[GLASSFISH-16061] could not find Factory: javax.faces.context.FacesContextFactory Created: 21/Feb/11  Updated: 17/May/11  Resolved: 11/May/11

Status: Closed
Project: glassfish
Component/s: jsf
Affects Version/s: 3.1_b43
Fix Version/s: None

Type: Bug Priority: Major
Reporter: bleathem Assignee: rogerk
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, Seam 3


Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

On running my JSF/Seam 3 application (using netbeans), the application startup fails with the message:

WARNING: StandardWrapperValve[FacesServlet]: PWC1382: Allocate exception for servlet FacesServlet
java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory

I have to undeploy my application, restart glassfish, and re-deploy my application (sometimes several times) to get this problem to go away.

This problem is intermittent.

--------------

Stack trace:

WARNING: StandardWrapperValve[FacesServlet]: PWC1382: Allocate exception for servlet FacesServlet
java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:815)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:317)
at javax.faces.webapp.FacesServlet.init(FacesServlet.java:253)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1439)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:1071)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:189)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)



 Comments   
Comment by rogerk [ 21/Feb/11 ]

Can you provide a war for this app?

Comment by bleathem [ 21/Feb/11 ]

I'll see if I can put together a simplified war that exhibits this behaviour.

Comment by rogerk [ 21/Feb/11 ]

Simplified app would be nice. I know that there are probably a lot of libraries with a Seam3 aopp.

Comment by rogerk [ 21/Feb/11 ]

Simplified app would be nice. I know that there are probably a lot of libraries with a Seam3 aopp.

Comment by rogerk [ 21/Feb/11 ]

Tagging until more information is available.

Comment by bleathem [ 22/Mar/11 ]

I can now reproduce this behaviour, and I have a workaround, with a small caveat.

I cannot run my app with the weld-osgi-bundle.jar provided with glassfish, so I replace it with the latest weld-osgi-bundle snapshot.

The error comes up consistently in my sample app, and I can make it consistently going away by adding the following to my web.xml:

<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

I can provide you with the sample app if this information is not enough to go on.

Comment by rogerk [ 23/Mar/11 ]

Are you saying your app was not configured to go through the FacesServlet?

Comment by Scott Fordin [ 23/Mar/11 ]

Need more info to add issue to 3.1 Release Notes.

Comment by rogerk [ 11/May/11 ]

Closing as I have not heard back from reporter and this appears to be a configuration issue - in addition the reporter has workaround for config issue.

Comment by bleathem [ 16/May/11 ]

This issue is sporadic issue, and is observed when a JSF application does not register the Faces Servlet in the web.xml.

com.sun.faces.config.FacesInitializer will attempt to initialize the JSF Servlet, which normally works fine, except when Seam Faces is included in the application, which also tries to initialize the Servlet.

This bug is not deterministic due to the random ordering of listeners by Glassfish.

For more information, please see the corresponding issue in SeamFaces:
https://issues.jboss.org/browse/SEAMFACES-163

Comment by Scott Fordin [ 17/May/11 ]

Added issue to 3.1 Known Issues section of the 3.1-3.1.1 Release Notes.

Generated at Mon May 04 06:29:19 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.