geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack Cai" <>
Subject Re: [DISCUSS] enhance the assemble server portlet usability
Date Tue, 19 Aug 2008 03:17:34 GMT
If we can make the customization process very easy in the first place, then
it won't be a pain to recreate the custom server due to a Geronimo upgrade.

Surely we can allow the user to export the config for a custom server, but
it might not be a good scenario for the users to edit this file by hand to
update versions and things like that. This requires the user to have a very
good knowledge about Geronimo. A better scenario is to let the system import
the old config and automatically "absorb" the changes, but the
implementation might not be as easy as the first thought, considering some
components might be completely replaced with another implementation.

- Jack

2008/8/18 Joe Bohn <>

> 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,
> whatever)
> 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.
> Joe

View raw message