1. Ziel nicht erreichbar, Bezeichner 'Bean' in Null aufgelöst
Dies läuft darauf hinaus, dass die verwaltete Bean-Instanz selbst nicht genau durch diesen Bezeichner (Name der verwalteten Bean) in EL gefunden werden konnte #{bean} .
Die Identifizierung 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 verantwortlich ist. Ist es JSF über @ManagedBean? Oder ist es CDI über @Named? Oder ist es Frühling über@Component ? Können Sie sicherstellen, dass Sie nicht mehrere Bean-Framework-spezifische Annotationen in derselben Backing-Bean-Klasse mischen? ZB @Named @Componentoder @Named @ManagedBeanoder @ManagedBean @Component. Das ist falsch. Die Bean muss von höchstens einem Bean-Verwaltungsframework 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: Wie füge ich eine Spring-Komponente / einen Spring-Service in eine JSF-verwaltete Bean ein?
Für den Fall , es ist JSF , die über die Bohne ist die Verwaltung @ManagedBean, dann müssen Sie sicher , dass der folgende machen:
Die faces-config.xmlRoot-Deklaration ist mit JSF 2.0 kompatibel. Also die XSD-Datei und dieversion müssen also mindestens JSF 2.0 oder höher angeben und somit nicht 1.x.
<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">
Für JSF 2.1 ersetzen Sie einfach 2_0 und 2.0durch 2_1und2.1 sind.
Wenn Sie JSF 2.2 oder höher verwenden, stellen Sie sicher, dass Sie verwenden xmlns.jcp.org Namespaces anstelle von java.sun.comüberall 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.2durch 2_3und 2.3sind.
Sie haben nicht versehentlich importiert javax.annotation.ManagedBean statt javax.faces.bean.ManagedBean. Achten Sie bei der automatischen Vervollständigung der IDE darauf, dass Eclipse den falschen als ersten Eintrag in der Liste automatisch empfiehlt.
- Sie haben das nicht
@ManagedBeandurch einen JSF 1.x-Stil überschrieben<managed-bean> Eintrag im in faces-config.xmlderselben Backing-Bean-Klasse zusammen mit einem anderen Namen für verwaltete Beans . Dieser wird Vorrang vor haben @ManagedBean. Das Registrieren einer verwalteten Bean in faces-config.xmlist seit JSF 2.0 nicht erforderlich. Entfernen Sie sie einfach.
- 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 Java EE API-JAR-Datei in der Webanwendung bereitstellen, wenn der Zielcontainer die JSF-API bereits standardmäßig bündelt. Anweisungen zur JSF-Installation finden Sie auch im Abschnitt "Installieren von JSF" auf unserer JSF-Wiki-Seite . Wenn Sie beabsichtigen, in Containern gebündeltes JSF von WAR auf anstatt in Container selbst zu aktualisieren, stellen Sie sicher, dass Sie den Zielcontainer angewiesen haben, WAR-gebündeltes JSF API / impl zu verwenden.
- Wenn Sie JSF-verwaltete Beans in eine JAR verpacken, stellen Sie sicher, dass die JAR mindestens mit JSF 2.0 kompatibel ist
/META-INF/faces-config.xml. Siehe auch Verweisen auf JSF-verwaltete Beans, die in einer JAR-Datei bereitgestellt werden.
Wenn Sie tatsächlich das jurassic JSF 1.x verwenden und kein Upgrade durchführen können, müssen Sie die Bean über <managed-bean>in faces-config.xmlanstelle von registrieren @ManagedBean. Vergessen Sie nicht, Ihren Projekterstellungspfad so festzulegen, dass Sie keine JSF 2.x-Bibliotheken mehr haben (damit die @ManagedBeanAnnotation nicht verwirrend erfolgreich kompiliert wird).
Für den Fall , es ist CDI , die über die Bohne ist die Verwaltung @Named, dann müssen Sie sicher , dass der folgende machen:
CDI 1.0 (Java EE 6) benötigt eine /WEB-INF/beans.xmlDatei, 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.xmloder eine leere beans.xmlDatei oder mit dem oben genannten CDI 1.0-kompatiblen beans.xmlVerhalten verhält sich genauso wie CDI 1.0. Wenn es ein CDI 1.1 kompatibel ist beans.xmlmit einem expliziten version="1.1", dann wird es standardmäßig registriert nur @NamedBohnen mit einer expliziten CDI Umfang Anmerkung wie @RequestScoped, @ViewScoped, @SessionScoped, @ApplicationScopedusw. Falls Sie beabsichtigt, alle Bohnen registrieren als CDI Bohnen verwaltet, auch solche ohne explizite Verwenden Sie für den CDI-Bereich das unten stehende CDI 1.1, das /WEB-INF/beans.xmlmit bean-discovery-mode="all"set kompatibel ist (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"(Standard) sicher, dass Sie nicht versehentlich einen JSF-Bereich importiert haben, z. B. javax.faces.bean.RequestScopedanstelle eines CDI-Bereichsjavax.enterprise.context.RequestScoped . Achten Sie auf die automatische Vervollständigung der IDE.
- 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 . In Fall können Sie nicht aktualisieren, dann müssen Sie entweder Satz bean-discovery-mode="all"in beans.xml, oder die JSF 2.3 spezifischen setzen@FacesConfig Anmerkung auf einer beliebigen Klasse in der WAR ( in der Regel eine Art von einem Start der Anwendung Klasse scoped).
- Nicht-Java-EE-Container wie Tomcat und Jetty werden nicht mit CDI-Paket geliefert. 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 auf 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 Java EE API-JAR-Datei in der Webanwendung bereitstellen, wenn der Zielcontainer die CDI-API bereits sofort bündelt.
Wenn Sie CDI-verwaltete Beans für JSF-Ansichten in eine JAR packen, stellen Sie sicher, dass die JAR mindestens eine gültige /META-INF/beans.xml(die leer bleiben kann) hat.
Wenn es Spring ist , der die Bean über verwaltet @Component, müssen Sie Folgendes sicherstellen:
Spring wird gemäß seiner Dokumentation installiert und integriert . Wichtig ist, dass Sie mindestens Folgendes haben web.xml:
<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>
(Vor allem ist alles, was ich in Bezug auf Spring weiß - ich mache Spring nicht - zögern Sie nicht, andere wahrscheinliche Spring-bezogene Ursachen zu bearbeiten / zu kommentieren, z. B. einige Probleme im Zusammenhang mit der XML-Konfiguration)
Im Fall ist es eine Repeater - Komponente , die den (verschachtelten) Bean über sein Managing varAttribut (zB <h:dataTable var="item">, <ui:repeat var="item">, <p:tabView var="item">etc) , und Sie haben tatsächlich eine „Ziel nicht erreichbar, Kennung‚item‘gelöst null“, dann müssen Sie sicher , dass der folgende machen ::
Auf das #{item}wird in bindingattribtue einer untergeordneten Komponente nicht verwiesen . Dies ist falsch, da das bindingAttribut während der Ansichtserstellungszeit und nicht während der Ansichtsrenderzeit ausgeführt wird. Darüber hinaus gibt es physisch nur eine Komponente im Komponentenbaum, die bei jeder Iterationsrunde einfach wiederverwendet wird. Mit anderen Worten, Sie sollten tatsächlich binding="#{bean.component}"anstelle von verwenden binding="#{item.component}". Aber viel besser ist es, die Komponenten-Bining-Funktion für Bean vollständig zu beseitigen und den richtigen Ansatz für das Problem zu untersuchen / zu erfragen, von dem Sie dachten, dass es auf diese Weise gelöst werden könnte. Siehe auch Wie funktioniert das Attribut 'Bindung' in JSF? Wann und wie soll es angewendet 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 entsprechen der JavaBeans-Spezifikation, während CDI abhängig von CDI impl / version Ausnahmen aufweist.
Eine FooBeanBacking Bean Klasse wie unten,
@Named
public class FooBean {}
wird in allen Bean-Management-Frameworks den Standardnamen für verwaltete Bean #{fooBean}gemäß JavaBeans-Spezifikation haben.
Eine FOOBeanBacking Bean Klasse wie unten,
@Named
public class FOOBean {}
deren unqualifizierter Klassenname mit mindestens zwei Großbuchstaben beginnt, wird in JSF und Spring einen standardmäßig verwalteten Bean-Namen haben, der genau dem unqualifizierten Klassennamen #{FOOBean}entspricht. Entspricht auch der JavaBeans-Spezifikation. In CDI ist dies auch bei Schweißversionen der Fall, die vor Juni 2015 veröffentlicht wurden, jedoch nicht bei Schweißversionen, die nach Juni 2015 veröffentlicht wurden (2.2.14 / 2.3.0.B1 / 3.0.0.A9), oder bei OpenWebBeans aufgrund eines Versehens in CDI spec . In diesen Weld-Versionen und in allen OWB-Versionen wird nur das erste Zeichen in Kleinbuchstaben geschrieben#{fOOBean} .
Wenn Sie explizit einen verwalteten Bean-Namen foowie unten angegeben haben,
@Named("foo")
public class FooBean {}
oder gleichwertig mit @ManagedBean(name="foo")oder @Component("foo"), dann wird es nur von #{foo}und somit nicht von verfügbar sein #{fooBean}.
1c. Wo ist die Backing Bean Klasse?
Der dritte Schritt wäre eine doppelte Überprüfung, wenn sich die Backing-Bean-Klasse an der richtigen Stelle in der erstellten und bereitgestellten 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 tatsächlich mit dem Schreiben von Code beschäftigt waren und ungeduldig F5 im Browser gedrückt haben. 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 .classDatei der Backing-Bean-Klasse muss sich in ihrer Paketstruktur in befinden /WEB-INF/classes. Wenn es als Teil eines JAR-Moduls gepackt ist, .classmuss sich die JAR, die die kompilierte Datei enthält, in /WEB-INF/libund daher nicht z. B. EARs /liboder anderswo befinden.
Wenn Sie Eclipse verwenden, stellen Sie sicher, dass die Backing-Bean-Klasse aktiviert ist srcund daher nicht WebContent , und stellen Sie sicher, dass Projekt> Automatisch erstellen aktiviert ist. Wenn Sie Maven verwenden, stellen Sie sicher, dass sich die Backing-Bean-Klasse in src/main/javaund somit nicht in src/main/resourcesoder befindet src/main/webapp.
Wenn Sie die Webanwendung als Teil einer EAR mit EJB + WAR (s) verpacken, müssen Sie sicherstellen, dass sich die Backing-Bean-Klassen im WAR-Modul und damit weder im EAR-Modul noch im EJB-Modul befinden. Die Business-Schicht (EJB) muss frei von Artefakten im Zusammenhang mit der Web-Schicht (WAR) sein, damit die Business-Schicht über mehrere verschiedene Web-Ebenen (JSF, JAX-RS, JSP / Servlet usw.) wiederverwendet werden kann.
2. Ziel nicht erreichbar, 'Entität' hat null zurückgegeben
Dies läuft darauf hinaus, dass die verschachtelte Eigenschaft entitywie #{bean.entity.property}zurückgegeben zurückgegeben wird null. Dies wird normalerweise nur angezeigt, wenn JSF den Wert für über eine Eingabekomponente wie unten festlegen muss property, während die #{bean.entity}tatsächlich zurückgegeben wird null.
<h:inputText value="#{bean.entity.property}" />
Sie müssen sicherstellen, dass Sie die Modellentität zuvor in einer @PostConstructoder <f:viewAction>-Methode oder einer add()Aktionsmethode vorbereitet haben , falls Sie mit CRUD-Listen und / oder -Dialogen in derselben Ansicht arbeiten.
@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; Dies in einem regulären Konstruktor zu tun, würde fehlschlagen, wenn Sie ein Bean-Management-Framework verwenden, das Proxys wie CDI verwendet. Verwenden Sie @PostConstructdiese Option immer, um die Initialisierung einer verwalteten Bean-Instanz zu aktivieren (und um @PreDestroydie Zerstörung einer verwalteten Bean-Instanz zu aktivieren). Außerdem hätten Sie in einem Konstruktor noch keinen Zugriff auf injizierte Abhängigkeiten. Siehe auch NullPointerException, wenn Sie versuchen, auf die @ Inject-Bean im Konstruktor zuzugreifen .
Falls das entityIdüber geliefert wird <f:viewParam>, müssten Sie <f:viewAction>stattdessen verwenden @PostConstruct. Siehe auch Wann wird f: viewAction / preRenderView im Vergleich zu PostConstruct verwendet?
Sie müssen auch sicherstellen, dass Sie das nullNichtmodell bei Postbacks beibehalten, falls Sie es nur in einer add()Aktionsmethode erstellen . Am einfachsten wäre es, die Bohne in den Ansichtsbereich zu stellen. Siehe auch So wählen Sie den richtigen Bean-Bereich aus.
3. Ziel nicht erreichbar, 'null' hat null zurückgegeben
Dies hat tatsächlich die gleiche Ursache wie # 2, nur die (ältere) verwendete EL-Implementierung ist etwas fehlerhaft, wenn es darum geht, den in der Ausnahmemeldung anzuzeigenden Eigenschaftsnamen beizubehalten, der letztendlich fälschlicherweise als 'null' angezeigt wird. Dies macht das Debuggen und Beheben nur dann etwas schwieriger, wenn Sie einige verschachtelte Eigenschaften wie diese haben #{bean.entity.subentity.subsubentity.property}.
Die Lösung ist immer noch dieselbe: Stellen Sie sicher, dass die betreffende verschachtelte Entität nicht nullauf allen Ebenen vorhanden ist.
4. Ziel nicht erreichbar, '' 0 '' hat null zurückgegeben
Dies hat auch die gleiche Ursache wie # 2, nur die (ältere) verwendete EL-Implementierung ist fehlerhaft bei der Formulierung der Ausnahmemeldung. Dies wird nur angezeigt, wenn Sie []in EL die Klammernotation verwenden, #{bean.collection[index]}bei der das #{bean.collection}selbst nicht null ist, das Element am angegebenen Index jedoch nicht vorhanden ist. Eine solche Nachricht muss dann interpretiert werden als:
Ziel nicht erreichbar, 'Sammlung [0]' hat null zurückgegeben
Die Lösung ist auch die gleiche wie bei Nummer 2: Stellen Sie sicher, dass das Sammlungsobjekt verfügbar ist.
5. Ziel nicht erreichbar, 'BracketSuffix' hat null zurückgegeben
Dies hat tatsächlich die gleiche Ursache wie # 4, nur die verwendete (ältere) EL-Implementierung ist etwas fehlerhaft, wenn es darum geht, den in der Ausnahmemeldung anzuzeigenden Iterationsindex beizubehalten, der letztendlich fälschlicherweise als 'BracketSuffix' angezeigt wird, was eigentlich das Zeichen ist ]. Dies erschwert das Debuggen und Beheben nur, wenn Sie mehrere Elemente in der Sammlung haben.
Andere mögliche Ursachen für javax.el.PropertyNotFoundException: