CODEWITHSUNDEEP
wildflyclassloader
Eric B.
Eric B.

Reputation: 24451

How to limit WAR classload in Wildfly to the WEB-INF folder only (not have visibility on EAR/lib folder)?

I'm trying to add a self-contained WAR to an existing EAR. Given that my new WAR has some much more recent libraries, I want to ensure at all costs that there are no conflicts with any existing libraries that are present within my EAR.

At the moment, my EAR is structured as:

EAR:
 - webapp1.war
 - ejb.jar
 - lib/lib1.jar
      /lib2.jar
      /lib3.jar
 - webapp2.war  <-- the new self-contained war

To limit any potential conflicts, I will package my webapp2.war as a completely self-contained WAR, with all its dependencies in the WEB-INF/lib folder. But to be even more certain, I want to limit the classloader for the webapp2 to its WEB-INF/classes and WEB-INF/lib folder.

I found this classloading reference for Wildfly, but the only thing I found in the document is the exclude-subsystems tag:

jboss-deployment-structure.xml:

<jboss-deployment-structure>
  <sub-deployment name="myapp.war">
    <!-- Exclusions allow you to prevent the server from automatically adding some dependencies     -->
    <exclusions>
        <module name="" />
    </exclusions>
  </sub-deployment>
</jboss-deployment-structure>

But I read this to mean that I would need to create a new subsystem entry for every lib (ie: module) in the ear/lib folder. Which is not very manageable. Additionally, I'm not even 100% clear of what the module name should be?

Is there any way to simply tell the classloader to ignore all modules/libs in the EAR/lib folder? Is there a maven plugin I can use to otherwise generate this automatically for me?

Upvotes: 0

Views: 773

Answers (1)

Steve C
Steve C

Reputation: 19445

The easiest way to do this is to just deploy the WAR separately.

If you really need to do this then simply including the WAR in the EAR should just work.

Aside from APIs provided by the Java EE/SE specifications, everything else in a WAR file's WEB-INF/lib (and classes) directory will always be seen before the class loader looks into the EAR and elsewhere. This is a specification requirement.

Things will get messy if you forget a library and a class is picked up from the EAR though. That class may return an object that references one of your duplicate libs resulting in strange class access problems.

Upvotes: 1

Related Questions