Working on the booking example has allowed me to gain a perspective about what services we need right away out of the faces (jsf) module. Perhaps it can be removed once the next rev of the EL is ready, but for now we need JBoss EL to get parametrized EL expressions. That means providing a custom JSF Application factory.

Fortunately, overriding the default Application impl got way simpler in JSF 2.0 since the spec now provides a base implementation class that you can override a single method at a time. We can eliminate these overrides as they come available in the platform. But for now we need it.

...that brings me to my next very important point. I think we need to be developing against the JSF trunk. The last release, PR2, does not have any of the features that we recently contributed, making development against PR2 almost pointless. I would like to compile a JSF release, call it 2.0.0-PR2_1 (or suggest another version number), deploy it to the JBoss repository, and Seam can depend on that for now. If there are no objections, I will do that today.

Going back to the faces module, instead of continuing with the org.jboss.seam.jsf and org.jboss.seam.faces package split in Seam 3, I think we should put all the faces classes under org.jboss.seam.faces and use appropriate sub-package names. So in this case, I propose org.jboss.seam.faces.application.SeamApplicationFactory and org.jboss.seam.faces.application.SeamApplication for overriding the default Application impl. We will also need the org.jboss.seam.el package (perhaps module).


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

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.