geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Please Vote: 1 deployment tool or 2?
Date Thu, 28 Oct 2004 18:35:37 GMT
On Thu, 28 Oct 2004, Dain Sundstrom wrote:
> These are the main commands.  I like hiram's idea of dropping the -- 
> from them like svn and cvs do.  I don't see why you have extra 
> restrictions on install.  Actually, why not just drop install since it 
> is just deploy?

	Sure, we can restructure the syntax.  The difference 
between install and deploy would be clearer if we called them "distribute" 
and "deploy" to match the JSR-88 terms -- I only used "install" because I 
thought we wanted to preserve the existing syntax.  So long as we're going 
to change it anyway...
	But the difference is that "distribute" does not start a module, 
so "deploy == distribute + start".  In concept, you could distribute an 
app, make sure it gets processed and loaded on to all the servers, and 
then bang! issue a start command to start them all at once.  I guess.  I 
don't really plan to use that much myself, but since the API capability is 
there, why not allow it from the tool?  We can just list that under 
"rarely used".
	Also, "start" is not meaningful for the current deployer -- not
only can it not start because the server is not running, it does not alter
the configuration in such a way that the module should be started next
time the server is started.  So "install" in the current tool really is
equivalent to "distribute" not "deploy".  If we want the default command
to be "deploy", then when the tool runs in "server is offline" mode (like
the current tool), it should update var/config/config.list to add the
module to that.

> > --modulelist    a list of TargetModuleID names to start, stop, or
> >                    undeploy
> >
> > --list-modules  gives you a list of modules available from the
> >                    management server you connected to.  defaults
> >                    to all targets, or use --targets

> What is the difference between these two?

	Well, when starting, stopping, or undeploying, you must give the
server a list of TargetModuleIDs to start, stop, or undeploy.  Where a
TargetModuleID is some product-specific amalgamation of a unique server or
cluster ("Target") ID and a module ID.  So if the same EAR is deployed on
3 servers, you could stop it on 2 of them with 2 TargetModuleID's.  We'll
have to think about what our Target IDs should look like, but they'll
likely be ugly (host name and installation path, perhaps?) or else a
unique name that a user configures somewhere, and the Target Module ID's
will presumably be that plus either a ConfigId or ObjectName identifying
the module.  I need to look at what the current TargetModuleID
implementation does.

	Anyway, one of these arguments gives the list of TargetModuleIDs 
that you want to start, stop, etc.  The other is an inquiry command, where 
you give it a list of targets, and it gives you back a list of 
TargetModuleIDs available on those targets.  So if you don't know what 
you're dealing with, it might go like this:

>>> deployer list-targets
>>> deployer list-modules --targets cluster
>>> deployer stop --modules cluster/webapp2.war,cluster/app1.ear
   cluster/app1.ear stopped
   cluster/webapp2.war stopped

Perhaps we could omit the --modules argument and just assume everything at 
the end of the command without a -- prefix is a module to operate on.

> > --list-targets  gives you a list of targets available from the
> >                    management server you connected to
> >
> >  --targets       a list of targets to get modules for, or to install
> >                    or deploy to.  defaults to all targets available
> >                    from the current management server if a URL is
> >                    specified or defaulted to.  defaults to the current
> >                    server environment only if the URL is null.
> These are almost never going to be used, so should be documented as such

	Well, until we implement clusters, or a single administration 
point for multiple servers (similar to WebLogic admin server + many 
managed servers).

> > --classPath     classpath to set for an executable module
> >
> > --mainClass     main class for an executable module
> >
> > --outfile       build a CAR instead of deploying into the server
> >                    environment
> Options of creating an output Jar... these are rarely used and should 
> be documented as such.

	I don't like them at all because they can't be done via JSR-88.  
So this introduces not only an additional implementation path, but also 
incompatibility with many of the other options that require JSR-88.  If 
nothing else, can we please please have another tool just to build 
output JARs?  This mode of operation has no relation to the normal 
deployer operation.  (Though in truth, deploying while the server is not 
running has the same disadvantage.)

> > --driver        JAR of the server driver, if not already on classpath.
> >                    only necessary when non-Geronimo server targeted
> I don't think there is any reason for us to support other app servers 
> drivers.  This is a tool by geronimo for geronimo.  Let the ide vendors 
> come up with the universal adapter.

	If we implement it using JSR-88, which is the most straightforward 
way for all normal operations (so long as the server is running), then we 
get support for other app servers for free.

	Deployment while the server is not running is the tricky case.  
We can shoehorn it into JSR-88 by having a URL mode that requires that a
local Kernel be started before JSR-88 is invoked (like the way the
deployer tool runs now), but Jeremy seemed to be strongly opposed to this.  
I don't really like having 2 different code paths for standard operation,
though, so if we go with one tool I might favor this, hacky as it is.

> So I see the following as being the most common usage:
> deployer deploy funk.war
> deployer undeploy funk

	Unfortunately, both of these are illegal according to JSR-88.  You 
need to specify a deployment plan for the module, and to undeploy you 
need to specify a target module ID including the target name and the 
module name.
	We could build a workaround for the first -- if no plan is
specified we load the driver, assume the driver loads the plan or 
creates a default one from deployment information in the archives, save 
the plan to a temp file, and then send the module and plan together as 
required and delete the temp file.
	For the second one, we'd assume you want to operate on all 
targets.  Then we'd get the list of all TargetModuleIDs for all targets, 
and for each, check if the name you specified is either equal to 
TargetModuleID.toString, or TargetModuleID.getModuleID.
	So I guess we could support both usages with a sufficiently 
clever tool.

	I'm thinking that the current Commons CLI logic for the arguments
isn't going to work, since there will be different available arguments
depending on your primary command.  Perhaps we can read the first argument 
and then construct a different CLI chain accordingly.

	Also, with all the votes for 1 tool, I'm assuming that you're OK 
with the basic Geronimo deployment tool depending on JSR-88.


View raw message