Исключение: не удалось найти Factory: javax.faces.context.FacesContextFactory - PullRequest
Новая
       21

Исключение: не удалось найти Factory: javax.faces.context.FacesContextFactory

13 голосов
/ 10 марта 2011

Я перехожу с JBoss 5.1.0.GA на JBoss 6.0.0-Final и сталкиваюсь со следующим исключением во время инициализации 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]

Я изучил код и обнаружил, что FactoryFinder ищет соответствующий FactoryManager на основе текущего загрузчика классов потока. Я также обнаружил, что мой FactoryFinder.FACTORIES_CACHE содержит две записи для двух загрузчиков классов: 

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

Моя структура развертывания следующая: 

* 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

Я использую Mojarra-1.2 в качестве реализации JSF 

    <param-name>org.jboss.jbossfaces.JSF_CONFIG_NAME</param-name>

    <param-value>Mojarra-1.2</param-value>

После некоторой отладки я мог бы подвести итог: 

     1. all JSF initialization is made in BaseClassLoader thread, i.e. 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.

Я проверил JBoss 5.1.0 и убедился, что инициализация и доступ к FactoryManager производились в потоках с одинаковым загрузчиком классов.

Я пытался зайти в Google, но не нашел много информации о ком-либо, кто сталкивался с такой же проблемой, что заставляет меня думать, что что-то не так в моей среде.

Кто-нибудь может прокомментировать или помочь с этим?

Ответы [ 3 ]

16 голосов
/ 10 марта 2011

Это признак загрязнения пути класса.JBoss уже поставляется с JSF в комплекте.Это исключение может произойти, если вы также включите JSF в свою WAR.Это только столкнется.

Существует 2 решения:

  1. Избавьтесь от jsf-api и jsf-impl JAR-файлов в вашей WAR (то есть они не должны заканчиваться на /WEB-INF/lib после сборки/deploy.

  2. Скажите JBoss, что ваша WAR поставляется с собственной версией JSF, чтобы JBoss не использовал свою собственную. 

    <context-param>
    <param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name>
    <param-value>true</param-value>
</context-param>
13 голосов
/ 19 мая 2011

У меня была такая же проблема, но со встроенным GlassFish v3. Я добавил это, и это сработало: 

<listener>
    <listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>

Вот веб-страница, объясняющая проблему: Использование JSF 1.2 с Facelets в Google App Engine .

0 голосов
/ 25 сентября 2015

У меня возникла та же проблема с Jboss EAP 6.1 и 6.3.

Тогда я использую Maven, поэтому моя проблема заключалась в создании файла EAR, когда я использовал Maven, я обнаружил, чтомой EAR-файл был развернут с «взорванными» зависимостями, то есть мой EAR-файл был развернут с папкой, содержащей файлы для моего проекта, а не с файлами WAR и JAR.

Исследуя различия между разобранным каталогом EAR и архивом EAR, я обнаружил, что то, что вы видите, не то, что вы получаете с Maven.Я думаю, проблема в том, что различные подключаемые модули Maven для WAR и EAR-сборки не применяются при создании разнесенных каталогов.

Чтобы исправить это, я просто удалил директивы 'unpack' из POM для EAR.1007 * 

<modules>  
        <webModule>  
                  <groupId>br.web</groupId>  
                  <artifactId>Web</artifactId>  
                  <contextRoot>/project</contextRoot>  
                  <unpack>false</unpack>
        </webModule>  
        <ejbModule>  
                  <groupId>br.ejb</groupId>  
                  <artifactId>Ejb</artifactId>  
                  <unpack>false</unpack>  
        </ejbModule>
  </modules>

Кроме того, я не рекомендую использовать разнесенные каталоги в файле EAR.

...