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.