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

[Dan Allen]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090611/237c0fa4/attachment.html