Javax.el.PropertyNotFoundException identifizieren und lösen: Ziel nicht erreichbar

1. Target Unreachable, Bezeichner 'bean' auf null aufgelöst

Dies läuft darauf hinaus, dass die verwaltete Bean-Instanz selbst nicht durch genau diesen Bezeichner (verwalteten Bean-Namen) in EL wie folgt gefunden werden konnte #{bean}.

Das Erkennen der Ursache kann in drei Schritte unterteilt werden:

ein. Wer verwaltet die Bohne?
b. Wie lautet der (Standard-) Name der verwalteten Bean?
c. Wo ist die Backing Bean Klasse?

1a. Wer verwaltet die Bohne?

Der erste Schritt wäre zu überprüfen, welches Bean-Management-Framework für die Verwaltung der Bean-Instanz zuständig ist. Ist es [~ # ~] jsf [~ # ~] über @ManagedBean ? Oder ist es [~ # ~] cdi [~ # ~] über @Named ? Oder ist es Spring über @Component ? Können Sie sicherstellen, dass Sie nicht mehrere Bean-Management-Framework-spezifische Annotationen auf derselben Backing-Bean-Klasse mischen? Z.B. @Named @Component Oder @Named @ManagedBean Oder @ManagedBean @Component. Das ist falsch. Die Bean muss von höchstens einem Bean Management Framework verwaltet werden und dieses Framework muss ordnungsgemäß konfiguriert sein. Wenn Sie bereits keine Ahnung haben, welche Sie auswählen sollen, gehen Sie zu Backing Beans (@ManagedBean) oder CDI Beans (@Named)? und Spring JSF-Integration: So fügen Sie eine Spring-Komponente/einen Spring-Service ein in JSF verwaltet Bean?

Falls es [~ # ~] jsf [~ # ~] ist, wer die Bean über @ManagedBean Verwaltet, müssen Sie Folgendes sicherstellen:

• Die Root-Deklaration faces-config.xml Ist mit JSF 2.0 kompatibel. Die XSD-Datei und die version müssen also mindestens JSF 2.0 oder höher und damit nicht 1.x angeben.

  <faces-config
      xmlns="http://Java.Sun.com/xml/ns/javaee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://Java.Sun.com/xml/ns/javaee http://Java.Sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
      version="2.0">
  

  Ersetzen Sie für JSF 2.1 einfach 2_0 Und 2.0 Durch 2_1 Bzw. 2.1.

  Wenn Sie mit JSF 2.2 oder höher arbeiten, stellen Sie sicher, dass Sie überall xmlns.jcp.org - Namespaces anstelle von Java.Sun.com Verwenden.

  <faces-config
      xmlns="http://xmlns.jcp.org/xml/ns/javaee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"
      version="2.2">
  

  Für JSF 2.3 ersetzen Sie einfach 2_2 Und 2.2 Durch 2_3 Bzw. 2.3.

• Sie haben nicht versehentlich javax.annotation.ManagedBean anstelle von javax.faces.bean.ManagedBean importiert. Passen Sie mit IDE autocomplete, Eclipse ist dafür bekannt, dass es das falsche als erstes Element in der Liste automatisch empfiehlt.

• Sie haben den @ManagedBean - Wert nicht durch einen Eintrag im JSF 1.x-Stil <managed-bean> In faces-config.xml Für dieselbe Backing-Bean-Klasse zusammen mit einem anderen verwalteten Bean-Namen überschrieben. Dieser hat Vorrang vor @ManagedBean. Das Registrieren einer verwalteten Bean in faces-config.xml Ist nicht erforderlich, da JSF 2.0 diese einfach entfernt.
• Ihr Laufzeitklassenpfad ist sauber und frei von Duplikaten in JSF-API-bezogenen JARs. Stellen Sie sicher, dass Sie nicht mehrere JSF-Implementierungen (Mojarra und MyFaces) mischen. Stellen Sie sicher, dass Sie keine weitere JSF- oder gar Java EE API-JAR-Datei in der Webanwendung bereitstellen, wenn der Zielcontainer die JSF-API bereits im Lieferumfang enthält. Siehe auch "Installieren von JSF") Abschnitt unserer JSF-Wiki-Seite für JSF-Installationsanweisungen Wenn Sie beabsichtigen, ein Upgrade von JSF im Container von WAR auf JSF im Container selbst durchzuführen, stellen Sie sicher, dass Sie den Zielcontainer angewiesen haben, JSF im WAR-Bundle zu verwenden API/impl.
• Wenn Sie mit JSF verwaltete Beans in eine JAR packen, stellen Sie sicher, dass die JAR mindestens mit JSF 2.0 kompatibel ist /META-INF/faces-config.xml. Siehe auch Wie verweise ich auf JSF-verwaltete Beans, die in einer JAR-Datei enthalten sind?

• Wenn Sie tatsächlich das jurassic JSF 1.x verwenden und kein Upgrade durchführen können, müssen Sie das Bean über <managed-bean> In faces-config.xml Registrieren. anstelle von @ManagedBean. Vergessen Sie nicht, Ihren Projekterstellungspfad so zu ändern, dass Sie keine JSF 2.x-Bibliotheken mehr haben (damit die Annotation @ManagedBean Nicht verwirrend erfolgreich kompiliert werden kann).

  ---

Falls es [~ # ~] cdi [~ # ~] ist, wer die Bean über @Named Verwaltet, müssen Sie Folgendes sicherstellen:

• CDI 1.0 (Java EE 6) benötigt eine /WEB-INF/beans.xml - Datei, um CDI in WAR zu aktivieren. Es kann leer sein oder nur den folgenden Inhalt haben:

  <?xml version="1.0" encoding="UTF-8"?>
  <beans xmlns="http://Java.Sun.com/xml/ns/javaee" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://Java.Sun.com/xml/ns/javaee
                             http://Java.Sun.com/xml/ns/javaee/beans_1_0.xsd">
  </beans>
  

• CDI 1.1 (Java EE 7) ohne beans.xml Oder eine leere beans.xml - Datei oder mit der obigen CDI 1.0 kompatiblen beans.xml Verhält sich wie folgt wie CDI 1.0. Wenn es ein CDI 1.1-kompatibles beans.xml Mit einem expliziten version="1.1" Gibt, registriert es standardmäßig nur @Named Beans mit einen expliziten CDI-Bereich Anmerkung wie @RequestScoped , @ViewScoped , @SessionScoped , @ApplicationScoped usw. Wenn Sie beabsichtigen, alle Beans als von CDI verwaltete Beans zu registrieren, auch solche ohne expliziten CDI-Geltungsbereich, verwenden Sie die folgende CDI 1.1-kompatible /WEB-INF/beans.xml Mit bean-discovery-mode="all" gesetzt (die Standardeinstellung ist bean-discovery-mode="annotated").

  <?xml version="1.0" encoding="UTF-8"?>
  <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
                             http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
         version="1.1" bean-discovery-mode="all">
  </beans>
  

• Stellen Sie bei Verwendung von CDI 1.1+ mit bean-discovery-mode="annotated" (Standardeinstellung) sicher, dass Sie nicht versehentlich einen JSF-Bereich wie javax.faces.bean.RequestScoped anstelle eines CDI-Bereichs importiert haben. javax.enterprise.context.RequestScoped . Achtung mit IDE autocomplete.

• Wenn Sie Mojarra 2.3.0-2.3.2 und CDI 1.1+ mit bean-discovery-mode="annotated" (Standard) verwenden, müssen Sie Mojarra aufgrund eines Fehlers auf 2.3.3 oder neuer aktualisieren. Falls Sie kein Upgrade durchführen können, müssen Sie entweder bean-discovery-mode="all" In beans.xml Setzen oder die JSF 2.3-spezifische Annotation @FacesConfig Für eine beliebige Klasse in WAR ( im Allgemeinen eine Art Startklasse mit Anwendungsbereich).
• Nicht-Java EE-Container wie Tomcat und Jetty werden nicht mit CDI-Bundles ausgeliefert. Sie müssen es manuell installieren. Es ist ein bisschen mehr Arbeit als nur das Hinzufügen der Bibliotheks-JARs. Stellen Sie bei Tomcat sicher, dass Sie die Anweisungen in dieser Antwort befolgen: Wie installiere und verwende ich CDI bei Tomcat?
• Ihr Laufzeitklassenpfad ist sauber und frei von Duplikaten in CDI-API-bezogenen JARs. Stellen Sie sicher, dass Sie nicht mehrere CDI-Implementierungen (Weld, OpenWebBeans usw.) mischen. Stellen Sie sicher, dass Sie keine weitere CDI- oder sogar Java EE API JAR-Datei zusammen mit der Webanwendung bereitstellen, wenn der Zielcontainer die CDI-API bereits im Lieferumfang enthält.

• Wenn Sie von CDI verwaltete Beans für JSF-Ansichten in eine JAR-Datei packen, stellen Sie sicher, dass die JAR-Datei mindestens einen gültigen /META-INF/beans.xml Aufweist (der leer bleiben kann).

  ---

Falls es Spring ist, der die Bean über @Component Verwaltet, müssen Sie Folgendes sicherstellen:

• Spring wird installiert und gemäß seiner Dokumentation integriert. Wichtig ist, dass Sie mindestens Folgendes in web.xml Haben:

  <listener>
      <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>
  

  Und das in faces-config.xml:

  <application>
      <el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver>
  </application>
  

• (über alles, was ich in Bezug auf Spring weiß - ich mache Spring nicht - zögern Sie nicht, andere wahrscheinliche Spring-Ursachen zu bearbeiten/zu kommentieren; z. B. Probleme mit der XML-Konfiguration)

  ---

Falls es sich um eine Repeater-Komponente handelt, die die (verschachtelte) Bean über ihr Attribut var verwaltet (z. B. <h:dataTable var="item">, <ui:repeat var="item">, <p:tabView var="item">, Etc) und Sie haben tatsächlich ein "Target Unreachable, Bezeichner 'item' zu null aufgelöst", dann müssen Sie Folgendes sicherstellen:

• Auf #{item} Wird in binding einer untergeordneten Komponente nicht verwiesen. Dies ist falsch, da das Attribut binding während der Erstellungszeit der Ansicht und nicht während der Renderzeit der Ansicht ausgeführt wird. Außerdem gibt es physikalisch nur eine Komponente im Komponentenbaum, die bei jeder Iterationsrunde einfach wiederverwendet wird. Mit anderen Worten, Sie sollten tatsächlich binding="#{bean.component}" Anstelle von binding="#{item.component}" Verwenden. Aber viel besser ist es, das Komponenten-Bining loszuwerden und den richtigen Ansatz für das Problem zu untersuchen/zu fragen, das Sie auf diese Weise gelöst haben. Siehe auch Wie funktioniert das Attribut 'binding' in JSF? Wann und wie sollte es verwendet werden?

  ---

1b. Wie lautet der (Standard-) Name der verwalteten Bean?

Der zweite Schritt wäre die Überprüfung des registrierten verwalteten Bean-Namens. JSF- und Spring-Verwendungskonventionen sind konform JavaBeans-Spezifikation , während CDI je nach CDI-Impl/-Version Ausnahmen aufweist.

• Eine Backing-Bean-Klasse FooBean wie unten,

  @Named
  public class FooBean {}
  

  wird in allen Bean-Management-Frameworks einen standardmäßig verwalteten Bean-Namen von #{fooBean} gemäß JavaBeans-Spezifikation haben.

• Eine Backing-Bean-Klasse FOOBean wie unten,

  @Named
  public class FOOBean {}
  

  wessen nicht qualifizierter Klassenname mit mindestens zwei Großbuchstaben beginnt, wird in JSF und Spring einen standardmäßig verwalteten Bean-Namen haben, der genau dem nicht qualifizierten Klassennamen #{FOOBean} entspricht. In CDI ist dies auch in Weld-Versionen der Fall, die vor Juni 2015 veröffentlicht wurden, jedoch nicht in Weld-Versionen, die nach Juni 2015 veröffentlicht wurden (2.2.14/2.3.0.B1/3.0.0.A9), oder in OpenWebBeans aufgrund von ein Versehen in CDI-Spezifikation . In diesen Weld-Versionen und in allen OWB-Versionen wird nur das erste Zeichen in Kleinbuchstaben geschrieben #{fOOBean}.

• Wenn Sie einen verwalteten Bean-Namen foo wie unten angegeben haben,

  @Named("foo")
  public class FooBean {}
  

  oder gleichwertig mit @ManagedBean(name="foo") oder @Component("foo"), dann wird es nur von #{foo} und damit nicht von #{fooBean}.

  ---

1c. Wo ist die Backing Bean Klasse?

Der dritte Schritt wäre ein Doppelcheck, wenn sich die Backing-Bean-Klasse an der richtigen Stelle in der erstellten und implementierten WAR-Datei befindet. Stellen Sie sicher, dass Sie das Projekt und den Server vollständig bereinigt, neu erstellt, erneut bereitgestellt und neu gestartet haben, falls Sie gerade mit dem Schreiben von Code beschäftigt waren und ungeduldig F5 im Browser drücken. Wenn dies immer noch vergebens ist, lassen Sie das Build-System eine WAR-Datei erstellen, die Sie dann extrahieren und mit einem Zip-Tool überprüfen. Die kompilierte .class - Datei der Backing-Bean-Klasse muss sich in ihrer Paketstruktur in /WEB-INF/classes Befinden. Oder wenn es als Teil eines JAR-Moduls gepackt ist, muss sich die JAR, die die kompilierte .class - Datei enthält, in /WEB-INF/lib Befinden und somit nicht z. EAR's /lib Oder anderswo.

Wenn Sie Eclipse verwenden, stellen Sie sicher, dass sich die Backing-Bean-Klasse in src und damit notWebContent befindet, und stellen Sie sicher, dass Project > Automatisch erstellen ist aktiviert. Wenn Sie Maven verwenden, stellen Sie sicher, dass die Backing-Bean-Klasse in src/main/Java Und damit not in src/main/resources Oder src/main/webapp Angegeben ist.

Wenn Sie die Webanwendung als Teil einer EAR mit EJB + WAR (s) packen, müssen Sie sicherstellen, dass sich die Backing-Bean-Klassen im WAR-Modul und somit nicht im EAR-Modul oder im EJB-Modul befinden. Die Business-Schicht (EJB) muss frei von WAR-Artefakten (Web-Schicht) sein, damit die Business-Schicht über mehrere verschiedene Web-Schichten (JSF, JAX-RS, JSP/Servlet usw.) hinweg wiederverwendbar ist.

2. Target Unreachable, 'entity' hat null zurückgegeben

Dies läuft darauf hinaus, dass die verschachtelt Eigenschaft entity wie in #{bean.entity.property}null zurückgegeben wird. Dies wird normalerweise nur angezeigt, wenn JSF set den Wert für property über eine Eingabekomponente wie unten festlegen muss, während #{bean.entity} Tatsächlich null.

<h:inputText value="#{bean.entity.property}" />

Sie müssen sicherstellen, dass Sie die Modellentität zuvor in einer @PostConstruct - oder <f:viewAction> - Methode oder, falls Sie mit einer add() - Aktionsmethode arbeiten, vorbereitet haben CRUD-Listen und/oder -Dialoge in derselben Ansicht.

@Named
@ViewScoped
public class Bean {

    private Entity entity; // +getter (setter is not necessary).

    @Inject
    private EntityService entityService;

    @PostConstruct
    public void init() {
        // In case you're updating an existing entity.
        entity = entityService.getById(entityId);

        // Or in case you want to create a new entity.
        entity = new Entity();
    }

    // ...
}

In Bezug auf die Bedeutung von @PostConstruct; Wenn Sie dies in einem regulären Konstruktor tun, schlägt dies fehl, wenn Sie ein Bean-Management-Framework verwenden, das Proxies verwendet, z. B. CDI. Verwenden Sie immer @PostConstruct, Um die Initialisierung der verwalteten Bean-Instanz einzubinden (und verwenden Sie @PreDestroy, Um die Zerstörung der verwalteten Bean-Instanz einzubinden). Außerdem hätten Sie in einem Konstruktor noch keinen Zugriff auf injizierte Abhängigkeiten, siehe auch NullPointerException beim Versuch, auf die @Inject-Bean im Konstruktor zuzugreifen .

Wenn entityId über <f:viewParam> Bereitgestellt wird, müssen Sie <f:viewAction> Anstelle von @PostConstruct Verwenden. Siehe auch Wann wird f: viewAction/preRenderView im Vergleich zu PostConstruct verwendet?

Sie müssen auch sicherstellen, dass Sie das Nicht-Modell null während der Postbacks beibehalten, falls Sie es nur in einer add() -Aktionsmethode erstellen. Am einfachsten wäre es, die Bean in den Sichtbereich zu setzen. Siehe auch Wie wähle ich den richtigen Bean-Umfang aus?

3. Target Unreachable, 'null' hat null zurückgegeben

Dies hat tatsächlich die gleiche Ursache wie # 2, nur die (ältere) EL-Implementierung, die verwendet wird, ist etwas fehlerhaft bei der Beibehaltung des Eigenschaftsnamens, der in der Ausnahmemeldung angezeigt werden soll, die letztendlich fälschlicherweise als 'null' angezeigt wird. Dies erschwert das Debuggen und Reparieren nur dann, wenn Sie einige verschachtelte Eigenschaften wie z. B. #{bean.entity.subentity.subsubentity.property} Haben.

Die Lösung ist immer noch dieselbe: Stellen Sie sicher, dass die betreffende verschachtelte Entität nicht auf allen Ebenen null ist.

4. Target Unreachable, '' 0 '' hat null zurückgegeben

Dies hat auch die gleiche Ursache wie # 2, nur die verwendete (ältere) EL-Implementierung ist bei der Formulierung der Ausnahmemeldung fehlerhaft. Dies wird nur angezeigt, wenn Sie die geschweifte Klammer [] In EL wie in #{bean.collection[index]} Verwenden, wobei #{bean.collection} Selbst nicht null ist, das Element am angegebenen Index jedoch nicht vorhanden ist . Eine solche Nachricht muss dann interpretiert werden als:

Das nicht erreichbare Ziel 'collection [0]' hat null zurückgegeben

Die Lösung entspricht auch der von Nummer 2: Stellen Sie sicher, dass das Sammlungsobjekt verfügbar ist.

5. Ziel nicht erreichbar, 'BracketSuffix' hat null zurückgegeben

Dies hat eigentlich die gleiche Ursache wie # 4, nur die (ältere) EL-Implementierung, die verwendet wird, ist etwas fehlerhaft, um den in der Ausnahmemeldung anzuzeigenden Iterationsindex beizubehalten, der letztendlich fälschlicherweise als 'BracketSuffix' angezeigt wird, was wirklich das Zeichen ]. Dies erschwert das Debuggen und Reparieren nur dann, wenn sich mehrere Elemente in der Sammlung befinden.

Andere mögliche Ursachen für javax.el.PropertyNotFoundException:

• javax.el.ELException: Fehler beim Lesen von 'foo' beim Typ com.example.Bean
• javax.el.ELException: Die Eigenschaft actionMethod konnte in der Klasse com.example.Bean nicht gefunden werden
• javax.el.PropertyNotFoundException: Eigenschaft 'foo' wurde bei Typ com.example.Bean nicht gefunden
• javax.el.PropertyNotFoundException: Eigenschaft 'foo' bei Typ Java.lang.Boolean nicht lesbar
• javax.el.PropertyNotFoundException: Eigenschaft nicht gefunden für Typ org.hibernate.collection.internal.PersistentSet
• Auskommentierter Facelets-Code ruft weiterhin EL-Ausdrücke wie # {bean.action ()} auf und verursacht javax.el.PropertyNotFoundException auf # {bean.action}