Skip to main content
Last updated August 03, 2015 06:41, by Martin Scott Nicklous
Feedicon  
=Expert Group Meeting Minutes The JSR 362 Expert Group meetings take place every Tuesday, unless exceptions are made. After the meeting, I will update this page with the minutes. ---- 28 July 2015 Andy Bosch Edward Burns x Ross Clewley Boleslaw Dawidowicz Kenneth Finnigan Thomas Heute x Neil Griffen x Werner Keil Kito Mann x Scott Nicklous Andrew Petro x Henri Sara Artur Signell David Taylor Julien Viet * Security notice CVE-2015-1926 ** The text on the mitre site is incorrect. Attempting to correct. * Continued with Bean Portlet presentation at page 17 ** @RenderMethod - is it useful to allow multiple render methods? *** If multiple render methods are used, can make it easy to break the HTML if start and end tags are produced by different methods *** Would be just as easy to have a single render method that calls other methods to obtain markup **** However, in this case, the including method would have to be changed to add new markup *** In general, @RenderMethod is good, but need to revisit whether multiple @RenderMethods should be allowed *** Simplified render method (returning a string; require declaration only of exceptions actually thrown; allow a 'no argument' method but allow for injection of portlet artifacts) would be a great simplification ** Why is the portlet defined to be a singleton object? Performance reasons, or other? *** Likely performance reasons ** @HeaderMethod *** Allows the portlet to set HTTP header elements and add markup to the HTML document head section *** Needed by streaming portals, since the response is already committed when a portlet is called to generate markup *** JSF portlet bridge consideration: JSF needs to run through the JSF lifecycle twice in order to support doHeaders / @HeaderMethod functionality ** Would be good to add @DoView, @DoEdit, and @DoHelp annotations as shorthand for the corresponding @RenderMethod in order to make a bridge for experienced portlet programmers sho are used to the GenericPortlet methods *** However, the proposed @RenderMethod annotation extends the idea of the the JSR 286 @RenderMode annotation, so there is a certain continuity of thought *** It might be possible for frameworks to define their own @DoView, etc., methods *** Personally, I would worry that introduction of these methods might make the API less clear, since you would have multiple ways to do the same thing *** ==> look at this again ** Spec timeline: *** 8/31 - draft content complete; this will contain most of the target functionality for the new spec *** 9/30 - Submit to JCP org as early review draft *** After that, update V3Prototype branch on Pluto project to conform to draft spec *** After that, add any missing functionality * Would be good to show prototype of new functionality at upcoming JavaOne and Apache events ** A prepackaged Windows version of the Pluto prototype is available [https://java.net/projects/portletspec3/downloads/download/V3Prototype/V3Prototype-20150225.zip here] ** The V3 prototype source can be obtained by cloning the repository located [https://git-wip-us.apache.org/repos/asf/portals-pluto.git here] and checking out the branch named V3Prototype ---- 21 July 2015 Andy Bosch Edward Burns x Ross Clewley Boleslaw Dawidowicz Kenneth Finnigan Thomas Heute x Neil Griffen x Werner Keil Kito Mann x Scott Nicklous Andrew Petro x Henri Sara Artur Signell David Taylor Julien Viet * The text for the CVE-2015-1926 security notice is incorrect and should be changed ** I contacted Mitre, but recieved no answer so far * Discussed Spec plans / target ** Hope to have a draft version of the spec completed by the end of August ** Content: new portlet state handling; PortletHub; Annotations for configuration ... should contain most, but not all, of the final content ** September will be for review / corrections ** Hope to submit document for EDR by end of September * JavaOne - JSR 362 EG Attendees might be able to show something at Hacker Garden ** The V3Prototype available from the Apache web site might be a possibility * JavaLand (Brühl, Germany 8 - 10 March 2016) accepting submissions, might be good to submit something about portlets * ApacheCon North America (Vancouver, Canada 12 - 13 May 2016) might be good to submit something about portlets * Continued Bean Portet presentation at page 11 ** URLFactory: Can it be used during an action request *** That is not the intention ... the idea would be to provide an injectable possibility to create URLs during the render and resource phases *** Might be good to allow its use during action requests to allow a portlet to initiate POST-redirect-GET paradigm *** Requirement to create a portlet URL during the action phase to allow for a redirect, see: [https://java.net/jira/browse/PORTLETSPEC3-49 PORTLETSPEC3-49 Add createRedirectURL() method to javax.portlet.ActionResponse interface and javax.portlet.filter.ActionResponseWrapper class] *** Would be very useful for JSF support *** Needed because some portal implementations do not implement POST-redirect-GET but return response directly as result of a POST *** JSR 286 portlet concept allows for a redirect to be performed by the portal at the end of the action phase after the action and all events have been processed. Whether or not a redirect is performed is not specified and is left to the portal implementation ** Concerning @PortletStateScoped - wouldn't it be better to just use Serializable rather than introduce new interface PortletSerializable? *** Developers already familiar with Serializable *** Serializable might fit in better with CDI passivation concept *** However, Serializable provides a very non-specific interface if you want to provide your own serialization - writeObject & readObject - doesn't fit in well with portlet concepts *** If Serializable were used, would be very difficult to make such parameters available on the client *** If Serializable were used, would have to define exactly how writeObject and readObject must be specified in order to allow storage as render parameter *** CDI passivation concept does not follow portlet rules that call for state to be passivated at the end of event requests and action requests, but not after render requests or resource requests *** PortletSerializable interface allows for serialization based on String arrays, which matches the render parameter value array definition *** @PortletStateScoped uses PortletSerializable to store the bean state as a render parameter *** The @PortletStateScoped annotation allows a parameter name to be provided *** Client-Side code using the portlet hub can access the @PortletStateScoped serialized data through use of the parameter name *** Since the serialized data is a string array, can be easily processed with JavaScript code *** Made it to page 16 .... will start at page 17 during next call ---- 14 July 2015 Andy Bosch Edward Burns x Ross Clewley Boleslaw Dawidowicz Kenneth Finnigan x Thomas Heute x Neil Griffen x Werner Keil Kito Mann x Scott Nicklous Andrew Petro x Henri Sara Artur Signell David Taylor Julien Viet * Discussed Security Bulletin CVE-2015-1926 concerning the serveResource vulnerability ** After some delay, the notice went live ** The Portlet Specification 2.1.0 Maintenance Release to remove the vulnerability from specified behavior is in 30-day review ** The updated source code has been posted to the [http://svn.apache.org/viewvc/portals/portlet-spec/trunk/portlet-api_2.1.0_spec/ Apache Portals] project (Thanks, David!!). * JavaOne: The portlet talks were not accepted :-( * Started going through the Bean Portlet presentation ** Can configuration annotations be used with portlets that implement the Portlet interface or extend GenericPortlet? *** Yes, that is the intention. The prototype shown 2 weeks ago did not implement this feature, but the final version will. ** How would portlet beans be recognized if no portlet deployment descriptor present? *** Standard CDI procedure - beans.xml file must be placed in WEB-INF directory *** But newer versions of CDI don't require existence of beans.xml **** So I wouldn't think bean portlets would, either ** The @BeanPortlet modifier for the PortletConfig object is ugly ... would be nice to get rid of it. *** Agreed. Problem is, don't really know how to get rid of it at this stage *** Currently is needed to disambiguate the PortletConfig object provided through the producer method from GenericPortlet, since GenericPortlet implements PortletConfig *** Might be a way to handle within the CDI extension; this point should be examined more closely ** Made it to page 10 in the presentation; will continue beginning at page 11 in the next meeting ---- 30 June 2015 Andy Bosch Edward Burns x Ross Clewley Boleslaw Dawidowicz Kenneth Finnigan x Neil Griffen x Werner Keil Kito Mann x Scott Nicklous Andrew Petro x Henri Sara Artur Signell David Taylor Julien Viet * Scott presented bean portlet prototype ** Allows configuration to be carried out through annotations *** Portlet deployment descriptor becomes optional *** Configuration info specified in portlet.xml takes precedence over info from annotations ** Defines method annotations for portlet lifecycle methods *** Header, Render, processAction, processEvent, and serveResource *** As opposed to type annotations that identify interfaces ** Container dispatches to annotated method based on method type and dispatch info depending on method type *** For Action requests, dispatch based on Action Name (parameter name defined by JSR 286 ActionRequest interface) *** For Render requests, dispatch based on portlet mode (similar to dispatch done by GenericPortlet for doView, doHelp, doEdit) *** For Resource requests, dispatch based on resource ID (different use of field defined by JSR 286) ** Would be possible to extend this idea for Render & Resource methods to include dispatching based on device information *** To allow device-specific methods to be created, container would select method based on device info *** Problem: where to get database for device-identifying info? *** Potential solution: [https://devicemap.apache.org/ Apache DeviceMap] project; [http://www.w3.org/TR/DDR-Simple-API/ based on W3C Spec "Device Description Repository Simple API "]. ** Apache DeviceMap *** Contains nfo for many devices in XML form *** Data is planned to be migrated to JSON format *** Defines Java API, which is non-standard *** Info could potentially be provided through CC/PP Profile object (JSR 188), which is available through PortletRequest#getProperty ** Minimum feature set necessary for specification *** In presence of CDI require that portlet classes instantiated by portlet container to enable CDI injection *** Provide custom CDI scopes for portlets - @PortletSessionScoped, @PortletStateScoped *** Provide annotations for configuration that can replace the deployment descriptor *** Method dispatching to methods defined by portlet interfaces ** Features that go beyond the minimum requirement *** Method dispatching to individual annotated methods *** Method dispatching based on device information * Comments / questions ** New way of looking at things; A step forward ** Expecting something different - type annotations along the lines of @WebServlet for configuration *** We might still go that route, either instead of or in addition to the bean portlet idea ** How about CDI performance? Big impact? *** CDI mature, well-implemented *** Vaadin: experience in this area would indicate potentially low impact *** However, implementation must be performance-optimized and tested to know for sure * JavaOne - notifications not out yet ** Scott & Neil submitted two papers ** There will be an EC meeting before javaOne, might be a good opportunity to present something (EDR?) if desired * JavaLand Conference in Brühl, Germany 8 - 10 March 2016 Call for Papers is open ... might be a good opportunity ---- 09 June 2015 Andy Bosch Edward Burns Ross Clewley Boleslaw Dawidowicz Kenneth Finnigan x Neil Griffen x Werner Keil Kito Mann x Scott Nicklous Andrew Petro x Henri Sara Artur Signell David Taylor Julien Viet * How to make CDI work in portlet on Tomcat? ** Problem: CDI apparently not being initialized when cross-context include occurs to include the portelt output ** Solution: Try configuring the [http://javadox.com/org.jboss.weld/weld-core-impl/2.2.4.Final/org/jboss/weld/servlet/WeldCrossContextFilter.html Weld cross-context filter] ... (worked!) * Java EE has been delayed until Spring 2017 ** Progress on Servlet 4 seems to be slowing it down * Neil will be in Darmstadt for a Liferay conference at the end of October
 
 
Close
loading
Please Confirm
Close