geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shan Karthic" <shan.kart...@gmail.com>
Subject Classloader Hierarchy and hidden-classes
Date Wed, 13 Sep 2006 20:38:24 GMT
I am using geronimo 1.1.1-rc3.  I am using the release candidate instead of
1.1 since 1.1.1 fixes GERONIMO-2125.

Is there anyway I can specify, for everything under the application
classloader (including child classloaders of the application classloader,
such as WAR classloaders), that the classes loaded by application class
loader are visible but not the ones loaded above the application
classloader?

I want to hide some classes loaded by the server inside my application.  If
I use hidden-classes I am able to hide the classes loaded by current
classloader's parents.  The problem I face is if I use hidden-classes at WAR
level it hides the same classes loaded by EAR/application classloader as
well.  If I use hidden-classes only at application level and not at WAR
level, it does not hide the classes loaded by the server from the WAR class
loader.  It looks like child classloaders do not know of hidden-classes
specified at parent classloader level.  Is there any reason it is so?

I started out trying to force my application to use its own log4j
configuration accessed through commons logging.  So I had to hide
org.apache.commons.logging, org.apache.log4j,
org.apache.geronimo.kernel.logloaded by the server.  An utility jar in
the application manages references
to Log objects.  The utility is used by EJBs and other utilities and WAR.

I am able to get the desired behaviour by hiding the classes at both app
level and at WAR level with inverse-classloading at WAR level.  If I do not
hide at WAR level, WAR class loader sees the classes loaded by the server.
If I hide at WAR level without inverse-classloading, WAR class loader does
not see log4j classes loaded by the app class loader.  But (I think so but
my interpretation of the diagnostic messages from commons logging may be
wrong), due to the way Log references are stored in a hierarchy of class
loaders, there seems to be assignments between log4j classes loaded by app
and WAR classloaders which results in errors.

Now the problem is, since I have enabled inverse-classloading at WAR level,
classes loaded by WAR classloader do not see any config/properties files
available under the EAR root.  I also think the singleton LogManager the
application uses is no longer singleton really as it is loaded separately by
the WAR and EAR classloaders.

As I see it, if I can hide the required classes at app classloader level,
that propagates to all child classloaders without hiding the classes loaded
the app classloader itself, that will help in resolving the problem.  I
searched but could not find whether there is anyway to do that.

Thanks and regards,
Shankar.

Mime
View raw message