geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: svn commit: r694978 - in /geronimo/server/trunk: assemblies/geronimo-framework/ assemblies/geronimo-jetty6-javaee5/ assemblies/geronimo-jetty6-minimal/ assemblies/geronimo-tomcat6-javaee5/ assemblies/geronimo-tomcat6-minimal/ buildsupport/car-maven-plu...
Date Mon, 15 Sep 2008 17:51:32 GMT
Joe Bohn wrote:
> David Jencks wrote:
>> On Sep 15, 2008, at 6:18 AM, Joe Bohn wrote:
>>> Thanks for making these changes David.  I think this mostly addresses 
>>> my concern that plugingroups can be used anywhere plugins are used 
>>> (it certainly helps now that they are all cars :-) ).
>>> So with the subject change ... is it now true what Lin mentioned 
>>> earlier in the "[DISCUSS] plugingroups - another idea" thread:
>>> Lin Sun wrote:
>>> > For option 1, I guess I don't understand why we need the classLoader
>>> > attribute.   I think for plugin groups, we should not add the plugin
>>> > group itself to the classloader, but we should add the dependencies to
>>> > the classloader.   For instance, if we support Joe's scenario, when a
>>> > user specifies a plugin group as a dependency in his deployment plan,
>>> > it would just add the dependencies that the plugin group depends on to
>>> > the project's classloader.
>>> Will the dependencies of the plugingroup be added to the project's 
>>> classloader?  That would certainly resolve any concerns.
>> I _think_ they will be in the maven build's classloader but definitely 
>> not in the geronimo classloader.   While this is inconsistent I don't 
>> yet see a reasonable use case for a plugingroup that doesn't have a 
>> classloader but does indicate a group of plugins that need to be added 
>> to some projects classloader.  I needed the new functionality for 
>> other purposes so I haven't spent a lot of time thinking about this 
>> but a real concrete use case would go a long way for me.
> The scenario I had in mind is very simple.
> 1) A user has decided (for whatever reason) that they need a core server 
> built on Geronimo including Jetty & Axis2.
> 2) The user will build multiple web applications and combine them on 
> server images as the need arises and so they don't want to include the 
> applications themselves in a custom server assembly.
> 2) To address the core server need, the user chooses to assemble their 
> own server image with the two universal pre-reqs: the web-jetty and 
> webservices-axis2 plugingroups.
> 3) The user then goes about building their web applications and 
> generating geronimo plugins for these web apps to ease deployment.  They 
> want to ensure these applications are installed in the correct server 
> configuration so they set the prereqs for the applications to match the 
> core server image that they had earlier constructed - a prereq on the 
> web-jetty and webservices-axis2 plugingroups.
Should have said dependencies rather than prereq here.  Not only is this 
to validate the server configuration but it is also to establish the 
classloader for application.
> 4) The user will then install the server in the appropriate location(s) 
> and deploy combinations of the applications on the as necessary on the 
> server instances.
> Of course it is more correct to have the applications prereq the 
> individual plugins necessary for jetty and axis2 runtimes rather than 
> the plugingroups.  However, that would mean that the user must 
> understand the detailed plugins for building applications but only the 
> plugingroups for building server images ... and the whole point of the 
> plugingroups was to simplify things for the user so they could deal with 
> higher level concepts.  If that simplification makes sense for 
> assembling a server (a relatively infrequent activity) why would it not 
> also make sense for assembling an application (a somewhat more frequent 
> activity)?
> And yes, I understand (as will the user) that the plugingroups may be 
> pulling in more than they really need to run the applications - esp. if 
> we continue to combine core function, deployers, and console extensions 
> in the plugingroups.  That may be a valid reason to alter the 
> granularity of the groups we are creating.  If not, another reason to 
> split things up a little finer is to facilitate the construction of 
> servers without deployment capabilities - but that's really a separate 
> discussion.
> Thanks,
> Joe
>> thanks
>> david jencks
>>> Thanks,
>>> Joe

View raw message