>>  Aaron Mulder wrote:
>>
>>  Since we have multi-parent class loaders, it may be that there's more
>>  than one path to the offending server-level JAR.
>>
>>  For example, if you want to make commons-logging hidden, and you put
>>  the hidden-classes at the EAR level, but the WAR has a dependency on a
>>  database pool, then the WAR could find the server commons-logging
>>  through either the EAR-parent path or the database-pool-parent path.
>>  The solution in that case would be to move the database pool
>>  dependency to the EAR too, so the hidden-classes in the EAR would
>>  work.  But again, there may be several such dependencies at the WAR
>>  level.  Actually, if it really was commons-logging, you might not be
>>  able to avoid this problem, since the WAR will automatically depend on
>>  either the Tomcat or Jetty module, which gives yet another route.
>>  Hmmm.  It's almost like we need a way to say "load only from EAR" or
>>  "load only from dependency X"...

While I understand what you are saying, I am not able to translate this scenario to my scenario.

The class that refers to commons-logging is inside an utility JAR in the EAR.  I also do not have any explicit dependencies at either EAR or WAR level.  There may be implicit dependencies as you have mentioned but let us keep that out for a moment.

With no inverse-classloading and default delegate model (as in scenarios 1 & 2 I have outlined in the follow up to David Jencks's reply), the WAR classloader should delegate the request for the utility class to its parent classloader(s).  Even if there are multiple parents and dependencies, only the EAR classloader will be able to see the utility JAR and load the class.  Since the EAR class loader is loading the utility class, (here I am not so sure) it should attempt also to load commons-logging and associated classes as it can't delegate since they are hidden.  But that seems to be not happening.

Thanks,
Shankar.