Creating an EAR shouldn't cause the libraries to be loaded multiple times.
If you really want them to be independent, I think you'd need to make the available per-WAR, either by packaging them in WEB-INF/lib or doing it with a deployment overlay.
My requirement is to load these classes only once & not for per WAR. So if it does not get loaded multiple times then I am fine.
Another question is whether the classes in EAR are loaded lazily?
Also I still am not clear whether the common libraries should be shared through an EAR or as a static module.
The difference which I am aware is that as an EAR I can do hot deployment & avoid server restart.
Are there implications in terms of performance / memory usage which I should consider?
Thanks for your reply
In a JVM all classes are loaded lazily, but they may be loaded before you wanted them to. Did you have a specific problem you were concerned about?
Putting them in the EAR would be portable, since it is supported by all containers. There are no real performance/memory concerns - you can leak perm gen (or metaspace on JDK 8) by doing hot deployments, however the modules approach only avoids that by not letting you do hot deployments.
- deploying each JAR as an independent module with it's own module.xml desriptor;
- deploying the JARs in the WEB-INF/lib directory of a WAR;
- and the foo.ear/lib directory for any JARs shared across multiple WARs.
The obvious advantage to approach 1. above is the reduced memory footprint at deploy time over apprach 2. and approach 3.
Is the above statement true, & if so why?
If you have duplicated libraries that are in multiple EAR/WARs, then being a static module will reduce memory usage since there is only one version rather than multiple versions. If a library is only in one application, then being packaged versus being in a module shouldn't be different from a memory perspective.