geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Classloader Hierarchy and hidden-classes
Date Thu, 14 Sep 2006 01:35:58 GMT
I'm getting confused by your description, and looking at the code in  
trunk what I think you're saying doesn't look too likely... so I'm  
pretty sure I'm confused about something here and misunderstanding  
what you are saying.

Could you outline what you are seeing in terms of a class org.foo.X  
that is present in 3 classloaders:

cl1
parent of
cl2
parent of
cl3

where cl2 or cl3 has org.foo in hidden classes and either cl2 or cl3  
or maybe both have inverse classloading turned on?

Seems like maybe we need some test cases to make sure what we think  
is happening, is actually happening.

Many thanks
david jencks

On Sep 13, 2006, at 4:38 PM, Shan Karthic wrote:

> 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.log loaded 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