Search code examples
javajakarta-eeglassfishclassloader

GlassFish extending JARs used by common classloader


I am migrating several applications from JBoss 4 to GlassFish 3.1.x. Each of these application use the same API that provides common classes and interfaces that each of the applications uses. Let's call it CoreAPI.jar.

CoreAPI.jar is put into the <domain>/lib directory of GlassFish and is loaded by the common class loader.

Now let's say that each application extends a class (not abstract) from the CoreAPI called Version:

public class Version {
    public String getVersion() { return null; }
}

The method getVersion() is called from within the API itself in several places and each application that uses the API is responsible for extending the class and providing a version like so:

public class MyAppVersion extends Version {
    private static final String VERSION = "1.0";

    @Override
    public String getVersion() { return VERSION; }
}

When I deploy the application to GlassFish, bundled in a WAR or EAR, any time the API calls getVersion() from the parent class, I get a java.lang.NullPointerException - it cannot seem to find the sub-class.

The sub-class is found properly if CoreAPI.jar is bundled with the WAR and removed from <domain>/lib directory, but I cannot do this because many application require it as a shared library.

Is there a way I can make a shared-library 'see' a sub-class within a deployed application?

Thanks!

Clarification: I do NOT have access to change the CoreAPI


Solution

  • Is there a way I can make a shared-library 'see' a sub-class within a deployed application?

    No. The application class loader is a descendant of the common class loader, and class loaders can only see their parents, not their dependents.

    This is typically discovered when the common class tries to do something like Class.forName("com.app.ImplementationClass") in code that is actually within common library.