How Jetty handles class loading with same class with different dependencies?

Question

I want to know how jetty handles when multiple dependency paths which can lead to same class.

For example,

Jetty comes pre-packaged with JSTL-1.2, but I added a dependency to load JSTL-1.2.4. At compile time, if I breakpoint test it downloading the source code in eclipse, it breaks at 1.2.4 version.

I want to know which version will be passed to generate byte code of a JSP, when there are two versions of classes, say some base class JstlCoreTlv in dependency (one pre-packaged, that is JSTL 1.2 with jetty and one passed from maven dependency 1.2.4)

In brief, I want to know How jetty is doing it. I want to know how jetty prioritizes pre-packaged vs dependencies added later. Even if the version is older than that of pre-packaged one, will it override and refer to added dependencies?

I couldn't get much in this context from jetty documentation. Help is much appreciated

Answer 1

• Assuming you are not planning to change the jstl version of your Jetty installation.
• Assuming you are only using jstl version 1.2.4 to compile your code, and you are not adding the jar in your war WEB-INF/lib.

If you compile and package with maven against 1.2.4 and deploy the packaged war on Jetty, Jetty will use 1.2 (which is the one on the server classpath and not 1.2.4 (because it is not available for Jetty). This could lead to problems.

The best way to avoid problems is to use exact the same version in your maven project dependencies as the version is used by the Jetty version you will deploy on.

Answer 2

The servlet specification require that:

• Classes contained within WEB-INF/lib or WEB-INF/classes have priority over classes on the parent classloader (here is jetty's classloader).

From the document of jetty

A WEB-INF class can replace a Server class.

And the server class here is the jetty implementation of j2ee standard (code from jetty source code):

    /** Is the class a Server Class.
     * A Server class is a class that is part of the implementation of 
     * the server and is NIT visible to a webapplication. The web
     * application may provide it's own implementation of the class,
     * to be loaded from WEB-INF/lib or WEB-INF/classes 
     * @param clazz The fully qualified name of the class.
     * @return True if the class is a server class.
     */
    boolean isServerClass(Class<?> clazz);

You can also add control of server class by calling:

• org.eclipse.jetty.webapp.WebAppContext.setServerClasses(String Array)
• org.eclipse.jetty.webapp.WebAppContext.addServerClass(String)