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: PhaseListener SystemEventListener BehaviorListener? (not sure)

-Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan

On Tue, Jul 21, 2009 at 1:08 PM, Kito Mann <kito.mann(a)virtua.com&gt; wrote: > On Tue, Jul 21, 2009 at 12:42 AM, Dan Allen <dan.j.allen(a)gmail.com&gt;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: >> >> PhaseListener >> SystemEventListener >> 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 -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan

On Wed, Jul 22, 2009 at 9:11 AM, Steve Roy <steveroy(a)ensighttech.com <mailto:steveroy@ensighttech.com>> wrote: 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. My focus was not necessarily on hooks to cleanup expensive resources. To clarify, my focus is to get listeners to tie in better with the EE platform. For instance, if I am developing an extension to JSF, and I want to manipulate the JSR-299 conversation or perhaps wrap one or more phases in a UserTransaction, there is no portable way to inject the necessary components. Another use case is that I want to store state in a JSR-299 contextual object or a stateful EJB session bean (or a hybrid of the two). Again, no portable way to access this bean. What I am looking for are injections like the following: @Resource UserTransaction transaction; @Current Conversation conversation; @EJB Cart cart; @Current StatusMessages statusMessages; Right now phase and system event listeners have to use JNDI to get at any of those resources, with subsequent calls necessary in some cases (such as to get a contextual instance from the BeanManager). My point is that managed objects in the Java EE platform should be able to receive injections. I see phase listeners and system event listeners as managed objects. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan

Am Mittwoch, den 22.07.2009, 21:40 -0700 schrieb Alaxander Smirnov: > Most of the JSF listener tags supports 'bind' attribute that allows to > use any JSF beans as listeners, that could have any scope and where > injection library could make any necessary work. > Because narrow listener objects are saved in the components tree, in > addition to the injection we should also define some addition > lifecycle methods ( e.g. activate/passivate ), otherwise status of > injected objects will be unpredictable. I suggest to check only is all > listener could be defined as binding to the JSF beans. > In respect to status of injected objects I cannot see the need for additional lifecycle methods (on the listener objects). We should support @Postconstruct/@Predestroy annotations (for consistency).

But the status of injected Objects should be transparently managed by the container, not the managed objects.