ClassLoaders and EARs

[hlship]

Here's my scenario:

I have an EAR that consists of a WAR and several EJBs.

Classes in the WAR and the EJB modules are built from some common framework classes, packaged as a JAR.

(This is actually a simplification, the target system will have many, many EJBs and many, many framework JARs).

I would like to package the framework JARs, the EJBs and the WARs together as an EAR.

I would like to ensure that, at the very least, all the framework JARs are loaded by the same classloader.

What I've found is that if my WAR's manifest lists all of the framework JARs (using a "Class-Path" manifest header) then things seem to work (even in the EJBs). I've verfiied this by varying the entries in the manifest, and see that the EAR fails to even load unless I include all the framework JARs in the WAR's manifest.

Is there an easier way? Is there anything I can do in the application deployment descriptor?

Generating the framework list for the Manifest is not too difficult, but not ideal.

In addition, it is not clear whether this approach is portable to other app servers besides JBoss.

Thanks in advance for the help.

I've found that Sun's documentation is not helpful about this kind of issue. I can't decide if they are clueless, or whether they have some religous fixation that EJB jars must be completely self-contained (that is, one possible solution would be to duplicate the classes in each EJB JAR ... though that may not work in my situation, since I need just one singleton object, in a static variable, for all of the EJBs, and the WAR, to share).

[frito]

Hi,
the singleton thing won't work in a portable way, since it is in the responsibility of the container implementer to assign classloaders. A very usual way of doing this is assigning a classloader to every deployed unit (with subdeployment classloaders are child to the enclosing deployment classlaoder). JBoss uses a single loader repository as default and can be configured to use a new one for every deployed unit, which is a different approach.

AFAIK the WAR has to have its own classloader. First it has to look into the WARs lib directory for resources. Then it is going up to look the manifests classpath.
Probably you are able to configure JBoss in a manner you wanted to without the verifier complaining using the <loader-repository> tag in your jboss specific deployment descriptor.

Greetings,
Frito

[hlship]

It's hard to tell what's standard, and what's vendor specific.

For example, WebLogic appears to create one class loader for the EAR, and all the EJBs in the EAR share that class loader.

Each WAR in the EAR gets a child class loader, to allow for reloading servlets and JSPs.

Again, all the common frameworks (which are, in reality, pluggable modules) should be in the EAR so that they will be distributed properly in the cluster.

I'll be doing more testing tomorrow using WebLogic. We'll see if the Manifest Class-Path trick works there as well.