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
