geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: [DISCUSS] enhance the assemble server portlet usability
Date Mon, 18 Aug 2008 14:10:55 GMT
Kevan Miller wrote:
> On Aug 12, 2008, at 6:11 PM, David Jencks wrote:
>> On Aug 12, 2008, at 2:59 PM, Lin Sun wrote:
>>> I appreciate your valuable feedback!
>>> Currently, a user doesn't have that much choices, as we only allow the
>>> user to assemble a new server out of plugins in local server, unless
>>> we want to change this behavior.
>>> So if a user installs the geronimo-tomcat-javaee5 assembly, he can
>>> only choose tomcat + axis2.   If a user installs the
>>> geronimo-jetty-javaee5 assembly, he can only choose jetty + cxf.
>> true... for now :-)
>>> To simplify things, here is what I suggest.  We allow the users to 
>>> choose from -
>>> __ Web
>> __jsp
>>> __ JMS
>>> __ Web Services
>>> __ EJB
>>> __ OpenJPA
>>> __ Deployment
>>> __ Admin Console
>>> __ Cluster (tomcat only?)
>> __wadi clustering
>>> Then the user can just select one or more functions they need and
>>> request for the customer assembly server to be created.   Optionally,
>>> the user can add on additional deployed apps or other system modules
>>> then request for the customer assembly server to be created.
>> I wonder if we can think bigger :-)
>> What if we distributed something with _all_ the cars in it and 
>> customizable profiles for the servers we ship now?  So, you wouldn't 
>> unpack a particular server, but the server construction kit.  You 
>> could pick a profile and optionally modify it, then spit out the 
>> desired server.  Then you would be able to pick jetty/tomcat and 
>> cxf/axis2 and however much deployment you wanted.
>> Alternatively maybe the "assemble a server" can show plugins from more 
>> than just the current server.
> Sounds similar (same?) to something I've been thinking of... I was 
> thinking we could include multiple config.xml files. These files could 
> be specified when starting a server. E.g.:
> ./gsh geronimo/start-server -c jee-config.xml
> ./gsh geronimo/start-server -c minimal-config.xml
> ./gsh geronimo/start-server -c joes-custom-config.xml
> If server footprint is a concern, you can still create custom assemblies 
> based on these "profiles".
> I'm not sure we'd want to include *all* cars and include a wide variety 
> of possible config files. We certainly could, but I might stick with 
> current tomcat/axis2 and jetty/cxf specific variants and maintain a 
> "server" focus, rather than a "server construction" focus. I also don't 
> think that such a capability would necessarily replace the function that 
> Lin is proposing.

Hi all,

I'm still catching up after being away ...

This all sounds very similar to the features we had discussed long ago 
that led the the creation of plugins themselves and the Geronimo 
Framework Assembly.  At the time we discussed the notion of templates 
which were basically like the configuration files mentioned by Kevan 
above.  We could ship a number of predefined templates along with a 
collection of plugins (aka the "server construction kit") which could be 
used to generate a server image.  We debated the notion of packaging all 
of the plugins into a tarball or using the maven repos - both seem 
viable.  The user could also create their own templates and persist them 
for future use.

I think the key notion there was the idea of this persistent, small 
"definition" of a server image content we were calling a "template" at 
the time.  This provided a mechanism that could potentially be leveraged 
across server releases with minor changes to create consistent server 
image as a user upgraded from Geronimo 2.x to Geronimo 2.X+1 without a 
lot of manual effort (such as repeating a set of steps in the console, 
command line, or whatever perhaps months or years later).  For example, 
if you wanted the same server image you created for 2.1.2 in 2.2 you 
could potentially:
1) take your 2.1.2 template (config.xml like thingy)
2) update it as appropriate for version changes or perhaps replacement 
modules (leveraging cxf instead of axis2)
3) run it through an assembly utility in 2.2 (console, command line, 
4) Have a server image spit out the other end that is similar to the 
2.1.2 assembly but upgraded to 2.2.

I think this upgrade scenario is an important aspect of the building 
custom assemblies that must be considered.


View raw message