Can you help us? It’s rather urgent; our development time window ends this week.

Since this is EAP, I suggest you use JBoss Support.

That's the easiest way how you get urgent things done. ;-)

At the same time F ear now contains a class "com.getronics.slg.civmk.common.jaas.listener.CivisionSessionListener"

that we want to be visible for ear’s A through E.

If it wasn't for this, then it would be pretty simple to do this -- simply putting F into own CL domain, with DefaultDomain as parent.

But with this, it means that A-F still need to be in a shared CL domain.

Let me think about this ...

For F: perhaps try to avoid big-ball-o-mud, and filter out the xxx.jar from ext delegates.

This is the code in BaseCLDomain that should help:

         if (policy.isImportAll())
            allExports = true;
      }


      // Next we try the old "big ball of mud" model      
      if (allExports)
      {
         loader = findLoaderInExports(classLoader, name, trace);
         if (loader != null)
            return loader;
      }
      else if (trace)
         log.trace(this + " not loading " + name + " from all exports");

      // Next we try the imports
      if (info != null)
      {
         loader = findLoaderInImports(info, name, trace);

Are you suggesting that I do a extend/override on the JBoss class loading?

No. :-)

I was thinking of having a proper jboss-classloading.xml configuration.

e.g. import-all=false, right requirements, etc

Isolating F helps with seeing the x.jar v1.0 first.

But that hides the CSL class.

Those jars should be able to see classes from A-E, if they are not .war classes.

Ah, direct streams, it always helps. :-)

Hopefully I'll find some more time soon to check how to do proper solution.

I will have to be "OSGi"-like in order to work w/o hacks.