Forcing Glassfish4 to use javax.faces-2.2.6.jar as module per domain using Maven pom.xml?

Question

Due to a bug in Mojarra 2.2.0 I'd like to use javax.faces-2.2.6.jar with Glassfish 4. It does work if I replace the existing /opt/glassfish4/glassfish/modules/javax.faces.jar but that would affect all apps in all domains.

I tried putting it at least in Glassfish's modules/endorsed/ directory but that had no effect.

Is it possible to replace the JSF implementation using Maven's pom.xml for just one application?

No, faces is included in the GlassFish modules library, which means it is a part of the installation. Why can't you simply install another instance of GlassFish that includes your desired Mojarra library? — codeturner, Apr 30 '14 at 20:35
Thanks for the answer. Well, of course I can just replace the jar but I'd rather wanted to enforce via pom.xml that my app does not start if Mojarra >= 2.2.6 is not found. Else the application suddenly gets buggy if deployed on e.g. a local glassfish on a collegues desktop. Now I will write a README.AppServer where I descript whatever is neccessary to prepare the Appserver for my application. — lathspell, May 02 '14 at 12:39

score 1 · Accepted Answer · answered May 03 '14 at 02:49

You can, of course, simply place the new javax.faces dependency within the pom.xml above your glassfish dependency to build your app. But this will not prevent someone from deploying to a non-customized glassfish install.

To prevent the application from running at all, you're going to have to do a library version check within a Filter and throw a ServletException if it doesn't match the expected version. This won't prevent a deployment, but this is the next most intrusive option since it all requests will respond with a ServletException.

For example:

import java.io.IOException;

import javax.faces.application.ResourceHandler;
import javax.faces.context.FacesContext;
import javax.servlet.DispatcherType;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.annotation.WebFilter;
import javax.servlet.http.HttpServletRequest;

@WebFilter(value = "/*", dispatcherTypes = { DispatcherType.REQUEST, DispatcherType.FORWARD })
public class RelativePathFacesFilter implements Filter {

    private static String EXPECTED_FACES_VERSION = "2.2.6";

    private String facesVersion;
    private boolean correctVersion;

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
        facesVersion = FacesContext.getCurrentInstance().getClass().getPackage().getImplementationVersion();
        correctVersion = EXPECTED_FACES_VERSION.equals(facesVersion);
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        if (!correctVersion) {
            throw new ServletException("Expected Faces version=" + EXPECTED_FACES_VERSION + ", but instead got " + facesVersion);
        }

        chain.doFilter(request, response);
    }

    @Override
    public void destroy() {
    }

}

Checking the JSF version in every single request might be overkill but as you example shows to to query the current implementation version number I mark it as correct answer. — lathspell, May 04 '14 at 13:21

Forcing Glassfish4 to use javax.faces-2.2.6.jar as module per domain using Maven pom.xml?

1 Answers1