PackageBuilderShellMojo (m2) and classloaders

[David Jencks <da...@yahoo.com>]

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

Re: PackageBuilderShellMojo (m2) and classloaders

[Jason Dillon <ja...@planet57.com>]

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

Okay, I added a comment to the changes I made (which removed the  
reflection) to note that if we run into crazy errors that we should  
re-implement the classloader isolation.

--jason

Re: PackageBuilderShellMojo (m2) and classloaders

[David Jencks <da...@yahoo.com>]

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.

true.
>
> 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  
pointless.

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

Re: PackageBuilderShellMojo (m2) and classloaders

[Jason Dillon <ja...@planet57.com>]

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?

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