geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: PackageBuilderShellMojo (m2) and classloaders
Date Tue, 11 Jul 2006 19:21:34 GMT

On Jul 11, 2006, at 11:41 AM, Jason Dillon wrote:

> Thanks for following up on this.
> Would have been nice if there were comments in the codebase to this  
> effect.

> Was there any reason why the setters were all invoked through  
> reflection as well?

well, in the m1 plugin the class of the PackageBuilder instance is in  
a different classloader than the PackageBuilderShell, so I don't see  
how there is any other way to call the setters.  Am I missing  
something?  If we said PackageBuilder pb = (PackageBuilder) 
packageBuilderInstance we'd get a class cast exception.

I think what you've done for m2 should work: if we start getting  
bizarre class cast exceptions when trying to build configs we'll have  
to revisit this question.

Note that the m2 plugin had already switched to using the same  
classloader for PBSM and PB, so the reflective setter calls were  

david jencks

> --jason
> On Jul 11, 2006, at 8:43 AM, David Jencks wrote:
>> Jason Dillon asked last night on IRC why the  
>> PackgeBuilderShellMojo for the m2 packaging plugin used reflection  
>> to create the PackageBuilder.  We need to control the classloader  
>> for PackageBuilder pretty closely so it has the same classpath as  
>> j2ee-system.  In maven 1, IIUC, plugins get instantiated using a  
>> child classloader of the project calling the plugin: this  
>> classloader typically has a more or less random selection of large  
>> numbers of geronimo jars in it, far more than j2ee-system, and in  
>> particular including all the classes for the dependencies of the  
>> module/configuration you are trying to build.  The only solution I  
>> could see for m1 was to construct a classloader myself and load  
>> PackageBuilder in my own classloader and access the instance by  
>> reflection.
>> I believe the situation is better in m2 and that the plugin is  
>> instantiated using a classloader determined solely by the plugin's  
>> pom.  If so, we should be safe in eliminating this extra  
>> reflection code and in fact using PackageBuilder directly without  
>> the "shell".  If not, we should keep using the inconvenient  
>> reflection code.
>> thanks
>> david jencks

View raw message