При попытке сослаться на управляемый bean-компонент в EL подобным образом #{bean.entity.property}иногда возникает javax.el.PropertyNotFoundException: Target Unreachableисключение, обычно когда должно быть установлено свойство bean-компонента или когда должно быть вызвано действие bean-компонента.

Кажется, есть пять разных типов сообщений:

1. Target Unreachable, идентификатор bean разрешен до нуля
2. Target Unreachable, 'entity' вернул null
3. Target Unreachable, 'null' вернул null
4. Target Unreachable, '0' вернул null
5. Target Unreachable, 'BracketSuffix' вернул null

Что все они означают? Как они возникают и как их решать?

1. Цель недостижима, идентификатор bean преобразован в нуль

Это сводится к тому, что сам экземпляр управляемого компонента не может быть найден точно по этому идентификатору (имени управляемого компонента) в EL, например #{bean}.

Выявление причины можно разбить на три этапа:

а. Кто управляет бином?
б. Какое имя (по умолчанию) управляемого bean-компонента?
с. Где бин-класс поддержки?

1a. Кто управляет бином?

Первым шагом будет проверка того, какая структура управления компонентами отвечает за управление экземпляром компонента. Это JSF через @ManagedBean? Или это через CDI@Named ? Или это Spring через @Component? Можете ли вы убедиться, что вы не смешиваете несколько аннотаций, специфичных для инфраструктуры управления компонентами, в одном и том же классе вспомогательного компонента? Например @Named @Component, или @Named @ManagedBean, или @ManagedBean @Component. Это не верно. Компонент должен управляться не более чем одной структурой управления компонентом, и эта структура должна быть правильно настроена. Если вы уже не знаете, что выбрать, перейдите к Backing beans (@ManagedBean) или CDI Beans (@Named)? и интеграция Spring JSF: как внедрить компонент / службу Spring в управляемый компонент JSF?

В случае, если JSF управляет компонентом через @ManagedBean, вам необходимо убедиться в следующем:

• 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 автоматически предлагает неправильный элемент в качестве первого элемента в списке.

• Вы не переопределили запись в @ManagedBeanстиле JSF 1.x <managed-bean>в faces-config.xmlтом же самом классе вспомогательного компонента вместе с другим именем управляемого компонента. Этот будет иметь приоритет перед @ManagedBean. faces-config.xmlНачиная с JSF 2.0 регистрировать управляемый компонент не требуется, просто удалите его.
• Путь к классам среды выполнения чистый и не содержит дубликатов в JAR-файлах, связанных с JSF API. Убедитесь, что вы не смешиваете несколько реализаций JSF (Mojarra и MyFaces). Убедитесь, что вы не предоставляете другой JSF-файл или даже JAR-файл Java EE API вместе с веб-приложением, когда целевой контейнер уже включает в себя JSF API из коробки. См. Также раздел «Установка JSF» на нашей вики-странице JSF для получения инструкций по установке JSF. Если вы собираетесь обновить JSF, связанный с контейнером, с WAR, а не в самом контейнере, убедитесь, что вы проинструктировали целевой контейнер использовать связанный с WAR JSF API / impl.
• Если вы упаковываете управляемые компоненты JSF в JAR, убедитесь, что JAR имеет как минимум JSF 2.0 совместимый /META-INF/faces-config.xml. См. Также Как ссылаться на управляемые компоненты JSF, которые содержатся в файле JAR?

• Если вы на самом деле используете jurassic JSF 1.x и не можете выполнить обновление, вам необходимо зарегистрировать компонент через <managed-bean>in faces-config.xmlвместо @ManagedBean. Не забудьте исправить путь сборки проекта как таковой, чтобы у вас больше не было библиотек JSF 2.x (чтобы @ManagedBeanаннотация не могла успешно компилироваться).

  ---

Если это CDI, который управляет bean-компонентом через @Named, вам необходимо убедиться в следующем:

• CDI 1.0 (Java EE 6) требует /WEB-INF/beans.xmlфайла для включения CDI в WAR. Он может быть пустым или иметь только следующее содержимое:

  <?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", то он по умолчанию будет регистрировать только @Namedбобы с явной КДИ области видимости аннотации , такие как @RequestScoped, @ViewScoped, @SessionScoped, @ApplicationScopedи т.д. В случае , если вы собираетесь регистрировать все бобы в качестве КДИ управляемых компонентов, даже без явного Область CDI, используйте приведенный ниже CDI 1.1, совместимый /WEB-INF/beans.xmlс bean-discovery-mode="all"set (по умолчанию 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"(по умолчанию) вам необходимо обновить Mojarra до 2.3.3 или новее из-за ошибки . В случае , если вы не можете обновить, то вам нужно либо набор bean-discovery-mode="all"в beans.xml, или поставить JSF 2.3 конкретную @FacesConfigаннотацию произвольного класса в WAR ( как правило , своего рода приложением запуска класс область действия).
• Контейнеры, отличные от Java EE, такие как Tomcat и Jetty, не поставляются с CDI в комплекте. Вам нужно установить его вручную. Это немного больше, чем просто добавление библиотеки JAR (ов). Для Tomcat убедитесь, что вы следуете инструкциям в этом ответе: Как установить и использовать CDI на Tomcat?
• Путь к классам среды выполнения чистый и не содержит дубликатов в JAR-файлах, связанных с API CDI. Убедитесь, что вы не смешиваете несколько реализаций CDI (Weld, OpenWebBeans и т. Д.). Убедитесь, что вы не предоставляете другой файл CDI или даже JAR-файл Java EE API вместе с webapp, если целевой контейнер уже включает в себя CDI API из коробки.

• Если вы упаковываете bean-компоненты, управляемые CDI, для представлений JSF в JAR, убедитесь, что JAR имеет по крайней мере действительный /META-INF/beans.xml(который можно оставить пустым).

  ---

Если это Spring, которая управляет bean-компонентом через @Component, вам необходимо убедиться в следующем:

• Spring устанавливается и интегрируется в соответствии с его документацией . Что немаловажно, вам нужно как минимум это иметь 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">и т.д.) , и вы на самом деле получили «Target недостижима, идентификатор„элемент“решил нуль», то вам необходимо убедиться в следующем :

• #{item}Не упоминается в bindingattribtue любого дочернего компонента. Это неверно, поскольку bindingатрибут запускается во время построения представления, а не во время визуализации представления. Более того, физически в дереве компонентов есть только один компонент, который просто повторно используется во время каждой итерации. Другими словами, вы действительно должны использовать binding="#{bean.component}"вместо binding="#{item.component}". Но гораздо лучше вообще избавиться от связывания компонентов с bean-компонентом и изучить / задать вопрос о подходящем подходе к проблеме, которую вы думали решить таким образом. См. Также Как работает атрибут «привязка» в JSF? Когда и как его использовать?

  ---

1б. Какое имя (по умолчанию) управляемого bean-компонента?

Вторым шагом будет проверка имени зарегистрированного управляемого компонента. Соглашения об использовании JSF и Spring соответствуют спецификации JavaBeans, в то время как CDI имеет исключения в зависимости от имп / версии CDI.

• FooBeanКласс поддержки боба , как показано ниже,

  @Named
  public class FooBean {}

  будет во всех средах управления компонентами иметь имя управляемого компонента по умолчанию #{fooBean}в соответствии со спецификацией JavaBeans.

• FOOBeanКласс поддержки боба , как показано ниже,

  @Named
  public class FOOBean {}

  чье неквалифицированное имя класса начинается, по крайней мере, с двух заглавных букв, будет в JSF и Spring иметь имя управляемого компонента по умолчанию, точно совпадающее с неквалифицированным именем класса #{FOOBean}, также соответствует спецификации JavaBeans. В CDI это также относится к версиям Weld, выпущенным до июня 2015 года, но не к версиям Weld, выпущенным после июня 2015 года (2.2.14 / 2.3.0.B1 / 3.0.0.A9), или к OpenWebBeans из-за недосмотра в CDI spec . В этих версиях Weld и во всех версиях OWB только первый символ в нижнем регистре #{fOOBean}.

• Если вы явно указали имя управляемого bean-компонента, fooкак показано ниже,

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

  или, что эквивалентно с @ManagedBean(name="foo")или @Component("foo"), тогда он будет доступен только от, #{foo}а не от #{fooBean}.

  ---

1c. Где бин-класс поддержки?

Третий шаг - это двойная проверка, находится ли поддерживающий класс bean-компонента в нужном месте в созданном и развернутом WAR-файле. Убедитесь, что вы правильно выполнили полную очистку, перестройку, повторное развертывание и перезапуск проекта и сервера, на случай, если вы действительно были заняты написанием кода и нетерпеливым нажатием F5 в браузере. Если все еще напрасно, позвольте системе сборки создать файл WAR, который затем извлеките и изучите с помощью инструмента ZIP. Скомпилированный .classфайл класса вспомогательного компонента должен находиться в его структуре пакета в формате /WEB-INF/classes. Или, когда он упакован как часть модуля JAR, JAR, содержащий скомпилированный .classфайл, должен находиться в нем, /WEB-INF/libа не, например, в EAR /libили в другом месте.

Если вы используете Eclipse, убедитесь, что класс вспомогательного bean-компонента включен, srcа значит, нет WebContent , и убедитесь, что включен Project> Build Automatically . Если вы используете Maven, убедитесь, что поддерживающий класс bean-компонента находится внутри, src/main/javaа не в src/main/resourcesили src/main/webapp.

Если вы упаковываете веб-приложение как часть EAR с EJB + WAR (s), то вам необходимо убедиться, что классы вспомогательных компонентов находятся в модуле WAR, а, следовательно, не в модуле EAR или модуле EJB. Бизнес-уровень (EJB) должен быть свободен от каких-либо артефактов, связанных с веб-уровнем (WAR), чтобы бизнес-уровень можно было повторно использовать на нескольких разных веб-уровнях (JSF, JAX-RS, JSP / Servlet и т. Д.).

2. Target Unreachable, 'entity' вернул null

Это сводится к тому , что вложенной собственности entityкак в #{bean.entity.property}вернулся null. Обычно это проявляется только тогда, когда JSF необходимо установить значение propertyчерез компонент ввода, как показано ниже, в то время как #{bean.entity}фактически возвращается null.

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

Вы должны убедиться , что вы подготовили модель объект заранее в @PostConstruct, или <f:viewAction>метод, или , возможно, add()метод действия в случае , если вы работаете со списками CRUD и / или диалоговые окна на ту же точку зрения.

@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для подключения к инициализации экземпляра управляемого компонента (и @PreDestroyдля подключения к уничтожению экземпляра управляемого компонента). Кроме того, в конструкторе у вас еще не будет доступа ни к каким внедренным зависимостям, см. Также исключение NullPointerException при попытке доступа к @Inject bean в конструкторе .

В случае, если entityIdпоставляется через <f:viewParam>, вам нужно будет использовать <f:viewAction>вместо @PostConstruct. См. Также Когда использовать f: viewAction / preRenderView по сравнению с PostConstruct?

Вам также необходимо убедиться, что вы сохраняете немодель nullво время обратной передачи, если вы создаете ее только в add()методе действия. Проще всего было бы поместить компонент в область просмотра. См. Также Как выбрать правильную область применения фасоли?

3. Target Unreachable, "null" вернул null.

Фактически это имеет ту же причину, что и № 2, только используемая (более старая) реализация EL несколько ошибочна в сохранении имени свойства для отображения в сообщении об исключении, которое в конечном итоге неправильно отображается как «null». Это только немного усложняет отладку и исправление, когда у вас довольно много таких вложенных свойств #{bean.entity.subentity.subsubentity.property}.

Решение остается тем же: убедитесь, что рассматриваемая вложенная сущность отсутствует nullна всех уровнях.

4. Target Unreachable, «0» вернул null.

Это также имеет ту же причину, что и №2, только используемая (более старая) реализация EL содержит ошибки при формулировании сообщения об исключении. Это проявляется только тогда, когда вы используете нотацию фигурных скобок []в EL, например, #{bean.collection[index]}когда #{bean.collection}сам по себе не равен нулю, но элемент по указанному индексу не существует. Такое сообщение следует интерпретировать как:

Target Unreachable, 'collection [0]' вернул null

Решение также такое же, как и №2: убедитесь, что предмет коллекции доступен.

5. Target Unreachable, BracketSuffix вернул null.

Фактически это имеет ту же причину, что и # 4, только используемая (более старая) реализация EL несколько ошибочна в сохранении индекса итерации для отображения в сообщении об исключении, которое в конечном итоге неправильно отображается как 'BracketSuffix', что на самом деле является символом ]. Это только немного усложняет отладку и исправление, когда в коллекции несколько элементов.

Другие возможные причины javax.el.PropertyNotFoundException:

• javax.el.ELException: ошибка чтения 'foo' для типа com.example.Bean
• javax.el.ELException: не удалось найти свойство actionMethod в классе com.example.Bean
• javax.el.PropertyNotFoundException: свойство 'foo' не найдено в типе com.example.Bean
• javax.el.PropertyNotFoundException: свойство 'foo' не читается для типа java.lang.Boolean
• javax.el.PropertyNotFoundException: свойство не найдено в типе org.hibernate.collection.internal.PersistentSet
• Закомментированный код Facelets по-прежнему вызывает выражения EL, такие как # {bean.action ()}, и вызывает исключение javax.el.PropertyNotFoundException на # {bean.action}

Для тех, кто еще застрял ...

При использовании NetBeans 8.1 и GlassFish 4.1 с CDI по какой-то причине у меня возникла эта проблема только локально, а не на удаленном сервере. В чем фокус:

-> с использованием javaee-web-api 7.0 вместо версии pom по умолчанию, предоставляемой NetBeans, то есть javaee-web-api 6.0, поэтому:

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

-> загрузите этот javaee-web-api-7.0.jar как lib на сервер (папка lib в папке domain1) и перезапустите сервер.

Я решил поделиться своими выводами об этой ошибке после того, как решил ее сам.

Прежде всего, следует серьезно отнестись к решениям BalusC, но есть еще одна вероятная проблема в Netbeans, о которой следует помнить, особенно при создании проекта корпоративного приложения (EAR) с использованием Maven.

Netbeans генерирует, а POM файл родительского , в проект EAR , в проект EJB и проект WAR . Все остальное в моем проекте было в порядке, и я почти предположил, что проблема связана с ошибкой, вероятно, в GlassFish 4.0 (мне пришлось установить и подключить его к Netbeans), потому что GlassFish 4.1 имеет ошибку Weld CDI, которая делает встроенный GlassFish 4.1 в Netbeans 8.0. 2 непригодны, кроме как через патч.

Решение:

Для того, чтобы решить «Target UNREACHABLE, идентификатор„боб“решил нуль» error-

I Щелкните правой кнопкой мыши родительский проект POM и выберите " Свойства" . Появится диалоговое окно «Свойства проекта», нажмите «Источники». Вы будете удивлены, увидев, что « Исходный / двоичный формат » установлен на 1,5, а « Кодировка » - на Windows 1250. Измените « Исходный / двоичный формат » на 1,6 или 1,7, в зависимости от того, что вы предпочитаете, чтобы ваш проект был совместим с CDI, а « Кодировка » - в UTF-8.

Сделайте то же самое для всех других подпроектов (EAR, EJB, WAR), если они еще не совместимы. Запустите свой проект, и вы больше не получите эту ошибку.

Я надеюсь, что это поможет кому-то с подобной ошибкой.

Я решил поделиться своим решением, потому что, хотя многие ответы, представленные здесь, были полезны, у меня все еще была эта проблема. В моем случае я использую JSF 2.3, jdk10, jee8, cdi 2.0 для своего нового проекта, и я запустил свое приложение на wildfly 12, запустив сервер с параметром standalone.sh -Dee8.preview.mode = true, как рекомендовано на веб-сайте wildfly , После загрузки wildfly 13 проблема с «bean resolved to null» исчезла. После загрузки точно такой же войны в wildfly 13 все заработало.

Я застрял на этой ошибке, потому что в классе, который имеет, @SpringBootApplicationя забыл указать имя пакета контроллера.

На этот раз я хотел быть более конкретным, указав, какие компоненты Spring должен сканировать, а не настраивать базовый пакет.

Это было так:

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

Но правильная форма одна из этих:

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

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

Я решил поделиться своим решением, потому что, хотя правильный ответ очень исчерпывающий, он не покрывает эту (идиотскую) ошибку :)

В моем случае я допустил орфографическую ошибку в @Named ("beanName"), это должно было быть "beanName", но я, например, написал "beanNam".

Я использую wildfly 10 для контейнера javaee. У меня возникла проблема «Target Unreachable, 'entity' return null». Спасибо за предложения BalusC, но моя проблема из объясненных решений. Случайно используя "import com.sun.istack.logging.Logger;" вместо "import org.jboss.logging.Logger;" вызвал CDI, реализовал JSF EL. Надеюсь, это поможет улучшить решение.

У меня такая же проблема. Решение оказалось намного проще. Похоже, что объекту данных нужен метод в форме получателя, то есть getSomeMethod (), а не только someMethod (). В моем случае в таблице данных я вызывал findResults. Я изменил метод в моем вспомогательном компоненте на getFindResults (), и он сработал.

CommandButton работал с поиском без получения, что только усложняло задачу.

Что касается №2, то в моем случае он волшебным образом ожил после замены

<body>

пометить с

<h:body>

После того, как я выполнил несколько (более простых, если честно) проектов JSF, я не мог вспомнить, чтобы делал что-то другое, настраивая его сейчас, и впервые получил такую ​​ошибку. Я делал очень простую страницу входа (имя пользователя, пароль, пользовательский компонент ...) и настраивал все как обычно. Единственное различие, которое я заметил, - это вышеупомянутые теги. Может, кому-то это пригодится.

Проблема в моем случае заключалась в том, что я включил конструктор, принимающий параметры, но не пустой конструктор с аннотацией Inject, например.

@Inject public VisitorBean() {}

Я только что протестировал его без конструктора, и это тоже работает.

Для 1. темы ( цель недостижима, идентификатор bean разрешен в нуль );

Я проверил ценные ответы @BalusC и других участников, но я превышаю эту проблему в своем сценарии. После создания нового xhtml с другим именем и создания класса bean-компонента с другим именем я написал (не копируя и вставив) коды шаг за шагом в новый класс bean-компонента и новый файл xhtml.

Когда я удаляю параметр контекста AnnotationConfigWebApplicationContext из файла web.xml Это работа

Если у вас есть подобный параметр, который, как показано ниже, вы должны удалить его из файла web.xml.

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

Работа с JSF в старом стиле Вы должны определить управляемый компонент в файле beans-config.xml (расположенном в папке WEB-INF) и сделать ссылку на него в файле web.xml следующим образом:

бобы-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>

(Я пробовал использовать другие прицелы, но ...)

web.xml

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

Еще одна подсказка: я использовал JSF и добавил зависимости 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>

Затем я попытался перейти на Primefaces и добавить зависимость Primefaces:

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

Я изменил свой xhtml с h: на p:, добавив xmlns: p = "http://primefaces.org/ui в шаблон. Только с JSF проект работал нормально, и управляемый бин был достигнут нормально. Когда я добавляю Primefaces Я получал недостижимый объект (javax.el.propertynotfoundexception). Проблема заключалась в том, что JSF генерировал ManagedBean, а не Primefaces, и я запрашивал простые лица для объекта. Мне пришлось удалить jsf-impl из моего .pom, чистый и установить проект. С этого момента все прошло нормально. Надеюсь, это поможет.

EL интерпретирует $ {bean.propretyName}, как описано - propertyName становится getPropertyName () в предположении, что вы используете явные или неявные методы генерации методов получения / установки.

Вы можете изменить это поведение, явно указав имя как функцию: $ {bean.methodName ()} Это вызывает метод функции Name () напрямую без изменений.

Не всегда верно, что ваши методы доступа называются "get ...".

В моем случае отсутствовал "el-ri-1.0.jar".