Excepción: no se pudo encontrar Fábrica: javax.faces.context.FacesContextFactory

Estoy migrando de JBoss 5.1.0.GA a JBoss 6.0.0-Final y haciendo frente a la siguiente excepción durante la inicialización de FacesServler

2011-03-09 18:07:24,574 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/].[Faces Servlet]] (http-0.0.0.0-8080-4) Allocate exception for servlet Faces Servlet: 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:725) [:1.2_15-20100816-SNAPSHOT] at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:239) [:1.2_15-20100816-SNAPSHOT] at javax.faces.webapp.FacesServlet.init(FacesServlet.java:164) [:1.2_15-20100816-SNAPSHOT] at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1208) [:6.0.0.Final] at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:955) [:6.0.0.Final] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:188) [:6.0.0.Final] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [:6.0.0.Final] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181) [:6.0.0.Final] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) [:6.0.0.Final] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88) [:6.0.0.Final] at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100) [:6.0.0.Final] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:6.0.0.Final] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.Final] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.Final] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.Final] at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0.Final] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.0.0.Final] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [:6.0.0.Final] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654) [:6.0.0.Final] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.Final] at java.lang.Thread.run(Thread.java:619) [:1.6.0_14] 

Revisé el código y descubrí que FactoryFinder busca el FactoryManager correspondiente en función del cargador de clases del hilo actual. También encontré que mi FactoryFinder.FACTORIES_CACHE contiene dos entradas para dos cargadores de clase:

 * BaseClassLoader which loads my EAR and * WebCtxLoader.ENCLoader which is used during web app running and which was current context classloaded for failed thread. 

Mi estructura de implementación es la siguiente:

 * deploy o myapplication.ear + lib # richfaces jars (3.3.1.GA) # seam jars (2.2.1.Final) # openfaces jar (2.0.0) # other jars + META-INF # jboss-app.xml # application.xml + myapplication.war # WEB-INF * web.xml * faces-config.xml * components.xml * deployers o jbossweb.deployer o jsf.deployer o and others 

Estoy usando Mojarra-1.2 como implementación de JSF

  org.jboss.jbossfaces.JSF_CONFIG_NAME Mojarra-1.2 

Después de algunas depuraciones podría resumir:

  1. all JSF initialization is made in BaseClassLoader thread, ie when javax.faces.FactoryFinder#setFactory(..) is invoked getClassLoader() returns EAR BaseClassLoader 2. A servlet thread (which cause exception) tries to look FactoryManager but his current classloader ( Thread.currentThread().getContextClassLoader()) is WebCtxLoader.ENCLoader. So nothing is returned and exception is thrown. 

Comprobé JBoss 5.1.0 y me aseguré de que la inicialización y el acceso para FactoryManager se realizaran en hilos con el mismo cargador de clases.

Intenté buscar en Google y no encontré mucha información sobre alguien que tenga el mismo problema, lo que me hace pensar que algo anda mal en mi entorno.

¿Alguien puede comentar o ayudar con esto?

Este es un signo de contaminación de classpath. JBoss ya se envía con JSF incluido. Esta excepción puede ocurrir si agrupa JSF en su WAR también. Solo colisionará.

Hay 2 soluciones:

  1. Deshágase de JARs jsf-api y jsf-impl en su WAR (es decir, no deberían terminar en /WEB-INF/lib después de la comstackción / implementación.

  2. Dile a JBoss que tu WAR viene con su propia versión de JSF para que JBoss no use la suya propia.

      org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL true  

Tuve el mismo problema, pero con GlassFish v3 incrustado. Añadí esto y funcionó:

  com.sun.faces.config.ConfigureListener  

Aquí está la página web que explica el problema: Usar JSF 1.2 con Facelets en Google App Engine .

Estaba teniendo el mismo problema con Jboss EAP 6.1 y 6.3.

Estoy usando Maven, entonces, mi problema fue sobre la generación del archivo EAR, cuando estoy usando Maven, descubrí que mi archivo EAR se había desplegado con dependencias “explotadas”, es decir, mi archivo EAR había sido implementado con una carpeta que contiene los archivos para mi proyecto, y no un WAR y archivos JAR.

Al investigar las diferencias entre el directorio EAR y el archivo EAR, descubrí que lo que ves no es lo que obtienes con Maven. Creo que el problema es que los diversos complementos de Maven para WAR y EAR no se aplican al crear los directorios explotados.

Para solucionarlo, simplemente eliminé las directivas ‘desempaquetar’ del POM para el EAR.

   br.web Web /project false   br.ejb Ejb false   

Además, no recomiendo que los directorios explotados se utilicen en un archivo EAR.

Intereting Posts