Here is the official announcement


We're pleased to announce the availability of the Early Draft Review
of the next versions of the specification for JavaServer Pages and
Faces. JavaServer Pages (JSP) 2.1 is developed under JSR-245 and
JavaServer Faces (Faces) 1.2 is developed under JSR-252. The two
expert groups are working together to improve the alignment between
these two powerful web presentation technologies. The foremost such
alignment issue is the Expression Language, as stated in both JSRs.


JSP 2.1 exports the Expression Language (EL) into its own separate
document; technically a sub-document of the JSP specification. The
Unified EL spec defines a new top level java package, javax.el. This
package is completely independent of the technology using it and
allows the using technology to plug itself into the EL resolution
process. The bulk of the changes in the JSP spec itself follow from
how it uses the Unified EL.


As mentioned in the original JSR-252, this spec is not a new feature
release. Faces 1.2 contains the work for it to leverage the new
Unified EL, as well as a few spec related bug fixes.


The alignment of Faces and JSP in these JSRs enables some new
capabilities and provides a solid foundation for future growth. For
example, in a web application that uses both Faces and JSP, it is
possible for pages that only use JSP (without any faces content) to
access managed beans. Please see Appendix E of the JSP spec and the
preface of the Faces spec to see details of what's changed!


To access the specifications:


   JSP 2.1 EDR (JSR-245)
     http://jcp.org/aboutJava/communityprocess/edr/jsr245/
   Faces 1.2 EDR (JSR-252)
     http://jcp.org/aboutJava/communityprocess/edr/jsr252/


Sincerely,


Ed Burns, Pierre Delisle, Roger Kitain, Mark Roth and the JSR-245 and
JSR-252 Expert Groups.

I'm confused about the new EL Spec--

ELContext has an ELResolver for resolving properties, much like JSF's PropertyResolver.

The only question I have is that the 'expected' implementation of ELResolver is a composite object that uses the chain of responsibility (not so fine). In the grander scheme of things, the implied behavior of the spec would/could result in lots of casts to the expected type of CompositeELResolver from ELResolver. Also, in providing a "default" implementation of ELResolver, they've also added a property to ELContext (the visitor) to support the chain of responsibility pattern (CoR).

If they are specifying that the EL spec *IS* going to be a composite object, then ELResolver should be an interface, not a class at the very least. Also, ELResolver should provide some basic methods that would inforce the idea that it's a composite object without casting-- probably by seperating the chain handler and the chain nodes (ELResolver *has* ELHandlers).

Going back to the additional property on ELContext to support the CoR behavior, I realize that by flipping a flag on the ELContext the owner of the chain will know which ELResolver has taken care of the operation, independent of the result returned (public Object getValue(ELContext)).

This could also be accomplished by enforcing the filter pattern in the ELResolver/Handlers, where if I handle it, I will return my result, otherwise I will return the next item in the chain's result. This way, there's no need to add responsibility/state to ELContext to support the ELResolver's specific implementation.

Just some ideas....

Jacob,

The diagrams that show a grand "CompositeELResolver" built up with all sorts of child ELResolvers is not a requirement for how an implementation must be built. The requirement is that an implementation function equivalently to an ELResolver that was built this way. No one should ever be casting to CompositeELResolver. This is less clear than it should be.

The "handles" property is ugly, but turned out to be the least ugly of a whole lot of uglier possibilities. The filter pattern is an interesting idea, but my gut feeling is that it'd add more complexity than it would remove w/regards to how these ELResolvers get instantiated and connected. We also explicitly rejected the decorator pattern.

-- Adam Winer (JSF 252 EG member)

Thanks Adam,

Catch me if I'm wrong, but doesn't the JSP spec also jump on board with ImplicitVariableELResolvers too... almost as if the spec shouldn't just commit to CoR and setup the classes/interfaces to reflect that? This would still allow a developer to provide a single handler to the Chain that would handle all requests? IMHO, I think CoR and composite are a great fit for EL resolution and the spec should enforce it in order to provide the most flexibility to all vendors.

That was the only thing I really found, other than that, I think the spec looks great!

On a slightly different tangent, if I could add a feature to the specification, I think it would be handy to have a standardized query parameter argument that could override the distinction of a post verses a get request by the lifecycle. If the action method is a get request, the only phase that is executed by the lifecycle is RESTORE_VEIW. This presents a challenge to a component developer that cannot use javascript for submitting a form. What happens is that the component developer has to put allot of processing logic in the render because the same lifecycle events are not invoked.

ok we have the specs,how it will go with the reference implementation Tomcat, does that suggect a new major version. and as apache already have JSF in incubation phase(myfaces), i expect to see the interoperability happenning very soon

... we're on top of it, tracking the specs as they develop. As the specs get fleshed out, we'll branch in CVS and start working on the new features and changes for Tomcat 6... ;)

actually we need a compatible JSTL tags especially c:if and c:foreach to repeat or conditionally reject jsf tags (actually oracle provide such implementation in ADF FACES) so it is possible
and what is really required is a compatible templating tag lib as till now tiles and sitemesh does not play nice with jsf

joe