识别和解决 javax.el.PropertyNotFoundException: Target Unreachable [英] Identifying and solving javax.el.PropertyNotFoundException: Target Unreachable

问题描述

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

When trying to reference a managed bean in EL like so #{bean.entity.property}, sometimes a javax.el.PropertyNotFoundException: Target Unreachable exception is being thrown, usually when a bean property is to be set, or when a bean action is to be invoked.

似乎有五种不同的消息:

There seem to be five different kinds of messages:

1. 目标无法访问，标识符 'bean' 解析为 null
2. 目标不可达，'实体'返回空
3. 目标不可达，'null'返回空
4. 目标不可达，''0''返回空
5. 目标不可达，'BracketSuffix' 返回空

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

What do they all mean? How are they caused and how should they be solved?

推荐答案

1.目标不可达，标识符bean"解析为空

这归结为托管 bean 实例本身无法通过 EL 中的标识符(托管 bean 名称)找到，就像 #{bean}.

确定原因可以分为三个步骤:

Identifying the cause can be broken down into three steps:

一个.谁在管理 bean?
湾什么是(默认)托管 bean 名称?
C.支持 bean 类在哪里?

a. Who's managing the bean?
b. What's the (default) managed bean name?
c. Where's the backing bean class?

第一步是检查哪个 bean 管理框架负责管理 bean 实例.是否通过 @CDI命名?或者是 JSF 通过 <代码>@ManagedBean?或者是 Spring 通过 @Component?你能确保你没有在同一个支持 bean 类上混合多个 bean 管理框架特定的注释吗?例如.@Named @ManagedBean、@Named @Component 或 @ManagedBean @Component.这是错误的.bean 必须由至多一个 bean 管理框架管理，并且必须正确配置该框架.如果您已经不知道选择哪个，请前往 支持 bean(@ManagedBean) 或 CDI Beans (@Named)? 和 Spring JSF 集成:如何在 JSF 托管 bean 中注入 Spring 组件/服务?

First step would be checking which bean management framework is responsible for managing the bean instance. Is it CDI via @Named? Or is it JSF via @ManagedBean? Or is it Spring via @Component? Can you make sure that you're not mixing multiple bean management framework specific annotations on the very same backing bean class? E.g. @Named @ManagedBean, @Named @Component, or @ManagedBean @Component. This is wrong. The bean must be managed by at most one bean management framework and that framework must be properly configured. If you already have no idea which to choose, head to Backing beans (@ManagedBean) or CDI Beans (@Named)? and Spring JSF integration: how to inject a Spring component/service in JSF managed bean?

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

In case it's CDI who's managing the bean via @Named, then you need to make sure of the following:

• CDI 1.0 (Java EE 6) 需要一个 /WEB-INF/beans.xml 文件才能在 WAR 中启用 CDI.它可以是空，也可以只有以下内容:

• CDI 1.0 (Java EE 6) requires an /WEB-INF/beans.xml file in order to enable CDI in WAR. It can be empty or it can have just the following content:

  <?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)没有任何 beans.xml 或空的 beans.xml 文件，或与上述 CDI 1.0 兼容的 beans.xml 的行为与CDI 1.0.如果存在 CDI 1.1 兼容的 beans.xml 和显式的 version=1.1"，那么默认情况下它只会注册 @Namedbean 带有显式 CDI 范围注释，例如 @RequestScoped, @ViewScoped, @SessionScoped, @ApplicationScoped 等.如果您打算将所有 bean 注册为 CDI 托管 bean，即使是那些没有显式 CDI 作用域的 bean，请使用下面的 CDI 1.1 兼容 <代码>/WEB-INF/beans.xml 带有 bean-discovery-mode="all" 设置(默认为 bean-discovery-mode="annotated").

CDI 1.1 (Java EE 7) without any beans.xml, or an empty beans.xml file, or with the above CDI 1.0 compatible beans.xml will behave the same as CDI 1.0. When there's a CDI 1.1 compatible beans.xml with an explicit version="1.1", then it will by default only register @Named beans with an explicit CDI scope annotation such as @RequestScoped, @ViewScoped, @SessionScoped, @ApplicationScoped, etc. In case you intend to register all beans as CDI managed beans, even those without an explicit CDI scope, use the below CDI 1.1 compatible /WEB-INF/beans.xml with bean-discovery-mode="all" set (the default is 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>

使用带有 bean-discovery-mode="annotated"(默认)的 CDI 1.1+ 时，请确保您没有意外导入 JSF 范围，例如 javax.faces.bean.RequestScoped 而不是 CDI 范围 javax.enterprise.context.RequestScoped.注意 IDE 自动完成功能.

When using CDI 1.1+ with bean-discovery-mode="annotated" (default), make sure that you didn't accidentally import a JSF scope such as javax.faces.bean.RequestScoped instead of a CDI scope javax.enterprise.context.RequestScoped. Watch out with IDE autocomplete.

当使用 Mojarra 2.3.0-2.3.2 和 CDI 1.1+ 和 bean-discovery-mode=annotated"(默认)时，你需要将 Mojarra 升级到 2.3由于 错误，.3 或更高版本.如果您无法升级，那么您需要在 beans.xml 中设置 bean-discovery-mode="all"，或者将 JSF 2.3 特定@FacesConfig WAR 中任意类的注解(通常是某种应用程序范围的启动类).

When using Mojarra 2.3.0-2.3.2 and CDI 1.1+ with bean-discovery-mode="annotated" (default), then you need to upgrade Mojarra to 2.3.3 or newer due to a bug. In case you can't upgrade, then you need either to set bean-discovery-mode="all" in beans.xml, or to put the JSF 2.3 specific @FacesConfig annotation on an arbitrary class in the WAR (generally some sort of an application scoped startup class).

在带有 web.xml 声明符合 Servlet 4.0 的 Servlet 4.0 容器上使用 JSF 2.3 时，您需要显式地放置 JSF 2.3 特定的 @FacesConfig WAR 中任意类的注释(通常是某种应用程序范围的启动类).这在 Servlet 3.x 中不是必需的.

When using JSF 2.3 on a Servlet 4.0 container with a web.xml declared conform Servlet 4.0, then you need to explicitly put the JSF 2.3 specific @FacesConfig annotation on an arbitrary class in the WAR (generally some sort of an application scoped startup class). This is not necessary in Servlet 3.x.

当使用 CDI 3.0 时，第一个版本的包从 javax.* 重命名为 jakarta.*，那么你需要确保所有的部署描述符文件beans.xml、web.xml、faces-config.xml 符合 新的jakartaee 模式，因此不符合旧的javaee 模式.

When using CDI 3.0, the first version with package renamed from javax.* to jakarta.*, then you need to ensure that all deployment descriptor files beans.xml, web.xml, faces-config.xml are conform the new jakartaee schemas and thus not conform the old javaee schemes.

  <?xml version="1.0" encoding="UTF-8"?>
  <beans xmlns="https://jakarta.ee/xml/ns/jakartaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee 
                             https://jakarta.ee/xml/ns/jakartaee/beans_3_0.xsd"
         version="3.0" bean-discovery-mode="all">
  </beans>

非 JEE 容器(如 Tomcat 和 Jetty)不附带捆绑的 CDI.您需要手动安装它.这比仅仅添加库 JAR(s) 要多一些工作.对于 Tomcat，请确保按照此答案中的说明进行操作:如何在Tomcat上安装和使用CDI?

您的运行时类路径是干净的，并且在 CDI API 相关的 JAR 中没有重复项.确保您没有混合多个 CDI 实现(Weld、OpenWebBeans 等).当目标容器已经捆绑了 CDI API 时，请确保不要在 webapp 中提供另一个 CDI 甚至 Java EE API JAR 文件.

Your runtime classpath is clean and free of duplicates in CDI API related JARs. Make sure that you're not mixing multiple CDI implementations (Weld, OpenWebBeans, etc). Make sure that you don't provide another CDI or even Java EE API JAR file along webapp when the target container already bundles CDI API out the box.

如果您在 JAR 中为 JSF 视图打包 CDI 托管 bean，则确保 JAR 至少具有有效的 /META-INF/beans.xml(可以保持为空).

If you're packaging CDI managed beans for JSF views in a JAR, then make sure that the JAR has at least a valid /META-INF/beans.xml (which can be kept empty).

如果 JSF 通过自 2.3 以来不推荐使用的 @ManagedBean 管理 bean，并且您无法迁移到 CDI，那么您需要确保以下:

In case it's JSF who's managing the bean via the since 2.3 deprecated @ManagedBean, and you can't migrate to CDI, then you need to make sure of the following:

• faces-config.xml 根声明与 JSF 2.0 兼容.因此 XSD 文件和 version 必须至少指定 JSF 2.0 或更高版本，因此不是 1.x.

• The faces-config.xml root declaration is compatible with JSF 2.0. So the XSD file and the version must at least specify JSF 2.0 or higher and thus not 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.

For JSF 2.1, just replace 2_0 and 2.0 by 2_1 and 2.1 respectively.

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

If you're on JSF 2.2 or higher, then make sure you're using xmlns.jcp.org namespaces instead of java.sun.com over all place.

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

For JSF 2.3, just replace 2_2 and 2.2 by 2_3 and 2.3 respectively.

您没有意外导入javax.annotation.ManagedBean 而不是 javax.faces.bean.ManagedBean.请注意 IDE 自动完成功能，众所周知，Eclipse 会自动建议错误的项目作为列表中的第一项.

You didn't accidentally import javax.annotation.ManagedBean instead of javax.faces.bean.ManagedBean. Watch out with IDE autocomplete, Eclipse is known to autosuggest the wrong one as first item in the list.

您没有通过 faces-config 中的 JSF 1.x 样式 条目覆盖 @ManagedBean.xml 与不同的托管 bean 名称位于相同的支持 bean 类上.这将优先于 @ManagedBean.从 JSF 2.0 开始，不需要在 faces-config.xml 中注册托管 bean，只需将其删除即可.

You didn't override the @ManagedBean by a JSF 1.x style <managed-bean> entry in faces-config.xml on the very same backing bean class along with a different managed bean name. This one will have precedence over @ManagedBean. Registering a managed bean in faces-config.xml is not necessary since JSF 2.0, just remove it.

您的运行时类路径是干净的，并且在与 JSF API 相关的 JAR 中没有重复项.确保您没有混合多个 JSF 实现(Mojarra 和 MyFaces).当目标容器已经捆绑了 JSF API 开箱即用时，请确保您没有在 webapp 中提供另一个 JSF 甚至 Java EE API JAR 文件.另请参阅安装 JSF"有关 JSF 安装说明，请参阅我们的 JSF wiki 页面部分.如果您打算从 WAR 升级容器捆绑的 JSF，而不是在容器本身中升级，请确保您已指示目标容器使用 WAR 捆绑的 JSF API/impl.

Your runtime classpath is clean and free of duplicates in JSF API related JARs. Make sure that you're not mixing multiple JSF implementations (Mojarra and MyFaces). Make sure that you don't provide another JSF or even Java EE API JAR file along webapp when the target container already bundles JSF API out the box. See also "Installing JSF" section of our JSF wiki page for JSF installation instructions. In case you intend to upgrade container-bundled JSF from the WAR on instead of in container itself, make sure that you've instructed the target container to use WAR-bundled JSF API/impl.

如果您将 JSF 托管 bean 打包到 JAR 中，请确保 JAR 至少具有与 JSF 2.0 兼容的/META-INF/faces-config.xml.另请参阅 如何引用 JAR 文件中提供的 JSF 托管 bean?

If you're packaging JSF managed beans in a JAR, then make sure that the JAR has at least a JSF 2.0 compatible /META-INF/faces-config.xml. See also How to reference JSF managed beans which are provided in a JAR file?

如果您实际上使用的是侏罗纪JSF 1.x，并且无法升级，那么您需要通过注册bean.faces-config.xml 中的 而不是 @ManagedBean.不要忘记修复您的项目构建路径，这样您就不再拥有 JSF 2.x 库(这样 @ManagedBean 批注不会混淆地成功编译).

If you're actually using the jurassic JSF 1.x, and you can't upgrade, then you need to register the bean via <managed-bean> in faces-config.xml instead of @ManagedBean. Don't forget to fix your project build path as such that you don't have JSF 2.x libraries anymore (so that the @ManagedBean annotation wouldn't confusingly successfully compile).

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

In case it's Spring who's managing the bean via @Component, then you need to make sure of the following:

• Spring 正在按照 其文档.重要的是，你至少需要在 web.xml 中有这个:

• Spring is being installed and integrated as per its documentation. Importantingly, you need to at least have this in 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 配置相关的问题)

如果它是一个 repeater 组件，它通过它的 var 属性(例如 、、等) 并且您实际上得到了目标无法访问，标识符‘项目’解析为空"，那么您需要确保以下几点:

In case it's a repeater component who's managing the (nested) bean via its var attribute (e.g. <h:dataTable var="item">, <ui:repeat var="item">, <p:tabView var="item">, etc) and you actually got a "Target Unreachable, identifier 'item' resolved to null", then you need to make sure of the following:

• #{item} 未在任何子组件的 binding 属性中引用.这是不正确的，因为 binding 属性在视图构建期间运行，而不是在视图渲染期间运行.此外，在组件树中物理上只有一个组件，它在每一轮迭代中都可以简单地重用.换句话说，您实际上应该使用 binding=#{bean.component}" 而不是 binding=#{item.component}".但更好的是完全摆脱组件绑定到 bean 并调查/询问您认为以这种方式解决的问题的正确方法.另见 'binding' 属性在 JSF 中是如何工作的?何时以及如何使用?

• The #{item} is not referenced in binding attribtue of any child component. This is incorrect as binding attribute runs during view build time, not during view render time. Moreover, there's physically only one component in the component tree which is simply reused during every iteration round. In other words, you should actually be using binding="#{bean.component}" instead of binding="#{item.component}". But much better is to get rid of component bining to bean altogether and investigate/ask the proper approach for the problem you thought to solve this way. See also How does the 'binding' attribute work in JSF? When and how should it be used?

第二步是检查注册的托管 bean 名称.JSF 和 Spring 使用约定符合 JavaBeans 规范，而 CDI 有例外，具体取决于关于 CDI 实施/版本.

Second step would be checking the registered managed bean name. JSF and Spring use conventions conform JavaBeans specification while CDI has exceptions depending on CDI impl/version.

• 一个 FooBean 支持 bean 类，如下所示，

• A FooBean backing bean class like below,

  @Named
  public class FooBean {}

将在所有 bean 管理框架中都有一个默认的托管 bean 名称 #{fooBean}，根据 JavaBeans 规范.

will in all bean management frameworks have a default managed bean name of #{fooBean}, as per JavaBeans specification.

一个 FOOBean 支持 bean 类，如下所示，

A FOOBean backing bean class like below,

  @Named
  public class FOOBean {}

其非限定类名至少以两个大写开头的人将在 JSF 和 Spring 中具有与非限定类名 #{FOOBean} 完全相同的默认托管 bean 名称，也符合 JavaBeans 规范.在 CDI 中，2015 年 6 月之前发布的 Weld 版本也是这种情况，但在 2015 年 6 月之后发布的 Weld 版本 (2.2.14/2.3.0.B1/3.0.0.A9) 和 OpenWebBeans 中都不是这种情况，因为 CDI 规范中的疏忽.在那些 Weld 版本和所有 OWB 版本中，它只有第一个字符小写 #{fOOBean}.

whose unqualified classname starts with at least two capitals will in JSF and Spring have a default managed bean name of exactly the unqualified class name #{FOOBean}, also conform JavaBeans specificiation. In CDI, this is also the case in Weld versions released before June 2015, but not in Weld versions released after June 2015 (2.2.14/2.3.0.B1/3.0.0.A9) nor in OpenWebBeans due to an oversight in CDI spec. In those Weld versions and in all OWB versions it is only with the first character lowercased #{fOOBean}.

如果您已经明确指定了一个托管 bean 名称 foo，如下所示，

If you have explicitly specified a managed bean name foo like below,

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

或等效于 @ManagedBean(name=foo") 或 @Component(foo")，那么它只能被 使用#{foo} 因此 not 来自 #{fooBean}.

or equivalently with @ManagedBean(name="foo") or @Component("foo"), then it will only be available by #{foo} and thus not by #{fooBean}.

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

Third step would be doublechecking if the backing bean class is at the right place in the built and deployed WAR file. Make sure that you've properly performed a full clean, rebuild, redeploy and restart of the project and server in case you was actually busy writing code and impatiently pressing F5 in the browser. If still in vain, let the build system produce a WAR file, which you then extract and inspect with a ZIP tool. The compiled .class file of the backing bean class must reside in its package structure in /WEB-INF/classes. Or, when it's packaged as part of a JAR module, the JAR containing the compiled .class file must reside in /WEB-INF/lib and thus not e.g. EAR's /lib or elsewhere.

如果您使用 Eclipse，请确保支持 bean 类在 src 中，因此 not WebContent，并确保项目 >自动构建 已启用.如果您使用 Maven，请确保支持 bean 类在 src/main/java 中，因此 not 在 src/main/resources 中> 或 src/main/webapp.

If you're using Eclipse, make sure that the backing bean class is in src and thus not WebContent, and make sure that Project > Build Automatically is enabled. If you're using Maven, make sure that the backing bean class is in src/main/java and thus not in src/main/resources or src/main/webapp.

如果您将 Web 应用程序打包为带有 EJB+WAR 的 EAR 的一部分，那么您需要确保支持 bean 类在 WAR 模块中，因此既不在 EAR 模块中也不在 EJB 模块中.业务层 (EJB) 必须没有任何与 Web 层 (WAR) 相关的工件，以便业务层可跨多个不同的 Web 层(JSF、JAX-RS、JSP/Servlet 等)重用.

If you're packaging the web application as part of an EAR with EJB+WAR(s), then you need to make sure that the backing bean classes are in WAR module and thus not in EAR module nor EJB module. The business tier (EJB) must be free of any web tier (WAR) related artifacts, so that the business tier is reusable across multiple different web tiers (JSF, JAX-RS, JSP/Servlet, etc).

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

This boils down to that the nested property entity as in #{bean.entity.property} returned null. This usually only exposes when JSF needs to set the value for property via an input component like below, while the #{bean.entity} actually returned null.

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

您需要确保在 @PostConstruct 或 方法或 方法中预先准备好模型实体add() 操作方法，以防您在同一视图上使用 CRUD 列表和/或对话框.

You need to make sure that you have prepared the model entity beforehand in a @PostConstruct, or <f:viewAction> method, or perhaps an add() action method in case you're working with CRUD lists and/or dialogs on same view.

@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的重要性；如果您使用的是使用 代理，例如 CDI.始终使用 @PostConstruct 来挂钩托管 bean 实例初始化(并使用 @PreDestroy 挂钩托管 bean 实例销毁).此外，在构造函数中，您还无法访问任何注入的依赖项，另请参见 NullPointerException 尝试访问构造函数中的@Inject bean .

As to the importance of @PostConstruct; doing this in a regular constructor would fail in case you're using a bean management framework which uses proxies, such as CDI. Always use @PostConstruct to hook on managed bean instance initialization (and use @PreDestroy to hook on managed bean instance destruction). Additionally, in a constructor you wouldn't have access to any injected dependencies yet, see also NullPointerException while trying to access @Inject bean in constructor.

如果 entityId 是通过 提供的，你需要使用 而不是 @PostConstruct.另请参阅何时使用 f:viewAction/preRenderView 与 PostConstruct?

In case the entityId is supplied via <f:viewParam>, you'd need to use <f:viewAction> instead of @PostConstruct. See also When to use f:viewAction / preRenderView versus PostConstruct?

您还需要确保在回发期间保留非 null 模型，以防您仅在 add() 操作方法中创建它.最简单的方法是将 bean 放在视图范围内.另请参阅如何选择正确的 bean 范围?

You also need to make sure that you preserve the non-null model during postbacks in case you're creating it only in an add() action method. Easiest would be to put the bean in the view scope. See also How to choose the right bean scope?

这实际上与 #2 的原因相同，只有使用的(较旧的)EL 实现在保留要在异常消息中显示的属性名称方面存在一些问题，最终错误地暴露为null".当您有相当多的嵌套属性时，这只会使调试和修复变得更加困难 #{bean.entity.subentity.subsubentity.property}.

This has actually the same cause as #2, only the (older) EL implementation being used is somewhat buggy in preserving the property name to display in the exception message, which ultimately incorrectly exposed as 'null'. This only makes debugging and fixing a bit harder when you've quite some nested properties like so #{bean.entity.subentity.subsubentity.property}.

解决方案仍然相同:确保所讨论的嵌套实体在所有级别都不是null.

The solution is still the same: make sure that the nested entity in question is not null, in all levels.

这也有与#2 相同的原因，只有正在使用的(旧的)EL 实现在制定异常消息时有问题.仅当您在 EL 中使用大括号表示法 [] 时才会公开，例如 #{bean.collection[index]} 其中 #{bean.collection} 本身非空，但指定索引处的项目不存在.这样的消息必须被解释为:

This has also the same cause as #2, only the (older) EL implementation being used is buggy in formulating the exception message. This exposes only when you use the brace notation [] in EL as in #{bean.collection[index]} where the #{bean.collection} itself is non-null, but the item at the specified index doesn't exist. Such a message must then be interpreted as:

目标不可达，'collection[0]' 返回空

Target Unreachable, 'collection[0]' returned null

解决方法也和#2一样:确保集合项可用.

The solution is also the same as #2: make sure that the collection item is available.

这实际上与 #4 的原因相同，只有使用的(较旧的)EL 实现在保留迭代索引以显示在异常消息中时有些错误，最终错误地暴露为真正的字符BracketSuffix"<代码>].当集合中有多个项目时，这只会使调试和修复更加困难.

This has actually the same cause as #4, only the (older) EL implementation being used is somewhat buggy in preserving the iteration index to display in the exception message, which ultimately incorrectly exposed as 'BracketSuffix' which is really the character ]. This only makes debugging and fixing a bit harder when you've multiple items in the collection.

• javax.el.E​​LException:在 com.example.Bean 类型上读取foo"时出错
• javax.el.E​​LException: 在类 com.example.Bean 中找不到属性 actionMethod
• javax.el.PropertyNotFoundException:在 com.example.Bean 类型上找不到属性foo"
• javax.el.PropertyNotFoundException:属性'foo' 在 java.lang.Boolean 类型上不可读
• javax.el.PropertyNotFoundException:在 org.hibernate.collection.internal.PersistentSet 类型上找不到属性
• 注释掉的 Facelets 代码仍然调用 EL表达式如 #{bean.action()} 并导致 #{bean.action}
上的 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}

这篇关于识别和解决 javax.el.PropertyNotFoundException: Target Unreachable的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！