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

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?

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 así #{bean}.

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

a. ¿Quién está manejando el frijol?
si. ¿Cuál es el nombre de bean administrado (predeterminado)?
C. ¿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 vía @ManagedBean? ¿O es a través de CDI@Named ? ¿O es Spring via @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 JSF bean gestionado?

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

• La faces-config.xmldeclaración raíz es compatible con JSF 2.0. Por lo tanto, el archivo XSD y el versiondeben al menos especificar 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_0y 2.0por 2_1y2.1 respectivamente.

  Si utiliza JSF 2.2 o superior, asegúrese de utilizar xmlns.jcp.orgespacios de nombres en lugar de java.sun.comtodos 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_2y 2.2por 2_3y 2.3respectivamente.

• No importaste accidentalmente en javax.annotation.ManagedBeanlugar dejavax.faces.bean.ManagedBean . Tenga cuidado con el autocompletado IDE, se sabe que Eclipse sugiere automáticamente el incorrecto como primer elemento de la lista.

• No reemplazó la entrada de @ManagedBeanestilo JSF 1.x en la misma clase de bean de respaldo junto con un nombre de bean administrado diferente. Este tendrá prioridad sobre . No es necesario registrar un bean administrado desde JSF 2.0, simplemente elimínelo.<managed-bean>faces-config.xml@ManagedBeanfaces-config.xml
• 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 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 JSF 2.0 compatible /META-INF/faces-config.xml. Consulte también ¿Cómo hacer referencia a los beans gestionados JSF que se proporcionan en un archivo JAR?

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

  ---

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

• CDI 1.0 (Java EE 6) requiere un /WEB-INF/beans.xml archivo 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 ninguno beans.xml, o un beans.xmlarchivo vacío , o con el CDI 1.0 anterior compatible beans.xmlse comportará igual que CDI 1.0. Cuando hay un CDI 1.1 compatible beans.xmlcon una explícita version="1.1", entonces será por defecto registro de sólo @Namedgranos con un CDI anotación explícita alcance tales como @RequestScoped, @ViewScoped, @SessionScoped,@ApplicationScoped , etc. En caso de que la intención de registrar a todos los granos como CDI habas logró, incluso aquellos sin una explícita Alcance CDI, use el CDI 1.1 a continuación compatible /WEB-INF/beans.xmlcon el bean-discovery-mode="all"conjunto (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 ámbito JSF como, por ejemplo, en javax.faces.bean.RequestScopedlugar de un ámbito CDI javax.enterprise.context.RequestScoped. Cuidado con el autocompletado IDE.

• Cuando se usa 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 error . En caso de que no se puede actualizar, entonces usted necesita ya sea a conjunto bean-discovery-mode="all"en beans.xml, o para poner el concreto JSF 2.3 @FacesConfiganotación en una clase arbitraria en el GUERRA (generalmente algún tipo de aplicación en el ámbito clase de arranque).
• 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 la biblioteca JAR (s). 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 los JAR relacionados con la 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 valor válido /META-INF/beans.xml(que puede mantenerse vacío).

  ---

En caso de que sea Spring quien gestione el bean a través de@Component , entonces 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, siéntase libre de editar / comentar con otras causas probables relacionadas con Spring; por ejemplo, algunos problemas relacionados con la configuración de XML)

  ---

En caso de que sea un componente repetidor quién administra el grano (anidado) a través de su varatributo (por ejemplo <h:dataTable var="item">, <ui:repeat var="item">,<p:tabView var="item"> , etc.) y que en realidad tiene un "objetivo inalcanzable, identificador 'tema' resuelto nulo", entonces usted necesita para asegurarse de lo siguiente :

• No #{item}se hace referencia a la bindingatribución de ningún componente secundario. Esto es incorrecto ya que el bindingatributo se ejecuta durante el tiempo de construcció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ías estar usando en binding="#{bean.component}"lugar de binding="#{item.component}". Pero mucho mejor es deshacerse por completo de la unión de componentes a 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 FooBeanclase de bean de respaldo como a continuación,

  @Named
  public class FooBean {}

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

• Una FOOBeanclase de bean de respaldo como a continuación,

  @Named
  public class FOOBean {}

  cuyo nombre de clase no calificado comience 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 una supervisión 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 foocomo el siguiente,

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

  o equivalentemente 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 .classarchivo compilado de la clase de bean de respaldo debe residir en su estructura de paquete en /WEB-INF/classes. O bien, cuando está empaquetado como parte de un módulo JAR, el JAR que contiene el .classarchivo compilado debe residir /WEB-INF/liby, por lo tanto, no, por ejemplo, EAR/lib ni en ningún otro lugar.

Si está utilizando Eclipse, asegúrese de que la clase de bean de respaldo esté dentro srcy, por lo tanto WebContent, no , 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/javay por lo tanto no en src/main/resourceso 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 propiedad anidadaentity como en #{bean.entity.property}devuelto null. Esto generalmente solo se expone cuando JSF necesita establecer el valor a propertytravés de un componente de entrada como el siguiente, mientras que en #{bean.entity}realidad se devuelve null.

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

Debe asegurarse de haber preparado la entidad modelo de antemano en un método @PostConstructo <f:viewAction>método, o tal vez un add()método de acción en caso de que esté trabajando con listas y / o cuadros de diálogo CRUD 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. Siempre use @PostConstructpara conectar la inicialización de la instancia de bean administrado (y use @PreDestroypara 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, consulte también NullPointerException al intentar acceder a @Inject bean en el constructor .

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

También debe asegurarse de preservar el no nullmodelo durante las devoluciones en caso de que lo esté creando solo con un add()método de acción. Lo más fácil sería poner el bean en el alcance de la vista. Consulte 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 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 tienes algunas propiedades anidadas como esta#{bean.entity.subentity.subsubentity.property} .

La solución sigue siendo la misma: asegúrese de que la entidad anidada en cuestión no lo 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 llaves []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 de 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 personaje ]. 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:

• javax.el.ELException: Error al leer 'foo' en el tipo com.example.Bean
• javax.el.ELException: no se pudo encontrar la propiedad actionMethod en la clase com.example.Bean
• javax.el.PropertyNotFoundException: propiedad 'foo' no encontrada en el tipo com.example.Bean
• javax.el.PropertyNotFoundException: la propiedad 'foo' no se puede leer en el tipo java.lang.Boolean
• javax.el.PropertyNotFoundException: propiedad no encontrada en el tipo org.hibernate.collection.internal.PersistentSet
• El código de Facelets comentados aún invoca expresiones EL como # {bean.action ()} y causa javax.el.PropertyNotFoundException en # {bean.action}

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.

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 al construir un Proyecto de Aplicación Empresarial (EAR) con 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 con el botón derecho en el proyecto POM principal y seleccione Propiedades . Aparece 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.

Me quedé atrapado en este error porque en la clase que tiene @SpringBootApplicationolvidé especificar el nombre del paquete del controlador.

Esta vez quería ser más específico al señalar qué componentes tenía que escanear Spring, en lugar de configurar el paquete base.

Fue así:

@ComponentScan(basePackages = {"br.com.company.project.repository", "br.com.company.project.service"})

Pero la forma correcta es una de estas:

@ComponentScan(basePackages = {"br.com.company.project.repository", "br.com.company.project.service", "br.com.company.project.controller"})

@ComponentScan(basePackages = {"br.com.company.project")

Decidí compartir mi solución, porque aunque la respuesta correcta es muy completa, no cubre este error (idiota) :)

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 mi problema fuera de las soluciones explicadas. 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.

Yo tuve el mismo problema. La solución resultó ser mucho más simple. Parece que una tabla de datos quiere 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.

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.

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() {}

Acabo de probarlo sin ningún constructor y esto parece funcionar también.

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

Verifiqué respuestas valiosas a @BalusC y a los otros compartidores, pero superé el problema de esta manera 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.

Cuando elimino el parámetro de contexto AnnotationConfigWebApplicationContext del archivo web.xml Esto es trabajo

Si tiene como param que, como se muestra a continuación, debe eliminarlo del archivo web.xml

<context-param>
    <param-name>contextClass</param-name>
    <param-value>
      org.springframework.web.context.support.AnnotationConfigWebApplicationContext
  </param-value>
</context-param> 

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>

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.

EL interpreta $ {bean.propretyName} como se describe: el propertyName se convierte en getPropertyName () en el supuesto de 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 ...".

En mi caso, faltaba "el-ri-1.0.jar".