Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Spring/JSF Managed PhaseListener  RSS feed

 
Mole Moore
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,
I have a PhaseListener that uses FacesContext to help me perform some first time logic. I would like to use dependency injection (DI) with Spring to inject the FacesContext into a property in the PhaseListener object. I am able to do the same thing using Spring and a managed backing bean, but I do not see an integration point between Spring and JSF for allowing a PhaseListener to be a managed bean.
I am fairly new to JSF and Spring, so in addition to answering this question I would also be interested in hearing of different/better ways to do the same thing. I am using JSF 1.2 and Spring 2.0.

This setup injects FacesContext into my backing bean, which has an appropriate property and getter/setter to recieve the object.

From my spring config file:


From my faces-config file:


The idea would be to do the same thing but with a PhaseListener, which would also contain a property and getter/setter to hold the FacesContext.
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Spring's primary purpose is to manage static objects. The FacesContext is anything but static. It is created at the beginning of a request-handling cycle by the FacesServlet on a per-request basis (meaning it's NOT a singleton and can't be constructed by the Spring bean factory). It is destroyed once the last function of the response has completed. It doesn't exist at all if you make a non-JSF request such as a JSP or vanilla servlet request.

That sort of limits you.
 
Mole Moore
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tim, thanks for the response.

I guess I am not understanding your comment about Spring not being able to manage non-static objects. Spring allows for the management of virtually any object that you want, provided you know how to configure it, correct? The solution above is working brilliantly. I understand that this will only work within the "walled garden" of JSF, but that is all that is needed.

The crux of the issue is, can the same thing that I am doing with the FacesContext and my BackingBean (leveraging IoC by integrating Spring and JSF), be done with a PhaseListener? I have a solution working, using the code below. My goal is to get to a point where the FacesContext.getCurrentInstance() is injected into a property in my PhaseListener class, which will allow for easy out-of-container unit testing and will follow the pattern I am using in my backing beans, lending intself to easier support.


I am not set on using Spring/JSF to inject the depencency as the way I am currently doing this is working and is testable outside of a container. Just exploring the limits of the technologies.

I would also be interested in other ways to do the same thing.

Mark
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The key word there is "manage". JSF does its own management of its internal objects. So you don't need Spring to construct the FacesContext, and in fact only the FacesServlet has enough knowledge to do so. The FacesServlet would have to be gimmicked to register the FacesContext with Spring, but then you get into the problem of matching the correct FacesContext with the correct requester thread. Plus, it has to be de-registered once the response cycle is done or you're dealing with invalid objects. The same pretty much applies to your PhaseListener object.

In other words, too much complexity, too much room for error. I got sold on IoC long before I got sold on JSF, but there's places where it's not the best solution.

Also, note that what you're REALLY interested in there is your HTTPSession object. FacesContext was just a means to an end. But the same problems and more apply to it. Unlike the FacesContext, the HTTPSession is constructed by the web container. And if you'll notice, it's an Interface, so the specific implementation is internal to the webapp container.

My stock architecture is Spring+JSF, but I use Spring for the persistence and system services layers and link it to JSF for the presentation layer stuff. For that kind of endeavor it works just fine. I hide my FacesContext references in a utility class (which JSF injects as requested).
 
Mole Moore
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alright, so what I am hearing is two things:

1) It is NOT possible to integrate JSF/Spring in respect to PhaseListeners.

2) The integration that I have done between JSF/Spring in respect to the FacesContext and my BackingBean, while technically working, is dangerous for threading reasons.

Does that sound accurate?
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I said it wasn't possible to integrate JSF/Spring in PhaseListeners, someone would promptly demonstrate a way to do it.

However, I can't conceive of any scenario that wouldn't be a cure far worse than the "disease".

If you're attempting to capture the FacesContext in a variable or property, you're playing with fire, yes. Any scope wider than the current thread's stack is perilous. It's OK inside a a method's code, but that's about as far as you should trust it.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!