Pourquoi les beans gérés ne sont-ils pas chargés dans Tomcat?

J'ai créé une application Web JSF 2 avec des facelets. Les libs pour JSF où stockées sur tomcat/lib, pour le partager entre plusieurs applications. J'ai pensé qu'il serait peut-être préférable de stocker les libs dans le dossier WEB-INF/lib de l'application, afin de rendre l'application plus indépendante des configurations de serveur. Maintenant, lorsque je lance Tomcat via Eclipse, les beans gérés sont chargés et fonctionnent. Mais quand je lance Tomcat directement/autonome, les beans gérés ne sont pas chargés automatiquement. J'ai utiliséPourquoi les beans gérés ne sont-ils pas chargés dans Tomcat?

@ManagedBean 
@SessionScoped/@RequestScoped

annotations pour déclarer des classes en tant que beans gérés.

Pourquoi est-ce? Que puis-je faire pour le réparer?

Je n'utilise pas encore de fichier faces-config.xml.

Merci d'avance.

modifié:

Peut-être que cela aide à voir ce qui se passe:

javax.el.PropertyNotFoundException: /Artikel.xhtml @12,108 value="#{artikelBackingBean.nameFilterPattern}": Target Unreachable, identifier 'artikelBackingBean' resolved to null 
    at com.sun.faces.facelets.el.TagValueExpression.getType(TagValueExpression.java:93) 
    at com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getConvertedValue(HtmlBasicInputRenderer.java:95) 
    at javax.faces.component.UIInput.getConvertedValue(UIInput.java:1008) 
    at javax.faces.component.UIInput.validate(UIInput.java:934) 
    at javax.faces.component.UIInput.executeValidate(UIInput.java:1189) 
    at javax.faces.component.UIInput.processValidators(UIInput.java:691) 
    at javax.faces.component.UIForm.processValidators(UIForm.java:243) 
    at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1080) 
    at javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:1180) 
    at com.sun.faces.lifecycle.ProcessValidationsPhase.execute(ProcessValidationsPhase.java:76) 
    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) 
    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) 
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312) 
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) 
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) 
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) 
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433) 
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) 
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) 
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) 
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) 
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) 
    at java.lang.Thread.run(Thread.java:619)

Source

2010-03-03 c0d3x

Avez-vous supprimé les bibliothèques JSF de 'Tomcat/lib'? – BalusC

Oui, je les ai enlevés. – c0d3x

Ugh personne ici parle anglais. – Andrew

Ceci est un signe que la webapp utilise 1.x JSF au lieu de JSF 2.x. Le configurateur de JSF 1.x ne reconnaît pas les annotations @ManagedBean qui provoqueront qu'elles ne sont pas chargées/initialisées automagiquement sans avoir besoin de faces-config.xml.

Je suspecterais une certaine collision dans la version des bibliothèques JSF utilisées. Analyser l'ensemble du chemin de classe pour les fichiers JAR JSF et utiliser un outil zip/rar pour déterminer le fichier MANIFEST.MF inclus pour la version JSF réelle. Le chemin de classe comprend Tomcat/lib, JRE/lib/* et Webapp/WEB-INF/lib.

Source

2010-03-03 14:28:52 BalusC

Je viens d'avoir ce problème et trouvé la solution était le véritable attribut dans mon-maven-guerre plug-in

 <plugin> 
      <groupId>org.apache.maven.plugins</groupId> 
      <artifactId>maven-war-plugin</artifactId> 
      <version>${plugin-war-version}</version> 
      <configuration> 
       <archive> 
        <addMavenDescriptor>false</addMavenDescriptor> 
       </archive> 
       <archiveClasses>true</archiveClasses> 
       <failOnMissingWebXml>false</failOnMissingWebXml> 
      </configuration> 
     </plugin>

donc la mise à false (false) a résolu mon problème.

Je blogué à ce sujet ainsi: http://www.baselogic.com/blog/development/java-javaee-j2ee/propertynotfoundexception-target-unreachable-identifier-patientbean-resolved-to-null

Source

2011-02-13 18:04:39

Le JSF trouver des haricots dans WEB-INF/classes, quand il commence avec tomcat: exécuter les classes isnt cet endroit.

Utilisez mvn tomcat: run-war, travaillé pour moi.

Source

2013-02-13 02:35:11

Comment savez-vous que OP utilise Maven? Ni la question actuelle de l'OP, ni aucune des questions précédemment posées par OP ne montrent qu'il utilise Maven ou qu'il y est au moins en quelque sorte familier. – BalusC

Un projet JSF simple exécuté avec le plugin MAven Tomcat 7 utilisant tomcat7: run ne parvient pas à détecter l'annotation @ManagedBean et à lancer l'exception PropertyNotFound. Mais fonctionne bien avec mvn: tomcat7: run-war. –

Ajoutez le fichier META-INF/context.xml au dossier racine Web et utilisez run-war. Vous pouvez mettre un tag Context vide dans le fichier.

Source

2014-01-30 10:41:46

Pourquoi les beans gérés ne sont-ils pas chargés dans Tomcat?

Répondre

Questions connexes