Summary: | Using JSF with snaps gives IllegalStateException: Could not find backup for factory javax.faces.context.FacesContextFactory | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [RT] Virgo | Reporter: | Moacir Cardoso <moacsjr> | ||||||
Component: | snaps | Assignee: | Project Inbox <virgo-inbox> | ||||||
Status: | NEW --- | QA Contact: | |||||||
Severity: | enhancement | ||||||||
Priority: | P3 | CC: | dmarthaler, dmitry, eclipse, moacsjr, nobody | ||||||
Version: | 3.0.2.RELEASE | Keywords: | helpwanted | ||||||
Target Milestone: | --- | ||||||||
Hardware: | PC | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Bug Depends on: | 371379 | ||||||||
Bug Blocks: | |||||||||
Attachments: |
|
Description
Moacir Cardoso
2012-02-09 06:19:03 EST
I agree that the popping of the TCCL to sun.misc.Launcher$AppClassLoader immediately before the loading of default-web.xml did look a bit suspicious. However, it is normal behaviour and irrelevant to the problemat hand, for two reasons. Firstly, sun.misc.Launcher$AppClassLoader is the default TCCL and this is pushed and popped by BundleThreadContextManager as necessary. So the default value being popped is really irrelevant as the purpose of BundleThreadContextManager is to push an appropriate TCCL and later pop whatever was there previously. Secondly, in the trace provided in the description, the TCCL pop is occurring on thread "TCP Connection(4)-127.0.0.1" which is different to the thread "start-signalling-2" which is loading configuration from default-web.xml. So the pop won't make any difference to the TCCL in place on the thread which loads the configuration. I am therefore changing the title of the bug to reflect that it is an issue getting JSF and snaps to work together. Adding to Glyns comments. We have not had much luck with JSF before, the way it's packaged isn't very friendly to OSGi and people have had problems getting that going on OSGi as it is. I can't actually remember anyone that's managed to get it working on Snaps so it might not be possible without some quite fundamental changes to Snaps. We will have a look though and see what we can learn at the very least, thank you for the sample app to allow us to do this. Once we know just how JSF is trying to lookup its context factory we will have a better idea of the situation. Chris. Created attachment 210876 [details]
GWT Snap Project
I do not believe that the JSF could be the problem.
The same occurs in another example that uses GWT.
I'll provide a simple example with JSP and Spring.
As I said before, I do not think the problem is specifically with JSF. I tried the same with a GWT application and the problem continues. I think the way the snap is trying to process the application web.xml has some faults. I noticed that the servlet's configured in web.xml are being loaded correctly but the listeners responsible for proper initialization of the frameworks do not seem to work. In the case of the JSF application the web.xml has the following listener <listener> <listener-class> com.sun.faces.config.ConfigureListener </ listener-class> </ listener> It is responsible for parsing all relevant JavaServer Faces configuration resources, and set the Reference Implementation runtime environment. Without it the following error occurs: java.lang.IllegalStateException: Could not find backup for factory javax.faces.context.FacesContextFactory The web.xml of the GWT test application has the same issues. He also uses a listener to load the applicationContext.xml and load some beans. Again the servlet springGwtRemoteServiceServlet is loaded but then it finds no instance of the applicationContext. <web-app xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns = "http://java.sun.com/xml/ns/javaee" xmlns: web = "http :/ / java.sun.com/xml/ns/javaee/web-app_2_5.xsd "xsi: schemaLocation =" http://java.sun.com/xml/ns/javaee http://java.sun.com / xml/ns/javaee/web-app_2_5.xsd "version =" 2.5 "> <! - Spring context -> <context-param> <param-name> contextConfigLocation </ param-name> <param-value> / WEB-INF/applicationContext.xml </ param-value> </ context-param> <listener> <listener-class> org.springframework.web.context.ContextLoaderListener </ listener-class> </ listener> <servlet> <servlet-name> springGwtRemoteServiceServlet </ servlet-name> <servlet-class> org.spring4gwt.server.SpringGwtRemoteServiceServlet </ servlet-class> </ servlet> <servlet-mapping> <servlet-name> springGwtRemoteServiceServlet </ servlet-name> <url-pattern> / gwt_teste / remote / * </ url-pattern> </ servlet-mapping> <welcome-file-list> <welcome-file> Gwt_teste.html </ welcome-file> </ welcome-file-list> </ web-app> For some reason no listener works with snaps. (In reply to comment #4) > As I said before, I do not think the problem is specifically with JSF. I tried > the same with a GWT application and the problem continues. What are the symptoms of the problem with the GWT application? If it's not "IllegalStateException: Could not find backup for factory javax.faces.context.FacesContextFactory" then please update the bug title to reflect the symptom you would like this bug to address. It all boils down to Snaps not supporting Listeners in web.xml. I will update this issue when listener support is finalized (2 - 3 weeks time). Dmitry Hi Glyn, apparently the problem seems to be that listeners configured in web.xml are not being loaded when the application runs as a snap. The title is good for me, because the exception that occurs is a consequence of the listener not be running. With GWT what happens is that it uses a listener to load and initialize the applicaction context.xml. When this application runs as a snap the listener does not load. But I only mention the GWT application on this post to indicate that not only the JSF has problems in running as a snap. Thank you for listening, and I am available to help in whatever is needed. (In reply to comment #6) > It all boils down to Snaps not supporting Listeners in web.xml. > > I will update this issue when listener support is finalized (2 - 3 weeks time). > > Dmitry Thanks. For clarity, please could you raise an enhancement bug to cover adding listener support. (We could hijack this bug, but that seems a little unfair given the specific symptoms captured here.) Created 371379 Thanks Dmitry Thanks Dmitry. Given that it is now clear that snaps does not support listeners in web.xml, this bug should be fixed either by documenting the restriction or, preferably, by implementing bug 371379. Flagging as enhancement since the function of 371379 is not yet supported. |