Type API variable-resolver is deprecated after JSF 1.1. Use el-resolver instead

Question

We recently upgraded from WebSphere Portal v6.1 to v7.0 and in the process we now have JSF 1.2 available. Creating a new Portlet project in Rad 8 creates a faces-config.xml with the following entry

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

And then complains: Type API variable-resolver is deprecated after JSF 1.1. Use el-resolver instead.

Unfortunately i could not find an answer on the IBM pages which el-resolver to use.

Edit:

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

=> Resolver: com.sun.faces.el.FacesCompositeELResolver@696e696e

Adding an entry in faces-config

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

With or without removing the variable-resolver leads to:

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 with IBM opened ...

Acrobatic

Is this of no help? download.oracle.com/docs/cd/E17802_01/products/products/jsp/2.1/… – Robison

Warning message from RAD: Class javax.el.ELResolver must be concrete (not abstract). – Acrobatic

We use Spring, and there is org.springframework.web.jsf.DelegatingVariableResolver. It works fine. Maybe try adding a dependency for this resolver? Put it like <variable-resolver> org.springframework.web.jsf.DelegatingVariableResolver </variable-resolver> – Srinagar

Answer 1

IBMs response to the PMR:

Q - What might be the consequences of ignoring the warning?

Ans - User can still use variable resolver, the functionality will not be affected. [This tag will be maintained for backwards compatibility]

Q - Why does the generated faces-config.xml still use the deprecated method ?

Ans - We are using variable resolver to resolve the portlet variables, which would work well even with JSF 1.2

Q - Will there be or is there an el-resolver for portlets?

Ans - There will be an el-resolver for portlets. It will be provided in JSF portlet bridge 2.0 which will be shipped as an update to WAS. It is currently in the planning stages so I cannot give you a precise version that this will be found in.

Acrobatic

Answer 2

I hate to say it, but if we're talking about an asynchronous web application, then you're dead in the water.

JSF 1.2 introduced a "known bug" (I always loved that phrase) is the FaceletsRenderer class that prevents you from asynchronously rendering JSF components (because all aynchronousity in JSF uses a faked FacesContext; not a functional one that can be used for rendering). You need JEE6-friendly JSF 2.1 for that, otherwise you'll need a different solution altogether, as @D1e pointed out in his/her comment. Best of luck to your organization.

Itinerate

I'm confused, how asynchronous web apps could be related to the question. Especially since the stacktrace contains FacesServlet.init which is executed before any request processing. – Villose

Hm not using Facelets at all. – Acrobatic