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 Wed, 08 Apr 2009 13:09:26 GMT
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.

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


Mime
View raw message