javaee module class-loading and static variables

Question

Consider the following: support.jar

public class SupportUtil{

  private static Map<String, Resource> myResources;

  void init(){
    initResources();
  }
}

Then i have 2 independent war applications conneting remotely to another ejb module within the same javaee server (currently using wildfly 8)

war1 -> lib/support.jar
war2 -> lib/support.jar
ejb1 -> ear-lib/support.jar

My questions is, based on module classloading architecture, would the three modules see the same Map off myResources (considering that this is a class variable, and class variables are shared by all instances)

I need clarification, for wildfly or glassfish, how classloading would affect this behaviour.

Once the class has been loaded `myResources` which is static would be loaded along with it, and the same copy of it will be shared with all your modules until there are references to the class. — Darshan Lila, Sep 20 '14 at 09:43
@DarshanLila would the same classloader (read same instance of ModuleClassLoader) load SupportUtil for the three modules? Mark you, these are independent deployment units. — maress, Sep 20 '14 at 09:52

score 0 · Answer 1 · edited Jun 20 '20 at 09:12

The war is considered to be a single module, so classes defined in WEB-INF/lib are treated the same as classes in WEB-INF/classes. All classes packaged in the war will be loaded with the same class loader.

By default the EAR/lib directory is a single module, and every WAR or EJB jar deployment is also a separate module.

Each module will load its own class instance with its own static field values.

Sub deployments (wars and ejb-jars) always have a dependency on the parent module, which gives them access to classes in EAR/lib, however they do not always have an automatic dependency on each other. This behaviour is controlled via the ear-subdeployments-isolated setting in the ee subsystem configuration.

WARs usually depend on EAR/lib. So your WAR modules would "see" two instances of SupportUtil. When the code executes in the WAR module context (during a web application request), it would see it's own lib instance of SupportUtil. When you WAR calls EJB remotely (or even locally!) then the module context switches to EJB, and the "current" instance of SupportUtil comes from the EAR/lib module. (Disclaimer: I didn't test this, but that's my understanding.)

I wouldn't advise getting into this position, when a module has access to multiple instances of the same class. I don't have any failure stories to back that up, it just seems to be a potential source of confusion: a code in the same module can see different values depending on how the execution got there.

There is a special case though.

The ear-subdeployments-isolated element value has no effect on the isolated classloader of the .war file(s). i.e. irrespective of whether this flag is set to true or false, the .war within a .ear will have a isolated classloader and other sub-deployments within that .ear will not be able to access classes from that .war. This is as per spec.

WARs are always isolated! So you could have the same jars/classes in multiple WARs, and no module will see more multiple instances of the same classes.

Source: Class Loading in WildFly.

javaee module class-loading and static variables

1 Answers1