geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: Whence the geronimo kernel?
Date Tue, 07 Apr 2009 08:46:47 GMT
On 07/04/2009, at 4:00 AM, David Jencks wrote:

>
> There are two things that worry me about this.
>
> 1. IIUC whenever you include a jar in a configuration all the  
> configuration's parents get added as parents to the jar's global  
> classloader, in this code in MultiParentClassLoader2:
>
>     protected void addParents(Set<GlobalClassLoader>  
> globalClassLoaders) {
>         for (GlobalClassLoader globalClassLoader :  
> globalClassLoaders) {
>             for (ClassLoader parent : parents) {
>                 globalClassLoader.addParent(parent);
>             }
>         }
>     }
>
> I don't think this is acceptable.  I think that once we have a  
> GlobalClassloader set up for a jar it needs to be immutable.  With  
> your code which jar a class is loaded from could depend on which  
> configurations are started when you try to load the class.

I agree and this was one of my concerns; though it can be addressed.  
The problem is that the dependencies defined by a given config may  
not be complete.

Let's assume:
* config A imports dependency D1, D4;
* config B imports dependency D2 and D3;
* config B is a child of config A; and
* D1 and D3 are declared as maven dependencies for D2.

The current implementation builds a partial tree of  
GlobalClassLoaders based on the dependencies defined by a given  
config. This means that in the above scenario when config B is  
started only GlobalClassLoaders for D2 and D3 are put at the right  
place according to their maven dependencies, i.e. D3 is a parent of  
D2. D1 is artificially put as a parent of D2 by adding config A's  
classloader to D2.

A better implementation would be to add the relevant  
GlobalClassLoaders defined by parent configurations, in our example  
D1, to the GlobalClassLoaders used by a given config, in our example D2.

I can fix this problem.

>
> I'm sure I haven't thought this through completely but I really  
> wonder if adding parents to the global classloaders is necessary.   
> If we ignore geronimo plugins based on javaee apps for a moment,  
> geronimo plugins won't have any classes in them, and jars will have  
> maven dependencies on the appropriate other jars anyway.  So I  
> think that in the normal case adding these parents won't add any  
> missing classes.  Constructing a classloader for a javaee app that  
> can be used as a parent of some other classloader is a geronimo  
> specific feature anyway not supported by maven so I think it would  
> be OK to just have people include such dependencies in the  
> <baseURL>-additional.xml (or the pom, possibly).
>
> If we drop this add-parents behavior we might need to add  
> classloading rules to the global classloaders and either specify it  
> directly or push it down from a plugin config.  Again I haven't  
> thought this through.

I think that classloading rules are only going to be useful to  
isolate javaee apps. I think this is going to be OK as classloading  
rules were introduced to better isolate javaee apps from their  
runtime container.

>
> 2. IIUC the <baseURL>-additional.xml only lets you add to the maven  
> pom.  I think we need to be able to delete stuff too.

I can add this functionality.

Assuming that the above is fixed by mid-next week, do you think that  
current classloading problems would be resolved? Or do you think that  
re-platforming to an OSGi approach will provide a better mileage?

Thanks,
Gianny

>
> As a probably easy-to-fix bug I think that we currently decide if  
> something is a jar or a plugin in MavenDependencyResolver by  
> whether there is exactly one URL for the artifact.  However a  
> geronimo plugin with classes inside -- say an ejb jar -- could have  
> exactly one url but not be a jar.
>
> These are just my first impressions, I'll keep looking.
>
> thanks!
> david jencks


Mime
View raw message