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实现在保留要显示在异常消息中的属性名称时有些错误，最终会错误地显示为“ null”。只有当您具有诸如#{bean.entity.subentity.subsubentity.property}这样的嵌套属性时，这才使调试和修复变得更加困难。

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



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

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


  无法到达目标，“ collection [0]”返回null


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



5.无法到达目标，“ 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}