geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: New Feature: Configuration Import/Export
Date Mon, 27 Mar 2006 20:26:29 GMT

This is a good summary of the possibilities Matt.   I've got some 

> 2. User downloads a bootstrap agent (much like Cygwin) and then chooses 
> either the pacakges they want (specific OSS projects) or the features 
> they want (JMS, Servlet 2.4, EJB 1.1, Spring, etc.)  The downloaded 
> agent would resolve the required dependencies and suck down the 
> appropriate parts and configure the runtime.
> 3. Similar paradigm to above but rather than running a single server 
> instance they would specify a target location to export a server image 
> that would be bootable.  The instance they operate from is an AppServer
> factory and not an AppServer instance.  

But they aren't interacting with an AppServer in #2 either ... right? 
Isn't the bootstrap in #2 really just an AppServer Factory as well?

> The interfaces would include a 
> GUI (nice user interface, dynamic resolution of dependencies, etc.) as 
> well as a command line utility that could build the instances required 
> for a specific set of applications.
Can you clarify the command line utility?  Do you envision a command 
line that accepts all of the configuration choices as parameters or are 
you thinking of a response/properties/XML/whatever file that would be 
created to specify the particulars of a configuration and then the 
factory uses this information to generate an executable instance?  I 
assume that's what you mean but I may be missing some other aspect of 
the proposal.
> 4. A variation on the above would also install the application artifacts 
> and create disposable runtimes.  Users could then take these images and 
> distribute them in a cluster and they would be fully functional 
> containers but are designed to be disposed of after use.  The paradigm 
> of defining and iterating a server instance doesn't exist in this mode.  
> The "disposable" instances would be able to federate into a managable 
> cluster from an operations perspective but would be limited to starting 
> and stopping the servers and pulling runtime statistics.
I think that we may need to provide some capability for iteration and 
updates ... but I agree that we should limit this.  For example, I can 
see why it might be desirable to change ports, users, passwords, queues, 
drivers, etc... in a configuration without requiring the creation of a 
new image.  The problem is that there isn't necessarily a clear cut 
distinction between normal maintenance and what would require a new 

Perhaps you're correct that we should prevent any updates and always 
require a new image .... but I'm not sure how that will be perceived by 
the user.  Replacing the image typically requires an interruption of 
service while an update such as installing a new service or application 
doesn't impact other applications on the server.   I guess I'm thinking 
that we might need to give the user the choice.  Basically let the 
resultant server image be no different than other images which can be 
incrementally enhanced if the user chooses to do so.  However, the 
creation of the complete runtime image gives them the choice to maintain 
the template or the individual instances.


Joe Bohn
joe.bohn at

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

View raw message