Skip to main content
This revision made July 31, 2013 12:04, by Martin Scott Nicklous

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.


30 July 2013

     Andy Bosch
     Edward Burns
 x   Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
     Michael Freedman
 x   Neil Griffen
 x   Werner Keil
     Kito Mann
 x   Scott Nicklous
 x   David Taylor
 x   Julien Viet
  • David Taylor joined the EG to provide his portlet expertise, represent Apache, and help coordinate the spec work with the RI work when it commences at the Apache Pluto project
    • Welcome, David!
  • Revisited issue PORTLETSPEC3-6 from last week.
    • Question about how much information from other specifications do we want to reproduce in our spec.
      • Don't want to reproduce too much, as the source might change and then we would have a maintenance issue.
      • Current proposal provides a condensed description about language tags.
      • Ed is working on a similar issue for JSF.
      • We should wait for Ed's input to make sure the Portlet spec is compatible with the JSF spec in the area of Locales.
  • Discussed apidoc fixes for PORTLETSPEC3-7, 10, & 25.
    • Seem to be good; can be closed.
  • Discussed errata implementation PORTLETSPEC3-14 in spec document.
    • Seems to be good; can be closed.
  • Updated parameter handling document
    • improved discussion about parameter handling during an event request
    • Good improvement compared to last version.
  • Discussion about the mail "Thoughts about Parameters"
    • As concerns automatically copying parameters in general
      • There are some concerns about potential performance & state handling impact in the container implementation.
    • As concerns automatically adding parameters to render URLs and action URLs
      • great improvement from the view of the portlet developers
      • However, if we wanted to change the behavior of the existing createXxxURL methods, would break compatibility with 286
        • big change, not sure we want to do that
      • Alternative: introduce new methods containing a "copy flag" parameter (see new Jira issue PORTLETSPEC3-30)
    • As concerns automatically copying render parameters to the EventResponse & ActionResponse objects
      • There are some reservations
      • Would be a big break as compared to the existing 286 model
        • Would certainly need a runtime option switch in the deployment descriptor to ease migration of existing portlets
      • How would v3 portlets work with the JSR 329 JSF portlet bridge?
        • Several areas in the bridge spec could be affected
        • There is uncertainty about whether another rev of the bridge spec would take place
        • Companies are currently writing their own bridges; however, they are based on JSR 329, therefore 329 continues to be important
        • Have to be careful in this area
      • See new Jira issue PORTLETSPEC3-31 for more discussion
    • As concerns strange parameter handling behavior on action URL
      • We didn't really discuss it, but see new Jira issue PORTLETSPEC3-32 for some details
    • Question about backward compatibility: what should our goals be?
      • In any case, v1.0 & v2.0 portlets should be able to run unchanged.
      • There may be cases where we want to change the default behavior for v3 portlets
        • Could potentially identify portlet version based on deployment descriptor; adapt container behavior accordingly.
  • Informed JCP folks that we want to participate in the adopt-a-JSR program
    • Submitted text which will hopefully perk the interest of 1 or more JUGs
  • A couple of the Jira issues require actual code changes to GenericPortlet
    • How can these be tested? need to create test cases
  • How can we get started creating a test suite, probably on Apache?
    • Due to licensing issues, JSR 286 TCK can't be hosted on Apache
      • Was published under the Sun license for historical reasons
    • Three alternatives:
      • Rewrite the TCK under the Apache license
        • More work, but clean approach
        • Question about backward compatibility - portal vendors may need to run 286 TCK as well in order to prove backward compatibility
      • Split the TCK - use existing 286 TCK for 286 functionality; develop new 362 TCK under Apache
      • Extend the existing TCK under the Sun license
        • Big disadvantage: can't integrate under Apache Pluto
    • Could create TCK subproject under Apache Pluto
    • How do we get committers for the Apache Pluto project?
      • David will contact Apache board for guidance
      • Shouldn't be a big problem for people who actively participate
    • Who from the EG would want to be a committer on Pluto?
      • Please note your interest, either on the mailing list or in a private mail to me (Scott) if you prefer.
    • There is a read-only Pluto git mirror on Apache, see: Pluto GIT (thanks Werner!)
  • Discussion about JSR 362 javadoc / interface code licensing
    • Currently both are under the Apache 2 license and not the spec license
    • Uncertainty about whether that is acceptable
    • Werner will follow up

9 July 2013

     Andy Bosch
     Edward Burns
     Ross Clewley 
 x   Boleslaw Dawidowicz 
     Kenneth Finnigan 
     Michael Freedman
 x   Neil Griffen
     Werner Keil
     Kito Mann
 x   Scott Nicklous
 x   Julien Viet
 
  • Discussed how to make changes to the JSR 362 interfaces
    • Don't yet have the interface source code hosted anywhere
    • Would be nice to host it on github, since it would be easy for all members to make changes
      • We could start a github community for this work
    • Activated the website feature on the JSR 362 main page. This contains a placeholder with a link to the apidoc documentation for now.
      • Intention is to allow changes to be made to the api documentation in order to close errata issues.
      • Intended as interim solution until the JSR 362 interface code hosting question is solved.
    • The JSR 286 RI & interface code is hosted on Apache
    • Intention is to host the JSR 362 code on Apache as well
      • Need to contact Apache Portals people to see if they would be interested in participating
      • Determine relationship of Apache to github

2 July 2013

     Andy Bosch
     Edward Burns
 x   Ross Clewley 
     Boleslaw Dawidowicz 
 x   Kenneth Finnigan 
 x   Michael Freedman
 x   Neil Griffen
 x   Werner Keil
     Kito Mann
 x   Scott Nicklous
     Julien Viet
  • JSR 286 Parameter Handling Document
    • Neil provided comments on the Parameter Handling document
      • Should elaborate a little bit on the Event phase
      • Provide more clarification to removePublicRenderParameter() on the ActionResponse
    • Would be good to add examples, use cases - be prescriptive
    • Historical question: why the name "Public Render Parameters" rather than "Public State" or "Shared State" for example?
      • Named that way to maintain correspondence with the servlet naming
    • Might need one part of the spec more oriented toward portlet developers, and another part more toward container implementers
  • Question about attributes - why do we have the runtime parameter "actionScopedRequestAttributes"?
    • Needed a way of preserving state across Action and Render Requests
    • JSF portlet bridge implements its own notion of scope management
  • Neil changed the portletbox license to BSD
    • Thanks!

18 June 2013

     Andy Bosch
     Edward Burns
 x   Ross Clewley 
     Boleslaw Dawidowicz 
 x   Kenneth Finnigan 
 x   Michael Freedman
 x   Neil Griffen
 x   Werner Keil
     Kito Mann
 x   Scott Nicklous
     Julien Viet
  • Looked at JSR 286 Parameter Handling document - pretty good, captured reality
    • Parameter handling seems complicated
    • Most of the complexity is seen by container, bridge develiopers
    • Less of a problem for people devlopiong portlets - they can just work with getParameters
    • Would be good to provide use cases
  • State Management Expert Group is aware of JSR 362
    • They are trying to speed up their work
    • Public draft should be out soon
    • Should be monitored for potential synergies
  • Niel will change the portletbox license to BSD

4 June 2013

     Andy Bosch
     Edward Burns
 x   Ross Clewley 
 x   Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Michael Freedman
 x   Neil Griffen
 x   Werner Keil
     Kito Mann
 x   Scott Nicklous
 x   Julien Viet
  • Next week on 11 June there will be no call, as Scott will be out for the week.
  • There will be a WSRP call on Thursday of this week.
  • The JSR 286 Parameter Test summary page had to be split since it got too large for a single wiki page.
  • A document summarizing JSR 286 parameter handling is available here.
  • We discussed JIRA issue PORTLETSPEC3-29 "P3PUserInfos may need clarification and could be outdated in some areas"
    • Concerns the P3PUserInfos class defined in the PortletRequest interface
    • This class defines an enum for P3P user information constants
    • There is no documentation on the meaning of the individual enum items
      • This is a deficit that perhaps should be addressed
    • In addition, the P3P constants appear to be out of date - no provisions for social networking information
    • The enum is hard to use - must use toString() method to use the constants in methods. Why aren't they just strings to begin with?
    • Clarification on the history of P3PUserInfos
      • This class exists due to the P3P stuff defined in the WSRP 2.0 specification
      • The P3P web site hasn't been updated since 2007, need to determine whether P3P is still being used
      • May be a good question to address at the WSRP meeting
  • We discussed JSR 351 Java Identity API - Can it be leveraged for portlets?
    • Werner & Boleslaw are both members of the JSR 351 EG
    • Work is progressing slowly, but there should be a 1st draft soon
    • The aim is go in the direction of SSO, building a combined profile from multiple identity providers
      • Such as Facebook or Google
    • Allows user to see only what he/she is entitled to see
    • Use case: Health Care
      • Doctor might have rights to see one set of information
      • Pharmacist might have rights to see a different set of information
      • Seems to go in the direction of user authorization
      • Pretty generic API, high-level
      • Might not be good for lower-level authorization use
    • Targeting Java SE 8, but aim is to provide identity access in a distributed environment
      • But would probably be implemented as JAR that would work on top of Java EE 7
    • We need to keep an eye on this, align portlet spec with it
      • If schedules match & technology is relevant for portlets
  • JSR 350 Java State Management is another potentially interesting JSR
    • However is progressing very slowly
  • We spoke briefly about the map returned from getParameterMap()
    • Julien: on eXo Portal, Changing map does not change parameters
    • Scott, Neil, Ross: On IBM, Liferay, Oracle portals, changing the map changes the parameters
    • On Pluto, changing the map does not change the parameters
    • We probably can't increase restriction, so we should define map behavior such that changing the map changes the parameters

thanks for your participation,
Scott


28 May 2013

     Andy Bosch
     Edward Burns
     Ross Clewley 
     Boleslaw Dawidowicz 
 x   Kenneth Finnigan 
 x   Michael Freedman
 x   Neil Griffen
 x   Werner Keil
     Kito Mann
 x   Scott Nicklous
     Julien Viet
  • We spent considerable time talking about parameters and how they are supposed to work.
    • Mike provided clarification on public render parameters (through mailing list)
    • Scott created table describing Pluto parameter handling behavior, see wiki page
    • Several errata issues address parameter behavior
      • We discussed them, but didn't reach closure - need general concept description for parameter handling behavior
    • In the spec, the description of parameter behavior is not consolidated in one place, but is distributed in various sections
    • We need a consolidated description of parameter concepts and behavior
      • Scott will write such a description and make it available to the EG for perusal. Goal: FR 7 June 2013
      • It might be good to integrate a scenario walk-through like in the servlet spec to illustrate concepts
      • Once any corrections from EG members are integrated, it will serve as the basis for further work on parameters
      • The description will be integrated into the spec & API documentation in the appropriate manner
      • Based on the description, decisions on the corresponding errata issues will be taken
    • Changes to the parameter handling API may be necessary to improve clarity
    • Are parameters really URL parameters, or are they just modeled after URL parameters?
      • They are modeled after URL parameters
      • Portal implementations are not required to put the parameters in the URL
    • In the WSRP spec, there is a good description of navigational state
      • Navigational state is divided into a public and a private part
      • Parties interested in portlet parameter handling should review the WSRP material
    • Public render parameters are common state managed by the container
      • Common to all portlets using them
      • They are "owned" by the container, in contrast to private parameters which are "owned" by the portlet
      • Portlets can get, set, and remove public render parameters
      • Conceptually, they are common state accessed through a request, rather than being bound to the request
      • PRP's allow coordination between portlets through the common state
        • In contrast to events, which coordinate through an action
    • Parameter handling on resource requests is special
      • Resource requests are meant to serve resources for a specific portlet in a specific render state (specific set of render parameters set)
      • Render parameters active when resource URL is created are added to resource URL
      • Questionable whether resource requests are appropriate for page updates through Ajax - may need a new method for that
        • However, that is a discussion for later - will be deferred until Ajax support is discussed
  • Suggestion for getting errata closed: identify specific issues for focus and closure
    • Selected issues need to have a clean, clear proposal of what is to be done
    • Allow 1 weekly meeting for discussion with final decision made in the following meeting

thanks for your participation,
Scott


21 May 2013

     Andy Bosch
     Edward Burns
 x   Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Michael Freedman
 x   Neil Griffen
 x   Werner Keil
     Kito Mann
 x   Scott Nicklous
 x   Julien Viet
  • Scott still needs to follow up on spec & javadoc updates
  • There was some discussion on parameters
    • Lack of clarity on how pluto & other implementations work
    • A good task would be creation of a table showing pluto parameter handling behavior
      • Scott will look into this, comeback next meeting
    • Neil provided portletbox on GitHub containing test portlets for various aspects of parameter handling behavior
      • Very nice way to share code, collaborate on code development

14 May 2013

     Andy Bosch
     Edward Burns
 x   Ross Clewley 
 x   Boleslaw Dawidowicz 
 x   Kenneth Finnigan 
     Michael Freedman
 x   Neil Griffen
     Werner Keil
     Kito Mann
 x   Scott Nicklous
 x   Julien Viet
  • Neil provided information that the API documentation for JSF is under the spec license rather than the RI license.
    • Scott will follow up with the legal folks to see if this can be arranged for JSR 362
  • We went through all of the Jira issues that were filed under the component "JSR 286 Portlet Specification Errata"
  • The following issues were accepted for implementation:
    • (Spec update) [PORTLETSPEC3-1] Errata: Clarification for javax.portlet.renderHeaders Container Runtime Setting
    • (Javadoc update) [PORTLETSPEC3-3] Errata: Clarification in Javadoc for CacheControl.getExpirationTime()
    • (Javadoc update) [PORTLETSPEC3-4] Errata: Clarification for PortletRequest.getPortletSession()
    • (Javadoc update) [PORTLETSPEC3-5] Errata: Clarification about Private Render Parameters
    • (Spec update) [PORTLETSPEC3-6] Errata: Clarification for section "PLT.25.8.2 Locales supported by the Portlet"
    • (Spec & Javadoc update) [PORTLETSPEC3-7] Errata: Clarify Inconsistency about Removing Shared Render Parameters
    • (Spec update) [PORTLETSPEC3-12] Errata: Clarify use of Portlet 1.0 Tag Library in v2.0 Portlets
    • (Code update - GenericPortlet) [PORTLETSPEC3-15] Issue in GenericPortlet Annotation Processing
    • (Code update - RenderResponse)[PORTLETSPEC3-17] Errata: Correction in setNextPossiblePortletModes
    • (Spec & Javadoc update)[PORTLETSPEC3-19] Errata: Clarify when CacheControl parameters can be set
      • Scott will update spec
      • Neil will create proposal for related javadoc clarifications (see Neil's comment in issue)
    • (Javadoc update) [PORTLETSPEC3-20]  Errata: Clarification in Javadoc for an illegal scope use in PortletSession methods
    • (Code update - GenericPortlet) [PORTLETSPEC3-23] Errata: Issue in GenericPortlet Exception Handling for Annotations
  • The following issues were discussed but need follow-up:
    • [PORTLETSPEC3-8] Errata: Clarify inconsistencies regarding getting and setting parameters
      • The aspect about removing parameters needs to be split out and clarified. A separate issue will be created and assigned to Neil.
      • The rest will be updated in the comment section
    • [PORTLETSPEC3-9] Errata: Clarification needed for method MimeResponse.createRenderURL
      • Need to define use cases for propagating or not propagating the URL parameters
      • Follow-up once the additional info has been collected
    • [PORTLETSPEC3-10] Errata: Clarify setting parameters on Resource URLs
      • Collect information on how current portals behave in this area and follow up
    • [PORTLETSPEC3-14] Errata: Clarification about the Portlet Title
      • Scott will follow up with proposal for text change in spec
    • [PORTLETSPEC3-24] GenericPortlet.doHeaders(RenderRequest, RenderResponse) should throw javax.portlet.PortletException
      • Missed this one when going through the list ... sorry!
  • During the discussion, Neil noted that he had created test portlets for certain areas to determine how the portal implementation handles these cases. He will create additional portlets and make all of his test portlets available to the group so that we can all easily determine how our implementations behave.
  • Scott will take care of the spec updates, and will try to have the changes implemented in draft form by the next meeting.
  • We talked about how to get the Javadoc and code changes implemented.
    • Nobody from the EG is committer for the Apache Pluto project
    • One idea would be to recruit a person who was active in Pluto into the EG - Julien will reach out to a potential candidate
  • The issues filed under component "Ideas for JSR 362 Extensions" will be discussed at a later date

7 May 2013

     Andy Bosch
     Edward Burns
 x   Ross Clewley 
     Boleslaw Dawidowicz 
 x   Kenneth Finnigan 
     Michael Freedman
     Neil Griffen
     Werner Keil
 x   Kito Mann
 x   Scott Nicklous
 x   Julien Viet
  • Ed Burns has joined the JSR 362 EG to represent JSF interests. Welcome, Ed!
  • We want to review the errata that were entered into the Issue tracker
    • Everybody should try to review the issues in Jira by Friday 10 May.
      • If you can't make that date, send me a mail and let me know, or post on the mailing list
      • If you have additional issues, please try to enter them into the Issue tracker by Friday 10 May.
    • If you see need for discussion, make a comment in Jira.
    • All issues not marked for discussion will be considered to be accepted
    • All issues marked for discussion will be discussed in the next meeting on 14 May.
  • We had a short discussion on potential topics to discuss after the errata have been taken care of
    • Pros and cons of starting out with either a big, important issue or a small, easy issue
    • One idea might be to review the servlet spec and realign the corresponding portlet APIs
      • Since our goal is to align with the Java EE 7 specs, the target servlet version would be 3.1
      • Julien has some ideas about what could be done in this area
    • JSF alignment or optimization would be very interesting
      • However, this might be a larger topic that could potentially impact a number of areas, depending on how we want to handle it

thanks for your participation, Scott


30 April 2013

     Andy Bosch
 x   Ross Clewley 
      Boleslaw Dawidowicz 
 x   Kenneth Finnigan 
 x   Michael Freedman
 x   Neil Griffen
      Werner Keil
      Kito Mann
 x   Scott Nicklous
 x   Julien Viet
  • Neil - action item from last time, javadoc and method signatures for JSF licensed as open source, need to determine as to whether that would be part of the spec.
    • Neil has sent mails to obtain information, will report when information is available
  • Scott is working on the errata list, hasn't made the hoped-for progress so far, but hopes to have a list available for discussion by the next meeting.
    • apparently, not all can create JIRA issues ... Scott will report problem and obtain a solution hopefully quickly.
  • Scott tried to use the MyFaces JSF Portlet Bridge 3.0.0 alpha implementation with WebSphere, but ran into problems.
    • Mike kindly offered assistance
    • Neil promised to send a link around through the mailing list on how to use Mojarra 2.1 with WebSphere

thanks for your participation, Scott


23 April 2013

Attendees:

 x   Andy Bosch
 x   Ross Clewley 
 x   Boleslaw Dawidowicz 
 x   Kenneth Finnigan 
 x   Michael Freedman
 x   Neil Griffen
 x   Werner Keil
     Kito Mann
 x   Scott Nicklous
 x   Julien Viet
  • Welcome to the Expert Group!
  • We will start using the java.net tools for communication, beginning now, more or less.
    • I'm still learning how to administer the java.net site, so please be patient.
    • Expert Group: Please let me know your java-net userIDs, so I can give you appropriate rights to update things if I need to, once I figure out how to do so.
    • The EG calls will be private, but the minutes will be published on the public site.
    • However, I would be open to allowing guests if needed to provide special expertise.
  • A working document based on the JSR 286 Specification is available on the download page.
  • We agreed I believe to start discussion with an errata / clarifications list for JSR 286.
    • I unfortunately didn't get far enough along to post my list of errata
    • How shall we go about collecting items? Shall we use the issue tracker, or put things on the project wiki?
      • We will use the issue tracker.
      • We will collect the individual items through the issue tracker and then I will put a consolidated list on the Wiki for discussion before they are incorporated into the document.
      • Scott will look at the issue tracker and see if we need a naming convention or some such for the errata list.
  • Question about licensing for the JSR 362 Javadoc
    • after discussion with IBM legal, it looks like the Javadoc will fall under the RI license (Apache 2 license), since it is derived from the Reference Implementation
      • Other JSRs in the past used to fall under to spec license ... need to follow up.
      • With JSR 329, the message signatures were in the HTML document, so they were under the spec license
      • The Faces spec calls under the Java EE umbrella, so is a bit different.
      • How would someone go about creating their own Impl based on the spec only?
      • Scott will follow up.
  • Question about putting the TCK up under the Apache Pluto project
    • We need to integrate the JSR 286 TCK to maintain & prove backward compatibility with JSR 286
    • The JSR 286 TCK is licensed under a Sun license
    • Therefore the JSR 362 TCK will need to be licensed under the same license, or would have to include the JSR 286 TCK as a plug-in somehow
    • Possible solutions?
      • Yes, we could require folks to run obtain and run the the JSR 286 TCK in order to verify compatibility and then run the JSR 362 TCK on top of that. That way, we could put the JSR 362 TCK up on Pluto.

thanks for your participation,

 Scott
Difference compared to previous revision
** Who from the EG would want to be a committer on Pluto? *** Please note your interest, either on the mailing list or in a private mail to me (Scott) if you prefer. ** There is a read-only Pluto git mirror on Apache, see: [http://git.apache.org/pluto.git/ Pluto GIT] (thanks Werner!) *** There are read-only git mirrors for many Apache projects, see: [http://git.apache.org/ Apache git mirrors] * Discussion about JSR 362 javadoc / interface code licensing ** Currently both are under the Apache 2 license and not the spec license ** Uncertainty about whether that is acceptable ** Werner will follow up ---- 9 July 2013 Andy Bosch
 
 
Close
loading
Please Confirm
Close