Идентификация и решение javax.el.PropertyNotFoundException: цель недостижима

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

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

  1. Цель недостижима, идентификатор 'bean' разрешен в ноль
  2. Цель недостижима, "сущность" вернула ноль
  3. Цель недостижима, "ноль" вернул ноль
  4. Цель недостижима, ''0'' вернул ноль
  5. Цель недостижима, 'BracketSuffix' возвратил ноль

Что они все значат? Как они вызваны и как они должны быть решены?

Источник

18 ответов

Решение

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

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

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

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

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

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

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

  • faces-config.xml Объявление root совместимо с 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, а не в самом контейнере, убедитесь, что вы указали целевому контейнеру использовать JSF API в комплекте с WAR /impl.
  • Если вы упаковываете управляемые bean-компоненты JSF в JAR, убедитесь, что JAR-версия имеет хотя бы JSF 2.0-совместимый /META-INF/faces-config.xml, См. Также Как ссылаться на управляемые bean-компоненты JSF, которые представлены в файле JAR?

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

В случае, если CDI управляет компонентом через @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 бины с явной аннотацией области видимости CDI, такой как @RequestScoped, @ViewScoped, @SessionScoped, @ApplicationScoped и т. д. Если вы намереваетесь зарегистрировать все bean-компоненты как управляемые CDI-компоненты, даже если они не имеют явной области действия CDI, используйте приведенную ниже совместимость с CDI 1.1. /WEB-INF/beans.xml с bean-discovery-mode="all" установить (по умолчанию bean-discovery-mode="annotated").

    <?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
                           http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
       version="1.1" bean-discovery-mode="all">
</beans>

  • При использовании CDI 1.1+ с bean-discovery-mode="annotated" (по умолчанию), убедитесь, что вы случайно не импортировали область JSF, такую ​​как javax.faces.bean.RequestScoped вместо объема CDI javax.enterprise.context.RequestScoped, Остерегайтесь с автозаполнением IDE.

  • При использовании Mojarra 2.3.0-2.3.2 и CDI 1.1+ с bean-discovery-mode="annotated" (по умолчанию), тогда вам нужно обновить 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-файл API Java EE, когда целевой контейнер уже связывает CDI API из коробки.

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

В случае, если это Spring, кто управляет бином через @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 Unreachable, идентификатор" item "разрешен до нуля", тогда вам необходимо убедиться в следующем:

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

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

Вторым шагом будет проверка зарегистрированного имени управляемого бина. Соглашения об использовании JSF и Spring соответствуют спецификации JavaBeans, в то время как CDI имеет исключения в зависимости от impl / версии 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 спец. В этих версиях Weld и во всех версиях OWB только первый символ в нижнем регистре #{fOOBean},

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

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

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

1c. Где класс бобов?

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

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

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

2. Цель недостижима, "сущность" вернула ноль

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

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

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

3. Цель недостижима, "ноль" вернул ноль

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

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

4. Цель недостижима, ''0'' вернул ноль

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

Цель недостижима, 'collection[0]' возвратила ноль

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

5. Цель недостижима, "BracketSuffix" вернул ноль

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

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

Источник

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

Используя 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 в папке domain1) и перезапустить сервер.

Источник

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

Источник

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

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

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

Решение:

Чтобы разрешить "Target Unreachable, идентификатор" bean "разрешен в ноль",

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

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

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

Источник

Я застрял на этой ошибке, потому что в классе с @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")

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

Источник

Это также может быть ошибкой в ​​Mojarra 2.3 https://github.com/eclipse-ee4j/mojarra/issues/4734

Источник

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

@Inject public VisitorBean() {}

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

Источник

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

CommandButton работал без поиска, что делало его еще более запутанным.

Источник

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

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

Источник

Во-первых, я работаю с: Eclipse, Weblogic, CDI, JSF, PrimeFaces. Если вы тоже, возможно, мое решение может вам помочь.

В моем случае причиной ошибки была небольшая настройка «Затмения».

Проверь это:

  1. Щелкните правой кнопкой мыши свой сервер Weblogic на вкладке «Серверы».
  2. Выберите "Свойства"
  3. В новом маленьком окне "Свойства" разверните меню "Weblogic".
  4. В меню «Weblogic» нажмите на опцию «Публикация».
  5. Теперь, с правой стороны, убедитесь, что опция «Опубликовать как развернутый архив» отмечена.

В моем случае я проверил «Опубликовать как виртуальное приложение», поэтому, изменив это, я решил ошибку «Target Unreachable».

Источник

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

Источник

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

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

<context-param>
    <param-name>contextClass</param-name>
    <param-value>
      org.springframework.web.context.support.AnnotationConfigWebApplicationContext
  </param-value>
</context-param>
Источник

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

Источник

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

<body>

пометить с

<h:body>

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

Источник

Работа с 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() при условии, что вы используете явные или неявные методы генерации getter/setters

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

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

Источник

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

Источник
Другие вопросы по тегам