I've got an old web application which started to create some of its modules in JSF. The older modules store old entities directly to a session attribute.
So to avoid modifying the old modules, I created a session attribute listener in which it must convert old entities to new entities and make use of FacesContext to resolve the beans and store it there. That way I'm letting JSF do its way to resolve the variable, inject its dependencies and initialize it before use.
My problem is that FacesContext.getInstance() returns null if called within attributeAdded() or attributeReplaced() of my HttpSessionAttributeListener instance.
FacesContext is created by the FacesServlet when a JSF URL is requested. When the FacesServlet is done with the request and has returned the response, the FacesContext is discarded, essentially destroying it. An entirely new FacesContext is created when the user makes the next JSF URL request and the cycle repeats.
So any attempt to obtain a FacesContext outside of the context of the FacesServlet will fail. That includes not only container listeners, but non-JSF JSPs and servlets as well.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Mar 28, 2010
Thanks Tim. Right that's why it's call FacesContext. It's meant to be called when you're in a .. Faces's context. Maybe I should have asked what should I do about it? My goal is to keep my session data in synced.
I don't know but at the moment what I did is something like this:
It worked but it could have been better if I have used a listener instead I guess.
Well, I'm not too clear on things here. I think you're interested in dependent objects, which have their own issues. However, the JSF objects are not magically different from ordinary J2EE objects. So if you define a Managed Bean in session scope, it actually is an HttpSession attribute and can be freely accessed by legacy code as such. About the only caveat there is that if you create the Managed Bean explicitly in non-JSF code, you're responsible for whatever injections the JSF framework would have done had JSF constructed the object.
Yes that is a JSF code. But the first one that I have thought of isn't. I initially have thought of implementing a HttpSessionAttributeListener in which you will be able to listen to any changes in a SessionMap and do your things you deemed necessary. I was thinking of getting FacesContext from there so I could just call the variable resolver instead of getting the data directly from SessionMap so I could use the full injection, post constructor, etc of JSF.