jsf - 识别和解决javax.el.PropertyNotFoundException:目标不可达

Question

当尝试像#{bean.entity.property}这样引用EL中的托管bean时，有时会抛出javax.el.PropertyNotFoundException: Target Unreachable异常，通常是在设置bean属性或调用bean操作时。

似乎有五种不同的消息：


Target Unreachable, identifier 'bean' resolved to null
Target Unreachable, 'entity' returned null
Target Unreachable, 'null' returned null
Target Unreachable, ''0'' returned null
Target Unreachable, 'BracketSuffix' returned null


它们都是什么意思？它们是如何引起的，应该如何解决？

Answer 1

1.无法到达目标，标识符“ bean”解析为空

归结为，像#{bean}这样，在EL中不能完全通过标识符（托管bean名称）找到托管bean实例本身。

查明原因可分为三个步骤：

一种。谁在管理bean？
b。 （默认）托管Bean名称是什么？
C。支持bean类在哪里？

1a。谁在管理bean？

第一步是检查哪个bean管理框架负责管理bean实例。是通过@ManagedBean的JSF吗？还是通过@Named的CDI？还是通过@Component通过Spring？您能确定不会在同一个支持bean类上混合使用多个特定于bean管理框架的注释吗？例如。 @Named @Component或@Named @ManagedBean或@ManagedBean @Component。错了该bean必须最多由一个bean管理框架管理，并且该框架必须正确配置。如果您不知道该选择哪个，请转至Backing beans (@ManagedBean) or CDI Beans (@Named)?和Spring JSF integration: how to inject a Spring component/service in JSF managed bean?

如果是JSF通过@ManagedBean管理Bean，那么您需要确保以下几点：


faces-config.xml根声明与JSF 2.0兼容。因此，XSD文件和version必须至少指定JSF 2.0或更高版本，而不是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">

对于JSF 2.1，只需分别用 2_0和 2.0替换 2_1和 2.1。

如果您使用的是JSF 2.2或更高版本，请确保在所有位置都使用 xmlns.jcp.org命名空间而不是 java.sun.com。

<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">

对于JSF 2.3，只需分别用 2_2和 2.2替换 2_3和 2.3。
您并非偶然导入了 javax.annotation.ManagedBean而不是 javax.faces.bean.ManagedBean。使用IDE自动完成功能当心，众所周知Eclipse会自动建议错误的列表中的第一项。
您没有在完全相同的后备bean类上使用 @ManagedBean中的JSF 1.x样式 <managed-bean>条目覆盖 faces-config.xml以及不同的托管bean名称。该优先于 @ManagedBean。从JSF 2.0开始，不必在 faces-config.xml中注册托管bean，只需删除它即可。
您的运行时类路径是干净的，并且没有与JSF API相关的JAR中的重复项。确保您没有混合使用多个JSF实现（Mojarra和MyFaces）。当目标容器已将JSF API捆绑在包装盒中时，请确保您不在Web应用程序中提供其他JSF甚至Java EE API JAR文件。另请参阅 "Installing JSF" section of our JSF wiki page以获取JSF安装说明。如果您打算从WAR而不是在容器本身中升级容器绑定的JSF，请确保已指示目标容器使用WAR捆绑的JSF API / impl。
如果要将JSF托管的bean打包在JAR中，请确保JAR至少具有与JSF 2.0兼容的 /META-INF/faces-config.xml。另见 How to reference JSF managed beans which are provided in a JAR file?
如果您实际上是在使用侏罗纪的JSF 1.x，并且无法升级，则需要通过 <managed-bean>在 faces-config.xml而不是 @ManagedBean中注册Bean。不要忘记修复项目构建路径，以使您不再拥有JSF 2.x库（这样， @ManagedBean批注就不会令人困惑地成功编译）。




如果是CDI通过 @Named管理bean，那么您需要确保以下几点：


为了在WAR中启用CDI，CDI 1.0（Java EE 6）需要一个 /WEB-INF/beans.xml文件。它可以为空，也可以仅包含以下内容：

<?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>

没有任何 beans.xml或空 beans.xml文件或具有与上述CDI 1.0兼容的 beans.xml的 CDI 1.1 (Java EE 7)的行为与CDI 1.0相同。当存在与CDI 1.1兼容的 beans.xml带有显式 version="1.1"时，默认情况下，它将仅注册具有显式CDI范围注释的 @Named bean，例如 @RequestScoped， @ViewScoped， @SessionScoped， @ApplicationScoped ，等等。如果您打算将所有bean注册为CDI托管bean，即使没有明确的CDI范围的bean，也请使用以下与CDI 1.1兼容的 /WEB-INF/beans.xml设置为 bean-discovery-mode="all"（默认为 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>

将CDI 1.1+与 bean-discovery-mode="annotated"一起使用（默认）时，请确保您没有意外导入JSF范围（例如 javax.faces.bean.RequestScoped）而不是CDI范围 javax.enterprise.context.RequestScoped。使用IDE自动完成功能当心。
当将Mojarra 2.3.0-2.3.2和CDI 1.1+与 bean-discovery-mode="annotated"（默认）一起使用时，由于 bug，您需要将Mojarra升级到2.3.3或更高版本。如果您无法升级，则需要在 bean-discovery-mode="all"中设置 beans.xml，或将JSF 2.3特定的 @FacesConfig批注放在WAR中的任意类上（通常是某种应用程序范围的启动类）。
Tomcat和Jetty等非Java EE容器未附带捆绑的CDI。您需要手动安装。与添加库JAR相比，这需要做更多的工作。对于Tomcat，请确保遵循以下答案中的指示信息： How to install and use CDI on Tomcat?
您的运行时类路径是干净的，并且没有与CDI API相关的JAR中的重复项。确保您没有混合使用多种CDI实现（Weld，OpenWebBeans等）。当目标容器已将CDI API打包为开箱即用时，请确保不要在webapp上提供其他CDI甚至Java EE API JAR文件。
如果要在JAR中将CDI托管的bean用于JSF视图包装，则请确保JAR至少具有有效的 /META-INF/beans.xml（可以将其保留为空）。




如果是Spring通过 @Component管理Bean，那么您需要确保以下几点：


Spring已按照 its documentation进行安装和集成。重要的是，您至少需要在 web.xml中包含以下内容：

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

这在 faces-config.xml中：

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

（以上是我对Spring的了解-我不做Spring-随时编辑/评论其他可能与Spring相关的原因；例如，一些与XML配置有关的麻烦）




如果它是一个转发器组件，则通过其 var属性（例如， <h:dataTable var="item">， <ui:repeat var="item">， <p:tabView var="item">等）管理（嵌套的）bean，而您实际上得到了“ Target Unreachable，标识符'item'解析为null”，那么您需要确保以下几点：


在所有子组件的 #{item}属性中均未引用 binding。这是不正确的，因为 binding属性在视图构建时而不是视图渲染时运行。而且，组件树中实际上只有一个组件，在每个迭代回合中都可以简单地重用该组件。换句话说，您实际上应该使用 binding="#{bean.component}"而不是 binding="#{item.component}"。但是更好的方法是完全摆脱组件装箱到bean的问题，并针对您认为要解决的问题研究/提出正确的方法。另见 How does the 'binding' attribute work in JSF? When and how should it be used?




1b。 （默认）托管Bean名称是什么？

第二步将是检查已注册的受管Bean名称。 JSF和Spring使用约定遵循 JavaBeans specification，而CDI具有依赖于CDI实施/版本的异常。


如下所示的 FooBean支持bean类，

@Named
public class FooBean {}

根据JavaBeans规范，所有bean管理框架中的默认托管bean名称都为 #{fooBean}。
如下所示的 FOOBean支持bean类，

@Named
public class FOOBean {}

在JSF和Spring中，其不合格的类名至少以两个大写字母开头将具有与不合格的类名 #{FOOBean}完全相同的默认受管Bean名称，并且也符合JavaBeans规范。在CDI中，2015年6月之前发布的Weld版本中也是如此，但由于 an oversight in CDI spec，在2015年6月之后发布的Weld版本（2.2.14 / 2.3.0.B1 / 3.0.0.A9）或OpenWebBeans中也是如此。 。在那些Weld版本和所有OWB版本中，只有第一个字符小写的 #{fOOBean}。
如果您已明确指定一个托管Bean名称 foo，如下所示，

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

或与 @ManagedBean(name="foo")或 @Component("foo")等效，则它将仅由 #{foo}可用，因此， #{fooBean}将不可用。




1c。支持bean类在哪里？

第三步是仔细检查后备bean类是否在构建和部署的WAR文件中的正确位置。确保已正确执行了项目和服务器的完整清理，重建，重新部署和重新启动，以防您实际上正忙于编写代码并且不耐烦地在浏览器中按F5键。如果仍然徒劳，请让构建系统生成WAR文件，然后使用ZIP工具提取并检查该文件。支持Bean类的已编译 .class文件必须位于 /WEB-INF/classes中的其包结构中。或者，当将其打包为JAR模块的一部分时，包含已编译的 .class文件的JAR必须驻留在 /WEB-INF/lib中，因此不能例如位于EAR的 /lib或其他位置。

如果您使用的是Eclipse，请确保Backing bean类位于 src中，而不位于 WebContent中，并确保启用了Project> Build Automatically。如果使用的是Maven，请确保后备bean类在 src/main/java中，因此不在 src/main/resources或 src/main/webapp中。

如果要使用EJB + WAR将Web应用程序打包为EAR的一部分，则需要确保后备Bean类位于WAR模块中，因此不在EAR模块或EJB模块中。业务层（EJB）必须没有与任何Web层（WAR）相关的工件，以便该业务层可在多个不同的Web层（JSF，JAX-RS，JSP / Servlet等）之间重用。



2.无法到达目标，“实体”返回null

归结为嵌套属性 entity和 #{bean.entity.property}返回了 null。这通常仅在JSF需要通过如下所示的输入组件为 property设置值时公开，而 #{bean.entity}实际上返回了 null。

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

如果要在同一视图上使用CRUD列表和/或对话框，则需要确保事先使用 @PostConstruct或 <f:viewAction>方法，或者也许是 add()操作方法准备了模型实体。

@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();
    }

    // ...
}

关于 @PostConstruct的重要性；如果您使用的是使用 proxies的bean管理框架（例如CDI），则在常规构造函数中执行此操作将失败。始终使用 @PostConstruct钩住托管bean实例的初始化（并使用 @PreDestroy钩住托管bean实例的破坏）。此外，在构造函数中，您将无法访问任何注入的依赖项，另请参见 NullPointerException while trying to access @Inject bean in constructor。

如果 entityId是通过 <f:viewParam>提供的，则需要使用 <f:viewAction>而不是 @PostConstruct。另见 When to use f:viewAction / preRenderView versus PostConstruct?

您还需要确保在回发期间保留非 null模型，以防仅在 add()动作方法中创建它。最简单的方法是将bean放入视图范围。另见 How to choose the right bean scope?



3. Target Unreachable，“ null”返回null

实际上，这与＃2具有相同的原因，只是所使用的（较旧的）EL实现在保留要显示在异常消息中的属性名称时有些错误，最终错误地将其显示为“空”。仅当您具有类似 #{bean.entity.subentity.subsubentity.property}这样的嵌套属性时，这才使调试和修复变得困难。

解决方案仍然相同：确保所有级别的嵌套实体都不是 null。



4.无法到达目标，“ 0”返回null

这也与＃2具有相同的原因，只有正在使用的（较旧的）EL实现在制定异常消息时存在问题。仅当您像在 []中那样在EL中使用大括号表示法 #{bean.collection[index]}时（其中 #{bean.collection}本身非空，但指定索引处的项不存在）时，此方法才会显示。然后，必须将此类消息解释为：


  目标无法访问，“ collection [0]”返回null


解决方案也与＃2相同：确保收集项可用。



5. Target Unreachable，'BracketSuffix'返回null

这实际上与＃4具有相同的原因，只是使用的（较旧的）EL实现在保留要显示在异常消息中的迭代索引时有些错误，最终错误地显示为'BracketSuffix'，它实际上是字符 ] 。当您在集合中有多个项目时，这只会使调试和修复工作更加困难。



javax.el.PropertyNotFoundException的其他可能原因：


javax.el.ELException: Error reading 'foo' on type com.example.Bean
javax.el.ELException: Could not find property actionMethod in class com.example.Bean
javax.el.PropertyNotFoundException: Property 'foo' not found on type com.example.Bean
javax.el.PropertyNotFoundException: Property 'foo' not readable on type java.lang.Boolean
javax.el.PropertyNotFoundException: Property not found on type org.hibernate.collection.internal.PersistentSet
Outcommented Facelets code still invokes EL expressions like #{bean.action()} and causes javax.el.PropertyNotFoundException on #{bean.action}