It would be nice if the design made it easy for resources to be released when the beforePhase/afterPhase processing completes so developers don't inadvertently forget to release expensive resources.

I can see the need for the feature. There is a danger though, that it makes it too easy for developers to implement time & resource expensive operations for invocations of the JSF lifecycle, which should be considered time sensitive.

- steve

On Tue, Jul 21, 2009 at 1:35 PM, Dan Allen <> wrote:
On Tue, Jul 21, 2009 at 1:08 PM, Kito Mann <> wrote:
On Tue, Jul 21, 2009 at 12:42 AM, Dan Allen <> wrote:
One of the questions that is often raised when discussing Java EE integration (JSR-299 and EJB) is how to get a reference to a container-managed resource from within a JSF listener (e.g., EJB session bean, BeanManager, EntityManager). While Java EE certainly provides mechanisms to lookup up a resource, such as through JNDI, I think we need to restate the question at hand. Why is it that JSF listeners don't support Java EE resource injection like managed beans. Requiring this functionality in a Java EE environment would go a long way towards making JSF extensions (such as Seam or ADF) portable and generally make the effort of integration w/ container-managed resources easier.

With that said, I would like to propose for the next rev of the JSF specification that listeners, in addition to managed beans, support container injection and life-cycle callbacks when JSF is run in a Java EE environment (the rule for servlet containers would parallel that of managed beans today).

Listeners include:

BehaviorListener? (not sure)

So the easiest way to do this would be to accept an expression any time a listener is declared, correct? This is possible today with the <f:view> tag for PhaseListeners, but not in faces-config.xml. In the other cases, we do have support for expressions.

I think you may be looking at it too narrowly. What we really want is for listeners to be managed beans, since most of the Java EE platform is going in that direction (and in some regards already there). We don't want something JSF-specific like EL expressions being passed in. What we really want is @PostConstruct, resource injection, etc. In other words, we want these classes to work within the context of the Java EE environment, rather than as outliers.


Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597