geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Whence the geronimo kernel?
Date Wed, 08 Apr 2009 07:10:47 GMT

On Apr 7, 2009, at 1:46 AM, Gianny Damour wrote:

> 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?

I'm being led into more extensive changes, I hope to have something  
working tomorrow or the next day.  I think this will be a good and  
illuminating step towards osgi and that most likely releasing 2.2 with  
this system will be a good idea before attempting more extensive osgi  

david jencks
> 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

View raw message