Pretty faces config issues on WebSphere Application server - JSF2

Question

"Error 500: com.ocpsoft.pretty.PrettyFilter incompatible with javax.servlet.Filter"

• JSF2.1.2
• Prettyfaces-jsf2-3.3.2
• Primefaces 3.2
• WebSphere Application Server 7.0.0.9

Tried with adding custom properties in WebSphere admin console for filter compatibility(Last in FAQ at http://ocpsoft.org/prettyfaces/). Tomcat 6.0.32 don't have any issues but once deployed the app in WAS got the issue.

Below is webxml

<context-param>
    <param-name>defaultHtmlEscape</param-name>
    <param-value>true</param-value>
</context-param>

<context-param>
    <param-name>com.sun.faces.numberOfViewsInSession</param-name>
    <param-value>3</param-value>
</context-param>

<context-param>
    <param-name>com.sun.faces.numberOfLogicalViews</param-name>
    <param-value>10</param-value>
</context-param>

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>classpath*:WEB-INF/Controller-servlet.xml</param-value>
</context-param>

<context-param>
    <param-name>com.sun.faces.expressionFactory</param-name>
    <param-value>com.sun.el.ExpressionFactoryImpl</param-value>
</context-param>

 <context-param>
    <description>JSF Injection provider</description>
    <param-name>com.sun.faces.injectionProvider</param-name>
    <param-value>net.devgrok.jsf.Tomcat6GuiceInjectionProvider</param-value>
</context-param>

<context-param>
    <param-name>primefaces.THEME</param-name>
    <param-value>cupertino</param-value>
</context-param>

<context-param>
    <param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>
    <param-value>false</param-value>
</context-param>

<context-param>
    <param-name>javax.faces.FULL_STATE_SAVING_VIEW_IDS</param-name>
    <param-value>abc.xhtml</param-value>
</context-param>

<!--  JSF Required Context Params END-->

<!--  JSF Required Filters & Listeners START-->
<filter>
    <filter-name>PrimeFaces FileUpload Filter</filter-name>
    <filter-class>org.primefaces.webapp.filter.FileUploadFilter</filter-class>
    <init-param>
        <param-name>thresholdSize</param-name>
        <param-value>1048576000</param-value><!--51200-->
    </init-param>
    <init-param>
        <param-name>uploadDirectory</param-name>
        <param-value>/temp</param-value>
    </init-param>
</filter>

<filter-mapping>
    <filter-name>PrimeFaces FileUpload Filter</filter-name>
    <servlet-name>Faces Servlet</servlet-name>
</filter-mapping>
<!-- Creates the Spring Container shared by all Servlets and Filters -->

<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<filter>
    <filter-name>Pretty Filter</filter-name>
    <filter-class>com.ocpsoft.pretty.PrettyFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>Pretty Filter</filter-name>
    <url-pattern>/*</url-pattern>
    <dispatcher>FORWARD</dispatcher>
    <dispatcher>REQUEST</dispatcher>

</filter-mapping>

<!--  JSF Required Filters & Listeners END-->

<!--  JSF Required Servlets START -->

<servlet>
    <servlet-name>Faces Servlet</servlet-name>
    <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>Faces Servlet</servlet-name>
    <url-pattern>*.jsf</url-pattern>
</servlet-mapping>

Novercal

Answer 1

1. Changed war class loader order to "parent last" and policy to "Single class loader for application" in WebSphere admin console to pick apps own JSF version.

2. Removed the redundant jars (servlet-api.jar and xml-apis-1.0.b2.jar are in my case) from WEB-INF/Lib folder as it collides with server versions.

The above solved this issue. However creating Isolated shared library (https://mcmap.net/q/833027/-classloader-issue-in-websphere-application-server-7-x) would be better option when you have app-specific dependencies that may collide with server versions.

Novercal

Are you sure you had to change to "parent last"? Setting to "parent last" is known to trigger other classloading problems. – Brine

Having servletcontainer-specific libraries in webapp's /WEB-INF/lib will always form problems if that servletcontainer-specific library doesn't originate from the same servletcontainer as where you're deploying the webapp to. After all, you should never be doing that (forgive me) silly step. The servletcontainer itself already ships with the right Servlet API libraries. – Starwort