2011-10-27 21 views
6

Recientemente actualizamos de WebSphere Portal v6.1 a v7.0 y en el proceso ahora tenemos disponible JSF 1.2. Creación de un nuevo proyecto de portlets en Rad 8 crea un faces-config.xml con la siguiente entradaType API variable-resolver está en desuso después de JSF 1.1. Use el-resolver en su lugar

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

Y luego se queja: Tipo API variable de resolución está en desuso después de JSF 1.1. Usa el-resolver en su lugar.

Desafortunadamente no pude encontrar una respuesta en las páginas de IBM que el-resolver usará.

Editar:

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

=> Resolver: [email protected]

Adición de una entrada en caras-config

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

Con o sin la eliminación la variable-resolver lleva a:

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 con IBM abrió ...

+0

¿Esto no sirve de nada? http://download.oracle.com/docs/cd/E17802_01/products/products/jsp/2.1/docs/jsp-2_1-pfd2/javax/el/ELResolver.html – Brad

+0

Mensaje de advertencia de RAD: Clase javax.el. ELResolver debe ser concreto (no abstracto). – Stefan

+0

Utilizamos Spring, y hay org.springframework.web.jsf.DelegatingVariableResolver. Funciona bien.Tal vez intente agregar una dependencia para este resolver? Ponlo como org.springframework.web.jsf.Delegating VariableResolver JMelnik

Respuesta

1

respuesta de IBM a la PMR:

Q - ¿Cuáles podrían ser las consecuencias de ignorar la advertencia?

Res - El usuario puede seguir utilizando la resolución de la variable, la funcionalidad no se verá afectada. [Esta etiqueta se mantendrá para compatibilidad con versiones anteriores]

Q - ¿Por qué faces-config.xml generado sigue usando el método en desuso?

Ans - Estamos utilizando la variable de resolución para resolver las variables de portlets, que funcionan bien incluso con JSF 1.2

Q - ¿Habrá o hay un EL-resolver los portlets?

Respuestas - Habrá una el-resolver para los portlets. Se proporcionará en JSF portlet bridge 2.0, que se enviará como una actualización de WAS. Actualmente se encuentra en las etapas de planificación, por lo que no puedo darle una versión precisa que se encontrará en.

0

me gusta decirlo, pero si estamos hablando de una aplicación web asíncrono, entonces estás muerto en el agua.

JSF 1.2 presenté un "error conocido" (Siempre me ha gustado esa frase) es la clase FaceletsRenderer que le impide la prestación de forma asíncrona componentes JSF (porque todos aynchronousity en JSF utiliza un fingidoFacesContext; no uno funcionales que pueden ser utilizado para renderizar). Necesita JSF 2.1 compatible con JEE6 para ese, de lo contrario necesitará una solución diferente, como @D1e señaló en su comentario. La mejor de las suertes para su organización.

+0

Estoy confundido, cómo las aplicaciones web asíncronas podrían estar relacionadas con la pregunta. Sobre todo porque stacktrace contiene 'FacesServlet.init' que se ejecuta antes de procesar cualquier solicitud. –

+0

Hm no usa Facelets en absoluto. – Stefan

Cuestiones relacionadas