unreachable returned resuelto resolved persona objetivo nulo inalcanzable identificador devolvió bindings jsf cdi el managed-bean propertynotfoundexception

jsf - returned - Identificar y resolver javax.el.PropertyNotFoundException: Target Unreachable



objetivo inalcanzable identificador persona resuelto a nulo (13)

1. Destino inalcanzable, identificador ''bean'' resuelto a nulo

Esto se reduce a que la instancia de bean administrado en sí no se pudo encontrar exactamente por ese identificador (nombre de bean administrado) en EL como así #{bean} .

La identificación de la causa se puede dividir en tres pasos:

a. ¿Quién está manejando el frijol?
segundo. ¿Cuál es el nombre de bean administrado (predeterminado)?
do. ¿Dónde está la clase de bean de respaldo?

1a. ¿Quién está manejando el frijol?

El primer paso sería verificar qué marco de administración de beans es responsable de administrar la instancia de bean. ¿Es JSF a través de @ManagedBean ? ¿O es CDI a través de @Named ? ¿O es primavera a través de @Component ? ¿Puede asegurarse de que no está mezclando anotaciones específicas del marco de administración de múltiples beans en la misma clase de bean de respaldo? Por ejemplo, @Named @Component , o @Named @ManagedBean , o @ManagedBean @Component . Esto está mal. El bean debe ser administrado como máximo por un marco de administración de bean y ese marco debe estar configurado correctamente. Si ya no tiene idea de cuál elegir, diríjase a Backing beans (@ManagedBean) o CDI Beans (@Named)? e integración Spring JSF: ¿cómo inyectar un componente / servicio Spring en el bean administrado JSF?

En caso de que sea JSF quien administre el bean a través de @ManagedBean , entonces debe asegurarse de lo siguiente:

  • La declaración raíz faces-config.xml es compatible con JSF 2.0. Por lo tanto, el archivo XSD y la version deben especificar al menos JSF 2.0 o superior y, por lo tanto, no 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">

    Para JSF 2.1, simplemente reemplace 2_0 y 2.0 por 2_1 y 2.1 respectivamente.

    Si utiliza JSF 2.2 o superior, asegúrese de utilizar xmlns.jcp.org nombres xmlns.jcp.org lugar de java.sun.com en todos los lugares.

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

    Para JSF 2.3, simplemente reemplace 2_2 y 2.2 por 2_3 y 2.3 respectivamente.

  • No importó accidentalmente javax.annotation.ManagedBean lugar de @ManagedBean . Tenga cuidado con el autocompletado IDE, se sabe que Eclipse sugiere automáticamente el incorrecto como primer elemento de la lista.

  • No @ManagedBean por una entrada <managed-bean> estilo JSF 1.x en faces-config.xml en la misma clase de bean de respaldo junto con un nombre de bean administrado diferente. Este tendrá prioridad sobre @ManagedBean . No es necesario registrar un bean administrado en faces-config.xml desde JSF 2.0, simplemente elimínelo.
  • Su classpath en tiempo de ejecución está limpio y libre de duplicados en JAR relacionados con API JSF. Asegúrese de no mezclar múltiples implementaciones JSF (Mojarra y MyFaces). Asegúrese de no proporcionar otro archivo JAR JSF API o Java EE API junto con la aplicación web cuando el contenedor de destino ya incluye la API JSF de fábrica. Consulte también la sección "Instalación de JSF" de nuestra página wiki de JSF para obtener instrucciones de instalación de JSF. En caso de que tenga la intención de actualizar JSF empaquetado en contenedor desde WAR en lugar de en el contenedor en sí, asegúrese de haber indicado al contenedor de destino que use API / impl JSF empaquetado en WAR.
  • Si empaqueta beans gestionados JSF en un JAR, asegúrese de que el JAR tenga al menos un / /META-INF/faces-config.xml compatible con JSF 2.0. Consulte también ¿Cómo hacer referencia a los beans gestionados JSF que se proporcionan en un archivo JAR?

  • Si realmente está utilizando el JSF jurásico 1.x, y no puede actualizar, entonces necesita registrar el bean a través de <managed-bean> en faces-config.xml lugar de @ManagedBean . No olvide corregir la ruta de compilación de su proyecto de modo que ya no tenga las bibliotecas JSF 2.x (para que la anotación @ManagedBean no se compile con éxito de forma confusa).

En caso de que sea CDI quien administre el bean a través de @Named , entonces debe asegurarse de lo siguiente:

  • CDI 1.0 (Java EE 6) requiere un archivo /WEB-INF/beans.xml para habilitar CDI en WAR. Puede estar vacío o puede tener solo el siguiente contenido:

    <?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) sin beans.xml , o un archivo beans.xml vacío, o con los beans.xml compatibles con CDI 1.0 anteriores se comportarán igual que CDI 1.0. Cuando hay beans.xml compatibles con CDI 1.1 con una version="1.1" explícita version="1.1" , por defecto solo registrará @Named beans con una anotación explícita de alcance CDI como @RequestScoped , @ViewScoped , @SessionScoped , @ApplicationScoped , etc. En caso de que desee registrar todos los beans como beans administrados por CDI, incluso aquellos sin un alcance CDI explícito, use el siguiente CDI 1.1 compatible /WEB-INF/beans.xml con bean-discovery-mode="all" set (el valor predeterminado es 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>

  • Cuando use CDI 1.1+ con bean-discovery-mode="annotated" (predeterminado), asegúrese de no importar accidentalmente un alcance JSF como javax.faces.bean.RequestScoped lugar de un alcance CDI @RequestScoped . Cuidado con el autocompletado IDE.

  • Cuando use Mojarra 2.3.0-2.3.2 y CDI 1.1+ con bean-discovery-mode="annotated" (predeterminado), entonces necesita actualizar Mojarra a 2.3.3 o posterior debido a un bug . En caso de que no pueda actualizar, entonces necesita establecer bean-discovery-mode="all" en beans.xml , o colocar la anotación @FacesConfig específica de JSF 2.3 en una clase arbitraria en WAR (generalmente algún tipo de una clase de inicio de ámbito de aplicación).
  • Los contenedores que no son Java EE como Tomcat y Jetty no se entregan con CDI incluido. Necesita instalarlo manualmente. Es un poco más de trabajo que simplemente agregar los JAR de la biblioteca. Para Tomcat, asegúrese de seguir las instrucciones de esta respuesta: ¿Cómo instalar y usar CDI en Tomcat?
  • Su classpath en tiempo de ejecución está limpio y libre de duplicados en JAR relacionados con API CDI. Asegúrese de no mezclar múltiples implementaciones de CDI (Weld, OpenWebBeans, etc.). Asegúrese de no proporcionar otro CDI o incluso un archivo JAR API Java EE a lo largo de la aplicación web cuando el contenedor de destino ya incluye la API CDI de fábrica.

  • Si está empaquetando beans gestionados CDI para vistas JSF en un JAR, asegúrese de que el JAR tenga al menos un /META-INF/beans.xml válido (que se puede mantener vacío).

En caso de que sea Spring quien administre el bean a través de @Component , debe asegurarse de lo siguiente:

  • Spring se está instalando e integrando según su documentación . Es importante destacar que al menos debe tener esto en web.xml :

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

    Y esto en faces-config.xml :

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

  • (lo anterior es todo lo que sé con respecto a Spring - No hago Spring - no dude en editar / comentar con otras causas probables relacionadas con Spring; por ejemplo, algunos problemas relacionados con la configuración XML)

En caso de que sea un componente repetidor el que esté manejando el bean (anidado) a través de su atributo var (por ejemplo, <h:dataTable var="item"> , <ui:repeat var="item"> , <p:tabView var="item"> , etc.) y en realidad obtuviste un "Objeto de destino inalcanzable, ''elemento'' de identificador resuelto como nulo", entonces debes asegurarte de lo siguiente:

  • No se hace referencia al #{item} en binding atribución de enlace de ningún componente secundario. Esto es incorrecto ya binding atributo de binding ejecuta durante el tiempo de creación de la vista, no durante el tiempo de representación de la vista. Además, físicamente solo hay un componente en el árbol de componentes que simplemente se reutiliza durante cada ronda de iteración. En otras palabras, en realidad debería estar usando binding="#{bean.component}" lugar de binding="#{item.component}" . Pero mucho mejor es deshacerse por completo de la unión de componentes al bean e investigar / preguntar el enfoque adecuado para el problema que pensó resolver de esta manera. Consulte también ¿Cómo funciona el atributo ''vinculante'' en JSF? ¿Cuándo y cómo debe usarse?

1b. ¿Cuál es el nombre de bean administrado (predeterminado)?

El segundo paso sería verificar el nombre de bean administrado registrado. Las convenciones de uso de JSF y Spring cumplen con la especificación JavaBeans, mientras que CDI tiene excepciones dependiendo de la versión / impl CDI.

  • Una clase de bean de respaldo FooBean como a continuación,

    @Named public class FooBean {}

    en todos los marcos de administración de #{fooBean} tendrá un nombre de bean administrado predeterminado de #{fooBean} , según la especificación de JavaBeans.

  • Una clase de bean de respaldo FOOBean como a continuación,

    @Named public class FOOBean {}

    cuyo nombre de clase no calificado comienza con al menos dos mayúsculas tendrá en JSF y Spring un nombre de bean administrado predeterminado exactamente del nombre de clase no calificado #{FOOBean} , también se ajusta a la especificación JavaBeans. En CDI, este también es el caso en las versiones de Weld lanzadas antes de junio de 2015, pero no en las versiones de Weld lanzadas después de junio de 2015 (2.2.14 / 2.3.0.B1 / 3.0.0.A9) ni en OpenWebBeans debido a un descuido en CDI spec . En esas versiones de Weld y en todas las versiones de OWB solo es con el primer carácter en minúscula #{fOOBean} .

  • Si ha especificado explícitamente un nombre de bean administrado como a continuación,

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

    o de manera equivalente con @ManagedBean(name="foo") o @Component("foo") , entonces solo estará disponible por #{foo} y, por lo tanto, no por #{fooBean} .

1c. ¿Dónde está la clase de bean de respaldo?

El tercer paso sería una doble verificación si la clase de bean de respaldo está en el lugar correcto en el archivo WAR construido e implementado. Asegúrese de haber realizado correctamente una limpieza completa, reconstruir, volver a implementar y reiniciar el proyecto y el servidor en caso de que estuviera realmente ocupado escribiendo código y presionando impacientemente F5 en el navegador. Si todavía es en vano, deje que el sistema de compilación produzca un archivo WAR, que luego extrae e inspecciona con una herramienta ZIP. El archivo compilado .class de la clase de bean de respaldo debe residir en su estructura de paquete en /WEB-INF/classes . O, cuando está empaquetado como parte de un módulo JAR, el JAR que contiene el archivo compilado .class debe residir en /WEB-INF/lib y, por lo tanto, no, por ejemplo, EAR''s /lib u otro lugar.

Si está utilizando Eclipse, asegúrese de que la clase de bean de respaldo esté en src y, por lo tanto, no de WebContent , y asegúrese de que Project> Build Automatically esté habilitado. Si está utilizando Maven, asegúrese de que la clase de bean de respaldo esté en src/main/java y, por lo tanto, no en src/main/resources o src/main/webapp .

Si está empaquetando la aplicación web como parte de un EAR con EJB + WAR (s), entonces debe asegurarse de que las clases de beans de respaldo estén en el módulo WAR y, por lo tanto, no en el módulo EAR ni en el módulo EJB. El nivel empresarial (EJB) debe estar libre de artefactos relacionados con el nivel web (WAR), de modo que el nivel empresarial sea reutilizable en varios niveles web diferentes (JSF, JAX-RS, JSP / Servlet, etc.).

2. Destino inalcanzable, ''entidad'' devuelta nulo

Esto se reduce a que la entity propiedad anidada como en #{bean.entity.property} devolvió null . Esto generalmente solo se expone cuando JSF necesita establecer el valor de la property través de un componente de entrada como el siguiente, mientras que el #{bean.entity} realidad devuelve null .

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

@PostConstruct asegurarse de haber preparado la entidad modelo de antemano en un @PostConstruct , o un @PostConstruct <f:viewAction> , o tal vez un método de acción add() en caso de que esté trabajando con listas CRUD y / o cuadros de diálogo en la misma vista .

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

En cuanto a la importancia de @PostConstruct ; hacer esto en un constructor normal fallaría en caso de que esté utilizando un marco de administración de beans que usa proxies , como CDI. Utilice siempre @PostConstruct para conectar la inicialización de la instancia de bean administrado (y use @PreDestroy para conectar la destrucción de la instancia de bean administrado). Además, en un constructor aún no tendría acceso a ninguna dependencia inyectada, vea también NullPointerException al intentar acceder a @Inject bean en el constructor .

En caso de que el entityId se suministre a través de <f:viewParam> , deberá usar <f:viewAction> lugar de @PostConstruct . Consulte también ¿ Cuándo usar f: viewAction / preRenderView versus PostConstruct?

También debe asegurarse de conservar el modelo no null durante las devoluciones en caso de que lo esté creando solo con un método de acción add() . Lo más fácil sería poner el bean en el alcance de la vista. Vea también ¿Cómo elegir el alcance de frijol correcto?

3. Objetivo inalcanzable, ''nulo'' devuelto nulo

En realidad, esto tiene la misma causa que el n. ° 2, solo la implementación de EL (más antigua) que se está utilizando es algo defectuosa para preservar el nombre de la propiedad que se mostrará en el mensaje de excepción, que finalmente se expone incorrectamente como ''nulo''. Esto solo hace que la depuración y la corrección sean un poco más difíciles cuando tiene algunas propiedades anidadas como #{bean.entity.subentity.subsubentity.property} .

La solución sigue siendo la misma: asegúrese de que la entidad anidada en cuestión no sea null , en todos los niveles.

4. Destino inalcanzable, '''' 0 '''' devuelto nulo

Esto también tiene la misma causa que el n. ° 2, solo la implementación de EL (más antigua) que se usa tiene errores al formular el mensaje de excepción. Esto se expone solo cuando usa la notación de #{bean.collection[index]} [] en EL como en #{bean.collection[index]} donde el #{bean.collection} sí mismo no es nulo, pero el elemento en el índice especificado no existe. Dicho mensaje debe interpretarse como:

Destino inalcanzable, ''colección [0]'' devuelto nulo

La solución también es la misma que la n.º 2: asegúrese de que el elemento de la colección esté disponible.

5. Objetivo inalcanzable, ''BracketSuffix'' devuelto nulo

En realidad, esto tiene la misma causa que el n. ° 4, solo la implementación EL (más antigua) que se está utilizando es un poco defectuosa para preservar el índice de iteración para mostrar en el mensaje de excepción, que finalmente se expone incorrectamente como ''BracketSuffix'', que es realmente el carácter ] . Esto solo hace que la depuración y la reparación sean un poco más difíciles cuando tienes varios elementos en la colección.

Otras posibles causas de javax.el.PropertyNotFoundException :

Cuando se trata de hacer referencia a un bean administrado en EL como así #{bean.entity.property} , a veces se javax.el.PropertyNotFoundException: Target Unreachable una javax.el.PropertyNotFoundException: Target Unreachable , generalmente cuando se establece una propiedad de bean o cuando se ejecuta una acción de bean es ser invocado

Parece que hay cinco tipos diferentes de mensajes:

  1. Destino inalcanzable, identificador ''bean'' resuelto a nulo
  2. Destino inalcanzable, ''entidad'' devuelta nulo
  3. Objetivo inalcanzable, ''nulo'' devuelto nulo
  4. Objetivo inalcanzable, '''' 0 '''' devuelto nulo
  5. Objetivo inalcanzable, ''BracketSuffix'' devuelto nulo

a que se refieren ellos? ¿Cómo se causan y cómo se deben resolver?

Decidí compartir mi hallazgo sobre este error después de resolverlo yo mismo.

En primer lugar, las soluciones de BalusC deben tomarse en serio, pero luego hay otro problema probable en Netbeans que debe tener en cuenta especialmente cuando se construye un Proyecto de Aplicación Empresarial (EAR) utilizando Maven.

Netbeans genera, un archivo POM principal , un proyecto EAR , un proyecto EJB y un proyecto WAR . Todo lo demás en mi proyecto estuvo bien, y casi asumí que el problema es probablemente un error en GlassFish 4.0 (tuve que instalarlo y conectarlo a Netbeans) porque GlassFish 4.1 tiene un error de CDI de soldadura que hace que GlassFish 4.1 incrustado en Netbeans 8.0. 2 inutilizables excepto a través de un parche.

Solución:

Para resolver el error "Destino inalcanzable, identificador ''bean'' resuelto a nulo"

I Haga clic derecho en el proyecto POM principal y seleccione Propiedades . Aparecerá un cuadro de diálogo de propiedades del proyecto, haga clic en "Fuentes", se sorprenderá al ver el " Formato de origen / binario " en 1.5 y " Codificación " en Windows 1250. Cambie el " Formato de origen / binario " a 1.6 0r 1.7, lo que sea prefiere hacer que su proyecto sea compatible con CDI y " Codificar " en UTF-8.

Haga lo mismo para todos los demás subproyectos (EAR, EJB, WAR) si aún no son compartibles. Ejecute su proyecto y no volverá a recibir ese error.

Espero que esto ayude a alguien que tenga un error similar.

Decidí compartir mi solución, porque aunque muchas respuestas proporcionadas aquí fueron útiles, todavía tenía este problema. En mi caso, estoy usando JSF 2.3, jdk10, jee8, cdi 2.0 para mi nuevo proyecto y ejecuté mi aplicación en wildfly 12, iniciando el servidor con el parámetro standalone.sh -Dee8.preview.mode = true como se recomienda en el sitio web de wildfly . El problema con "bean resuelto a nulo" desapareció después de descargar wildfly 13. Subir exactamente la misma guerra a wildfly 13 hizo que todo funcionara.

EL interpreta $ {bean.propretyName} como se describe: el propertyName se convierte en getPropertyName () suponiendo que está utilizando métodos explícitos o implícitos para generar getter / setters

Puede anular este comportamiento identificando explícitamente el nombre como una función: $ {bean.methodName ()} Esto llama al método de función Name () directamente sin modificación.

No siempre es cierto que sus accesores se denominen "get ...".

El problema en mi caso fue que incluí un constructor que tomaba parámetros pero no un constructor vacío con la anotación Inject, así.

@Inject public VisitorBean() {}

Lo acabo de probar sin ningún constructor y esto parece funcionar también.

En cuanto al número 2, en mi caso, mágicamente cobró vida después de reemplazar

<body>

etiqueta con

<h:body>

Después de haber realizado varios proyectos JSF (más simples, para ser sincero), no recordaba haber hecho nada diferente al configurarlo ahora, y recibí este tipo de error por primera vez. Estaba haciendo una página de inicio de sesión muy básica (nombre de usuario, contraseña, usuario Bean ...) y configuré todo como de costumbre. La única diferencia que vi son las etiquetas mencionadas anteriormente. Tal vez alguien encuentre esto útil.

En mi caso, cometí un error de hechizo en @Named ("beanName"), se suponía que era "beanName", pero escribí "beanNam", por ejemplo.

Estoy usando wildfly 10 para javaee container. Experimenté el problema "Objetivo inalcanzable, ''entidad'' devuelto nulo". Gracias por las sugerencias de BalusC, pero se explicó mi problema con las soluciones. Accidentalmente usando "import com.sun.istack.logging.Logger;" en lugar de "import org.jboss.logging.Logger;" causó CDI implementado JSF EL. Espero que ayude a mejorar la solución.

Otra pista: estaba usando JSF y agregué dependencias mvn: com.sun.faces jsf-api 2.2.11

<dependency> <groupId>com.sun.faces</groupId> <artifactId>jsf-impl</artifactId> <version>2.2.11</version> </dependency>

Luego, intenté cambiar a Primefaces y agregar dependencia de Primefaces:

<dependency> <groupId>org.primefaces</groupId> <artifactId>primefaces</artifactId> <version>6.0</version> </dependency>

Cambié mi xhtml de h: a p :, agregando xmlns: p = "http://primefaces.org/ui a la plantilla. Solo con JSF el proyecto se estaba ejecutando bien, y el bean gestionado se alcanzó bien. Cuando agregué Primefaces Estaba obteniendo el objeto inalcanzable (javax.el.propertynotfoundexception). El problema era que JSF estaba generando ManagedBean, no Primefaces, y estaba pidiendo primefaces para el objeto. Tuve que eliminar jsf-impl de mi .pom, limpiar y instale el proyecto. Todo salió bien desde este punto. Espero que ayude.

Para 1. tema ( Objetivo inalcanzable, el identificador ''bean'' se resolvió como nulo );

Verifiqué respuestas valiosas a @BalusC y a los otros compartidores, pero superé el problema como este en mi escenario. Después de crear un nuevo xhtml con un nombre diferente y crear una clase de bean con un nombre diferente, escribí (no copiar y pegar) los códigos paso a paso en la nueva clase de bean y el nuevo archivo xhtml.

Para aquellos que todavía están atrapados ...

Utilizando NetBeans 8.1 y GlassFish 4.1 con CDI, por alguna razón tuve este problema solo localmente, no en el servidor remoto. ¿Qué hizo el truco:

-> usando javaee-web-api 7.0 en lugar de la versión predeterminada de pom proporcionada por NetBeans, que es javaee-web-api 6.0, entonces:

<dependency> <groupId>javax</groupId> <artifactId>javaee-web-api</artifactId> <version>7.0</version> <scope>provided</scope> <type>jar</type> </dependency>

-> cargue este javaee-web-api-7.0.jar como lib en el servidor (carpeta lib en la carpeta dominio1) y reinicie el servidor.

Trabajar con JSF en el estilo antiguo Debe definir el bean administrado en el archivo beans-config.xml (ubicado en la carpeta WEB-INF) y hacer una referencia a él en el archivo web.xml , de esta manera:

beans-config.xml

<managed-bean> <managed-bean-name>"the name by wich your backing bean will be referenced"</managed-bean-name> <managed-bean-class>"your backing bean fully qualified class name"</managed-bean-class> <managed-bean-scope>session</managed-bean-scope> </managed-bean>

(He intentado usar otros ámbitos, pero ...)

web.xml

<context-param> <param-name>javax.faces.CONFIG_FILES</param-name> <param-value>"/WEB-INF/beans-config.xml</param-value> </context-param>

Yo tuve el mismo problema. La solución resultó ser mucho más simple. Parece que una tabla de datos desea el método en forma de getter, es decir, getSomeMethod (), no solo someMethod (). En mi caso en la tabla de datos, estaba llamando a findResults. Cambié el método en mi bean de respaldo a getFindResults () y funcionó.

Un comandoButton funcionó find sin el get, lo que sirvió para hacerlo más confuso.