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 Fri, 10 Apr 2009 18:46:53 GMT

On Apr 8, 2009, at 6:09 AM, Gianny Damour wrote:

> On 08/04/2009, at 5:10 PM, David Jencks wrote:
>> 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 integration.
> Based on this fact, it appears to me as useless to continue further  
> down the road I explored.
> I do still believe that simplifying the configuration model is more  
> important than OSGi integration. Making IoC simpler (e.g. no need to  
> declare or annotate injected attributes or references), more  
> flexible (e.g. use of service factory) and to the point (i.e. less  
> verbose) is hopefully part of the extensive changes. Re-using Apache  
> Felix iPOJO would be good.

At this point I regard the configuration model as a bit orthogonal to  
the classloader model.  I think that getting the one-cl-per-jar to  
work is a really good idea.  For the configuration model I'm not sure  
if it makes more sense to extend ours or implement the osgi blueprint  

Anyway I took the approach of generating classloader metadata from  
poms and including it in the geronimo-plugin.xml for plugins.  I got  
the framework server to start with this and just checked in the result  
in my sandbox.  I expect to look at the rest of the server next....  
I'm sure there are lots of bugs left.

I've been wondering how we'll assemble servers if we are using osgi.   
AFAICT osgi doesn't really try to address the question of deciding  
which allegedly equivalent implementations of particular classes  
should actually get used, something that maven spends much of its  
efforts on.  I think that as a first step we should continue  
generating and using the geronimo-plugin.xml metadata even though in  
an osgi environment it will be much less directly related to the  
geronimo classloading structure.

david jencks

> Thanks,
> Gianny
>> thanks
>> 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