[jsr-314-open] Meeting minutes from EG face-to-face at Sun's SF office post-JavaOne

[Dan Allen]

One item I forgot to mention from the agenda. We discussed the possibility
of adding a session invalidate method to either the Servlet API
(HttpSession) or the JSF API (ExternalContext) that would defer invalidation
until the end of the request.

The trouble is that currently, when you call session.invalidate(), the
session is invalidated immediately and HttpSessionListeners are notified. If
a context management framework, such as JSF, JSR-299, or Seam, cleans up the
session bean storage at this time, then all subsequent access to
session-scoped components may fail (or begin accessing a different session,
depending on implementation). Likely what the user intends in this case is
for the session to be terminated at the end of the request.

Thus, there really should be two methods (either two method names or
introduce a boolean argument to defer). Of course, use of the method which
invalidates immediately would be discouraged.

Gavin proposed, on the contrary, that perhaps frameworks should simply be
designed to deal with the session.invalidate() being called in the middle of
the request. I think it is something that needs to be addressed one way or
the other.

-Dan

On Thu, Jun 11, 2009 at 3:37 PM, Dan Allen <dan.j.allen at gmail.com> wrote:

> There is a standing invitation by Sun (from what I've been told) to host an
> EG face-to-face meeting at Sun's San Francisco office after each JavaOne
> event. This year there was a strong representation by the JSF group. Andy
> and I both took notes and to be consistent with our policy on openness, we
> felt compelled to produce a consolidated set of minutes and share it with
> the JSR-314 community.
>
> What follows are the minutes from the meeting, held on June 05, 2009 from
> 10:30AM - 1:00PM. If you were in attendance, feel free to supplement these
> minutes with your own notes. Apologies if we left out any names of who was
> in attendance. There was no formal sign in sheet.
>
> The meeting began with introductions. Attendance:
>
> Name, Project/Spec, Company
>
> Andy Schwartz, JSR-314 EG, Oracle
> Tedd Goddard, JSR-314 EG, ICEfaces
> Greg Wilkins, JSR-315 EG, Mort Bay
> Rajiv Mordani, JSR-315 EG Lead, Sun
> Jason Lee, Mojarra/JSFTemplating, Sun
> Justin Lee, Sun
> Kin-Man Chung, JSR-245 EG Lead, Sun
> Wenbo Zhu, Open Google Servlet Engine, Google
> Dan Allen, JSR-314, Red Hat
> Kito Mann, JSR-314, Virtua
> Jan Luehe, Sun
> Ed Burns, JSR-314 EG Lead, Sun
> Roger Kitain, JSR-314 EG Co-Lead, Sun
> (apologies if we missed anyone)
>
> Topics:
>
> - Andy gave an overview of the improvements that came with JSF 2.0.
> Features mentioned:
>   - Ajax support. Though not a new technology, the first time JavaScript
> APIs were introduced into Java EE. Cited RichFaces and ICEfaces as source of
> ideas (he didn't mention Trinidad/ADF Faces, but they were sources as well)
>   - Standardization and improvement of Facelets. We could call it Facelets
> 2.0.
>   - Easy component creation: Built on the Facelets compositions, all
> aspects of a UI component can be defined in template markup.
>   - Bookmarkable URL components and view parameters contributed by Red Hat.
> Eventually led to the introduction of the metadata facet for non-rendering
> components which can be processed before the page is built.
>   - System events. Used for more fine-grained control and interception of
> the JSF life cycle. A more fine-grained approach than PhaseListeners.
>   - Exception queing so that root cause exceptions bubble out of the
> FacesServlet.
>   - Bean Validation integration. Constraints defined with annotations.
>   - Partial state saving to reduce the overhead of having to generate and
> save an entire component tree representation on each request.
>   - Annotation-based configuration, consistent with the direct the platform
> is heading
>   - Component behaviors, a mechanism for enhancing components with
> additional behaviors that are not explicitly defined by the component author
>
> - Kin-Man reported that there will be a maintaince release for JSR-245
>   - The focus is on EL improvements
>   - EL will include support for method parameters
>   - New version of EL/JSP will be aligned as "2.2"
>
> - Dan asked to discuss other features of EL that are supported by JBoss EL
>   - EL should support calling static methods in addition to non-static
> methods (just treat static like member method)
>   - EL should recognize namespaces in EL names, with API support to
> "import" a namespace (should involve JSR-299, which is introducing qualified
> EL names)
>
> - Rajiv gave update of JSR-315
>   - Annotation-based configuration
>   - Improved security/login routine; preemptive login now possible
>   - web.xml fragments
>   - Programmatic registration of listeners, filters, servlets
>   - Introduced the ServletContainerInitializer API, which the JSF members
> didn't seem to be very familiar with
>
> - Rajiv made the comment that the Web Tier spec may be able to rev more
> quickly than JEE as a whole
>
> - Greg requested that we discuss ordering with regard to web.xml fragments
>   - Discussed the ordering of servlet life cycle callbacks
>   - Similar in nature to the JSF faces-config.xml ordering
>   - Begin/end callbacks compilments should be called in reverse order on
> exit (e.g. filters)
>   - Point source callbacks should be executed in defined order (no
> reversing) (e.g. property listeners)
>   - Exclusion mechanism should prevent resources from being located in it's
> classpath entry when using getResources() and how this affects JSF
>   - Rajiv and Ed are going to sync up to make sure that we are consistent
> on ordering behavior across Servlet 3.0/JSF 2.0.
>
> - Dan asked for a clarification in servlet spec on when the
> ServletRequestListener#requestDestroyed() is called when an exception is
> raised
>   - Tomcat notifies the listener that the request has been destroyed before
> rendering the error page; this breaks framework reliant on the request
> boundaries such as JSR-299
>   - The group agreed that the notification should be fired after the error
> page is rendered, just like when an include or forward is dispatched to the
> RequestDispatcher
>
> - A lengthly discussion pursued regarding annotation scanning
>
> One concern is that various EE specs need to scan for annotations, which
> may lead to multiple scan passes, and possibly inconsistent behavior
> regarding how paths to scan/exclude are determined.  To avoid performing an
> extra scan, servlet EG members recommended that JSF implementations leverage
> the new ServletContainerInitializer API.  This allows the servlet container
> to call JSF implementations back with any classes that may be of interest to
> JSF (as specified via the @HandlesTypes annotation).  JSF 2.0
> implementations do not/should not require Servlet 3.0, but could possibly
> leverage this mechanism when running in 3.0 containers.
>
> Dan raised concern that the servlet spec is too narrow to deal with all
> annotation scanning needed in Java EE, so likely this is only going to be a
> partial optimization. He mentioned that the Java EE EG and the JSR-299 EG
> should be brought into this discussion.
>
> Towards the end of the meeting Ed provided thoughts on what's next for
> JSF...  Ed is collecting a list of issues to be addressed in an MR.   Ed
> would like to hold off on any major changes on top of 2.0 until the
> community has had a chance to adopt 2.0 and help identify key issues.
> Others (Dan, Andy) expressed interest in seeing some of the more pressing
> smaller issues addressed more quickly, either via an MR or, if not possible,
> via a 2.1 rev of the spec.
>
> Ed also raised the idea of a component-centric JSR for JSF in order to
> address concerns about the limited set of standard components.  We'll need
> to have some more discussion to scope this out and understand the
> implications for existing component vendors.  Ted Goddard suggested that one
> obvious place where standardization would be across the models defined by
> the various component frameworks.
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://in.relation.to/Bloggers/Dan
>
> NOTE: While I make a strong effort to keep up with my email on a daily
> basis, personal or other work matters can sometimes keep me away
> from my email. If you contact me, but don't hear back for more than a week,
> it is very likely that I am excessively backlogged or the message was
> caught in the spam filters.  Please don't hesitate to resend a message if
> you feel that it did not reach my attention.
>



-- 
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan

NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters.  Please don't hesitate to resend a message if
you feel that it did not reach my attention.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090612/4de90647/attachment.html