Тип API variable-resolver устарел после JSF 1.1. Вместо этого используйте el-resolver

#java #jsf #websphere-portal #ibm-rad #ibm-jsf

Вопрос:

Недавно мы обновили WebSphere Portal с версии 6.1 до версии 7.0, и в процессе у нас теперь есть JSF 1.2. Создание нового проекта портлета в Rad 8 создает faces-config.xml со следующей записью

 <application>
    <state-manager>com.ibm.faces.application.DevelopmentStateManager</state-manager>
    <variable-resolver>com.ibm.faces.portlet.PortletVariableResolver</variable-resolver>
</application>

А затем жалуется: Type API variable-resolver устарел после JSF 1.1. Вместо этого используйте el-resolver.

К сожалению, я не смог найти ответ на страницах IBM, какой el-resolver использовать.

Редактировать:

 System.out.println("Resolver: "   PortalUtil.getFacesContext().getApplication().getELResolver());

=> Распознаватель: com.sun.faces.el.FacesCompositeELResolver@696e696e

Добавление записи в faces-config

 <el-resolver>com.sun.faces.el.FacesCompositeELResolver</el-resolver>

С удалением или без удаления преобразователя переменных приводит к:

 java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory
    at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:270)
    at javax.faces.webapp.FacesServlet.init(FacesServlet.java:164)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:358)
    ... 89 more

Открыт PMR с IBM…

1. Это не помогает? download.oracle.com/docs/cd/E17802_01/products/products/jsp/2.1 /…

2. Предупреждающее сообщение от RAD: класс javax.el.ELResolver должен быть конкретным (не абстрактным).

3. Мы используем Spring, и есть org.springframework.web.jsf.DelegatingVariableResolver . Он работает нормально. Может быть, попробуйте добавить зависимость для этого преобразователя? Поместите его как <распознаватель переменных> org.springframework.web.jsf.DelegatingVariableResolver </распознаватель переменных>

Ответ №1:

Ответ IBMs на PMR:

Вопрос — Каковы могут быть последствия игнорирования предупреждения?

Пользователь все еще может использовать распознаватель переменных, функциональность не будет затронута. [Этот тег будет сохранен для обратной совместимости]

Вопрос — Почему сгенерированный faces-config.xml все еще используете устаревший метод?

Ответ: Мы используем распознаватель переменных для разрешения переменных портлета, который будет хорошо работать даже с JSF 1.2

Вопрос — Будет ли или есть el-распознаватель для портлетов?

И еще — для портлетов будет el-распознаватель. Он будет предоставлен в JSF portlet bridge 2.0, который будет отправлен как обновление для WAS. В настоящее время он находится на стадии планирования, поэтому я не могу дать вам точную версию, в которой это будет найдено.

Ответ №2:

Мне неприятно это говорить, но если мы говорим об асинхронном веб-приложении, то вы мертвы в воде.

В JSF 1.2 появилась «известная ошибка» (мне всегда нравилась эта фраза) — это FaceletsRenderer класс, который не позволяет вам асинхронно отображать компоненты JSF (потому что все aynchronousity в JSF использует поддельный FacesContext ; не функциональный, который можно использовать для рендеринга). Для этого вам нужен JSF 2.1, дружественный к JEE6, в противном случае вам понадобится совсем другое решение, как @D1e указано в его / ее комментарии. Удачи вашей организации.

1. Я в замешательстве, как асинхронные веб-приложения могут быть связаны с этим вопросом. Тем более, что stacktrace содержит FacesServlet.init , который выполняется перед любой обработкой запроса.

2. Hm вообще не использует Facelets.