You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2004/10/29 04:12:06 UTC
Proposed Deployer Syntax
General syntax:
deployer [--uri URI [--driver JarFile] [--user username [--password \
password]]] command arguments
--uri: a URI to contact the server. The server must be running for this
to work. If not specified, the deployer default to operating on a
Geronimo server running on the standard port on localhost, or if nothing
is available there, then the Geronimo server installation that the
deployer JAR is part of.
A URI to connect to Geronimo has the form:
geronimo:deployer:jmx:rmi://localhost/jndi/rmi:/JMXConnector
--driver: if you want to use this tool with a server other than Geronimo,
then you must provide the path to its driver JAR. Currently, manifest
Class-Path entries in that JAR are ignored.
--user: if the deployment operation requires authentication, then you can
specify the username to use to connect. If no password is specified, the
deployer will attempt to connect to the server with no password, and if
that fails, will prompt you for a password.
--password: specifies a password to use to authenticate to the server
Common Commands and Options
---------------------------
deployer deploy [module] [plan]
Normally both a module and plan are passed to the deployer.
Sometimes the module contains a plan, or requires no plan, in which case
the plan may be omitted. Sometimes the plan references a module already
dpeloyed in the Geronimo server environment, in which case a module does
not need to be provided.
If the server is not currently running, the module will be marked
to start next time the server is started.
deployer undeploy [ModuleID|TargetModuleID]+
Accepts the configId of a module, or the fully-qualified
TargetModuleID identifying both the module and the server or cluster it's
on, stops that module, and removes the deployment files for that module
from the server environment. If multiple modules are specified, they will
all be undeployed.
deployer start [ModuleID|TargetModuleID]+
Accepts the configId of a module, or the fully-qualified
TargetModuleID identifying both the module and the server or cluster it's
on, and starts that module. The module should be available to the server
but not currently running. If multiple modules are specified, they will
all be started.
If the server is not running, the module will be marked to start
next time the server is started.
deployer stop [ModuleID|TargetModuleID]+
Accepts the configId of a module, or the fully-qualified
TargetModuleID identifying both the module and the server or cluster it's
on, and stops that module. The module should be available to the server
and running. After stop is completed, the server still has the module and
deployment information available, it's just not running. If multiple
modules are specified, they will all be stopped.
If the server is not running, the module will be marked to not
start next time the server is started.
deployer redeploy [module] [plan] [ModuleID|TargetModuleID+]
A shortcut to undeploy a module from one or more servers, then
deploy a new version. This is not a smooth cutover -- some client
requests may be rejected while the redeploy takes place.
Normally both a module and plan are passed to the deployer.
Sometimes the module contains a plan, or requires no plan, in which case
the plan may be omitted. Sometimes the plan references a module already
dpeloyed in the Geronimo server environment, in which case a module does
not need to be provided.
If more than one TargetModuleID is provided, all TargetModuleIDs
must refer to the same module (just running on different targets).
Regardless of whether the old module was running or not, the new
module will be started (if the server is running) or marked to start (if
the server is not running).
Other Commands and Options
--------------------------
deployer distribute [module] [plan]
Just like deploy, except the module is not started by this
operation.
deployer list-targets
Lists the targets known to the server you've connected to.
Currently, there is only ever one target, but this may eventually change.
deployer list-modules [--all|--started|--stopped] [target*]
Lists the modules available on the specified targets. If
--started or --stopped is specified, only started or stopped modules will
be listed; otherwise all modules will be listed. If no targets are
specified, then modules on all targets will be listed; otherwise only
modules on the specified targets. (But note that right now there's only
ever 1 target.)
Not For General Consumption Commands and Options
------------------------------------------------
deployer package [--classPath path] [--mainClass class] \
[module] [plan] fileName
Creates a configuration JAR rather than installing into the server
environment. The fileName argument specifies the JAR to create. The
optional classPath argument specifies a Class-Path to include in the JAR
manifest. The mainClass argument specifies the Main-Class to include in
the JAR manifest.
The standard arguments may not be used with this command -- it
never connects to a remote server.
Aaron
Re: Proposed Deployer Syntax
Posted by Hiram Chirino <hi...@hiramchirino.com>.
+1
Aaron Mulder wrote:
>General syntax:
>
>deployer [--uri URI [--driver JarFile] [--user username [--password \
> password]]] command arguments
>
>--uri: a URI to contact the server. The server must be running for this
>to work. If not specified, the deployer default to operating on a
>Geronimo server running on the standard port on localhost, or if nothing
>is available there, then the Geronimo server installation that the
>deployer JAR is part of.
> A URI to connect to Geronimo has the form:
>geronimo:deployer:jmx:rmi://localhost/jndi/rmi:/JMXConnector
>
>--driver: if you want to use this tool with a server other than Geronimo,
>then you must provide the path to its driver JAR. Currently, manifest
>Class-Path entries in that JAR are ignored.
>
>--user: if the deployment operation requires authentication, then you can
>specify the username to use to connect. If no password is specified, the
>deployer will attempt to connect to the server with no password, and if
>that fails, will prompt you for a password.
>
>--password: specifies a password to use to authenticate to the server
>
>
>Common Commands and Options
>---------------------------
>deployer deploy [module] [plan]
>
> Normally both a module and plan are passed to the deployer.
>Sometimes the module contains a plan, or requires no plan, in which case
>the plan may be omitted. Sometimes the plan references a module already
>dpeloyed in the Geronimo server environment, in which case a module does
>not need to be provided.
> If the server is not currently running, the module will be marked
>to start next time the server is started.
>
>deployer undeploy [ModuleID|TargetModuleID]+
>
> Accepts the configId of a module, or the fully-qualified
>TargetModuleID identifying both the module and the server or cluster it's
>on, stops that module, and removes the deployment files for that module
>from the server environment. If multiple modules are specified, they will
>all be undeployed.
>
>deployer start [ModuleID|TargetModuleID]+
>
> Accepts the configId of a module, or the fully-qualified
>TargetModuleID identifying both the module and the server or cluster it's
>on, and starts that module. The module should be available to the server
>but not currently running. If multiple modules are specified, they will
>all be started.
> If the server is not running, the module will be marked to start
>next time the server is started.
>
>deployer stop [ModuleID|TargetModuleID]+
>
> Accepts the configId of a module, or the fully-qualified
>TargetModuleID identifying both the module and the server or cluster it's
>on, and stops that module. The module should be available to the server
>and running. After stop is completed, the server still has the module and
>deployment information available, it's just not running. If multiple
>modules are specified, they will all be stopped.
> If the server is not running, the module will be marked to not
>start next time the server is started.
>
>deployer redeploy [module] [plan] [ModuleID|TargetModuleID+]
>
> A shortcut to undeploy a module from one or more servers, then
>deploy a new version. This is not a smooth cutover -- some client
>requests may be rejected while the redeploy takes place.
> Normally both a module and plan are passed to the deployer.
>Sometimes the module contains a plan, or requires no plan, in which case
>the plan may be omitted. Sometimes the plan references a module already
>dpeloyed in the Geronimo server environment, in which case a module does
>not need to be provided.
> If more than one TargetModuleID is provided, all TargetModuleIDs
>must refer to the same module (just running on different targets).
> Regardless of whether the old module was running or not, the new
>module will be started (if the server is running) or marked to start (if
>the server is not running).
>
>
>Other Commands and Options
>--------------------------
>deployer distribute [module] [plan]
>
> Just like deploy, except the module is not started by this
>operation.
>
>deployer list-targets
>
> Lists the targets known to the server you've connected to.
>Currently, there is only ever one target, but this may eventually change.
>
>deployer list-modules [--all|--started|--stopped] [target*]
>
> Lists the modules available on the specified targets. If
>--started or --stopped is specified, only started or stopped modules will
>be listed; otherwise all modules will be listed. If no targets are
>specified, then modules on all targets will be listed; otherwise only
>modules on the specified targets. (But note that right now there's only
>ever 1 target.)
>
>
>Not For General Consumption Commands and Options
>------------------------------------------------
>deployer package [--classPath path] [--mainClass class] \
> [module] [plan] fileName
>
> Creates a configuration JAR rather than installing into the server
>environment. The fileName argument specifies the JAR to create. The
>optional classPath argument specifies a Class-Path to include in the JAR
>manifest. The mainClass argument specifies the Main-Class to include in
>the JAR manifest.
> The standard arguments may not be used with this command -- it
>never connects to a remote server.
>
>
>Aaron
>
>
>
Re: Proposed Deployer Syntax
Posted by Dain Sundstrom <ds...@gluecode.com>.
+1
-dain
On Oct 28, 2004, at 7:12 PM, Aaron Mulder wrote:
> General syntax:
>
> deployer [--uri URI [--driver JarFile] [--user username [--password \
> password]]] command arguments
>
> --uri: a URI to contact the server. The server must be running for
> this
> to work. If not specified, the deployer default to operating on a
> Geronimo server running on the standard port on localhost, or if
> nothing
> is available there, then the Geronimo server installation that the
> deployer JAR is part of.
> A URI to connect to Geronimo has the form:
> geronimo:deployer:jmx:rmi://localhost/jndi/rmi:/JMXConnector
>
> --driver: if you want to use this tool with a server other than
> Geronimo,
> then you must provide the path to its driver JAR. Currently, manifest
> Class-Path entries in that JAR are ignored.
>
> --user: if the deployment operation requires authentication, then you
> can
> specify the username to use to connect. If no password is specified,
> the
> deployer will attempt to connect to the server with no password, and if
> that fails, will prompt you for a password.
>
> --password: specifies a password to use to authenticate to the server
>
>
> Common Commands and Options
> ---------------------------
> deployer deploy [module] [plan]
>
> Normally both a module and plan are passed to the deployer.
> Sometimes the module contains a plan, or requires no plan, in which
> case
> the plan may be omitted. Sometimes the plan references a module
> already
> dpeloyed in the Geronimo server environment, in which case a module
> does
> not need to be provided.
> If the server is not currently running, the module will be marked
> to start next time the server is started.
>
> deployer undeploy [ModuleID|TargetModuleID]+
>
> Accepts the configId of a module, or the fully-qualified
> TargetModuleID identifying both the module and the server or cluster
> it's
> on, stops that module, and removes the deployment files for that module
> from the server environment. If multiple modules are specified, they
> will
> all be undeployed.
>
> deployer start [ModuleID|TargetModuleID]+
>
> Accepts the configId of a module, or the fully-qualified
> TargetModuleID identifying both the module and the server or cluster
> it's
> on, and starts that module. The module should be available to the
> server
> but not currently running. If multiple modules are specified, they
> will
> all be started.
> If the server is not running, the module will be marked to start
> next time the server is started.
>
> deployer stop [ModuleID|TargetModuleID]+
>
> Accepts the configId of a module, or the fully-qualified
> TargetModuleID identifying both the module and the server or cluster
> it's
> on, and stops that module. The module should be available to the
> server
> and running. After stop is completed, the server still has the module
> and
> deployment information available, it's just not running. If multiple
> modules are specified, they will all be stopped.
> If the server is not running, the module will be marked to not
> start next time the server is started.
>
> deployer redeploy [module] [plan] [ModuleID|TargetModuleID+]
>
> A shortcut to undeploy a module from one or more servers, then
> deploy a new version. This is not a smooth cutover -- some client
> requests may be rejected while the redeploy takes place.
> Normally both a module and plan are passed to the deployer.
> Sometimes the module contains a plan, or requires no plan, in which
> case
> the plan may be omitted. Sometimes the plan references a module
> already
> dpeloyed in the Geronimo server environment, in which case a module
> does
> not need to be provided.
> If more than one TargetModuleID is provided, all TargetModuleIDs
> must refer to the same module (just running on different targets).
> Regardless of whether the old module was running or not, the new
> module will be started (if the server is running) or marked to start
> (if
> the server is not running).
>
>
> Other Commands and Options
> --------------------------
> deployer distribute [module] [plan]
>
> Just like deploy, except the module is not started by this
> operation.
>
> deployer list-targets
>
> Lists the targets known to the server you've connected to.
> Currently, there is only ever one target, but this may eventually
> change.
>
> deployer list-modules [--all|--started|--stopped] [target*]
>
> Lists the modules available on the specified targets. If
> --started or --stopped is specified, only started or stopped modules
> will
> be listed; otherwise all modules will be listed. If no targets are
> specified, then modules on all targets will be listed; otherwise only
> modules on the specified targets. (But note that right now there's
> only
> ever 1 target.)
>
>
> Not For General Consumption Commands and Options
> ------------------------------------------------
> deployer package [--classPath path] [--mainClass class] \
> [module] [plan] fileName
>
> Creates a configuration JAR rather than installing into the server
> environment. The fileName argument specifies the JAR to create. The
> optional classPath argument specifies a Class-Path to include in the
> JAR
> manifest. The mainClass argument specifies the Main-Class to include
> in
> the JAR manifest.
> The standard arguments may not be used with this command -- it
> never connects to a remote server.
>
>
> Aaron
Re: Proposed Deployer Syntax
Posted by Jailton Lopes <ja...@gmail.com>.
+1
On Fri, 29 Oct 2004 19:01:45 +0100, jastrachan@mac.com
<ja...@mac.com> wrote:
> +1
>
> looks good
>
> On 29 Oct 2004, at 03:12, Aaron Mulder wrote:
>
> > General syntax:
> >
> > deployer [--uri URI [--driver JarFile] [--user username [--password \
> > password]]] command arguments
> >
> > --uri: a URI to contact the server. The server must be running for
> > this
> > to work. If not specified, the deployer default to operating on a
> > Geronimo server running on the standard port on localhost, or if
> > nothing
> > is available there, then the Geronimo server installation that the
> > deployer JAR is part of.
> > A URI to connect to Geronimo has the form:
> > geronimo:deployer:jmx:rmi://localhost/jndi/rmi:/JMXConnector
> >
> > --driver: if you want to use this tool with a server other than
> > Geronimo,
> > then you must provide the path to its driver JAR. Currently, manifest
> > Class-Path entries in that JAR are ignored.
> >
> > --user: if the deployment operation requires authentication, then you
> > can
> > specify the username to use to connect. If no password is specified,
> > the
> > deployer will attempt to connect to the server with no password, and if
> > that fails, will prompt you for a password.
> >
> > --password: specifies a password to use to authenticate to the server
> >
> >
> > Common Commands and Options
> > ---------------------------
> > deployer deploy [module] [plan]
> >
> > Normally both a module and plan are passed to the deployer.
> > Sometimes the module contains a plan, or requires no plan, in which
> > case
> > the plan may be omitted. Sometimes the plan references a module
> > already
> > dpeloyed in the Geronimo server environment, in which case a module
> > does
> > not need to be provided.
> > If the server is not currently running, the module will be marked
> > to start next time the server is started.
> >
> > deployer undeploy [ModuleID|TargetModuleID]+
> >
> > Accepts the configId of a module, or the fully-qualified
> > TargetModuleID identifying both the module and the server or cluster
> > it's
> > on, stops that module, and removes the deployment files for that module
> > from the server environment. If multiple modules are specified, they
> > will
> > all be undeployed.
> >
> > deployer start [ModuleID|TargetModuleID]+
> >
> > Accepts the configId of a module, or the fully-qualified
> > TargetModuleID identifying both the module and the server or cluster
> > it's
> > on, and starts that module. The module should be available to the
> > server
> > but not currently running. If multiple modules are specified, they
> > will
> > all be started.
> > If the server is not running, the module will be marked to start
> > next time the server is started.
> >
> > deployer stop [ModuleID|TargetModuleID]+
> >
> > Accepts the configId of a module, or the fully-qualified
> > TargetModuleID identifying both the module and the server or cluster
> > it's
> > on, and stops that module. The module should be available to the
> > server
> > and running. After stop is completed, the server still has the module
> > and
> > deployment information available, it's just not running. If multiple
> > modules are specified, they will all be stopped.
> > If the server is not running, the module will be marked to not
> > start next time the server is started.
> >
> > deployer redeploy [module] [plan] [ModuleID|TargetModuleID+]
> >
> > A shortcut to undeploy a module from one or more servers, then
> > deploy a new version. This is not a smooth cutover -- some client
> > requests may be rejected while the redeploy takes place.
> > Normally both a module and plan are passed to the deployer.
> > Sometimes the module contains a plan, or requires no plan, in which
> > case
> > the plan may be omitted. Sometimes the plan references a module
> > already
> > dpeloyed in the Geronimo server environment, in which case a module
> > does
> > not need to be provided.
> > If more than one TargetModuleID is provided, all TargetModuleIDs
> > must refer to the same module (just running on different targets).
> > Regardless of whether the old module was running or not, the new
> > module will be started (if the server is running) or marked to start
> > (if
> > the server is not running).
> >
> >
> > Other Commands and Options
> > --------------------------
> > deployer distribute [module] [plan]
> >
> > Just like deploy, except the module is not started by this
> > operation.
> >
> > deployer list-targets
> >
> > Lists the targets known to the server you've connected to.
> > Currently, there is only ever one target, but this may eventually
> > change.
> >
> > deployer list-modules [--all|--started|--stopped] [target*]
> >
> > Lists the modules available on the specified targets. If
> > --started or --stopped is specified, only started or stopped modules
> > will
> > be listed; otherwise all modules will be listed. If no targets are
> > specified, then modules on all targets will be listed; otherwise only
> > modules on the specified targets. (But note that right now there's
> > only
> > ever 1 target.)
> >
> >
> > Not For General Consumption Commands and Options
> > ------------------------------------------------
> > deployer package [--classPath path] [--mainClass class] \
> > [module] [plan] fileName
> >
> > Creates a configuration JAR rather than installing into the server
> > environment. The fileName argument specifies the JAR to create. The
> > optional classPath argument specifies a Class-Path to include in the
> > JAR
> > manifest. The mainClass argument specifies the Main-Class to include
> > in
> > the JAR manifest.
> > The standard arguments may not be used with this command -- it
> > never connects to a remote server.
> >
> >
> > Aaron
> >
> >
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
Re: Proposed Deployer Syntax
Posted by ja...@mac.com.
+1
looks good
On 29 Oct 2004, at 03:12, Aaron Mulder wrote:
> General syntax:
>
> deployer [--uri URI [--driver JarFile] [--user username [--password \
> password]]] command arguments
>
> --uri: a URI to contact the server. The server must be running for
> this
> to work. If not specified, the deployer default to operating on a
> Geronimo server running on the standard port on localhost, or if
> nothing
> is available there, then the Geronimo server installation that the
> deployer JAR is part of.
> A URI to connect to Geronimo has the form:
> geronimo:deployer:jmx:rmi://localhost/jndi/rmi:/JMXConnector
>
> --driver: if you want to use this tool with a server other than
> Geronimo,
> then you must provide the path to its driver JAR. Currently, manifest
> Class-Path entries in that JAR are ignored.
>
> --user: if the deployment operation requires authentication, then you
> can
> specify the username to use to connect. If no password is specified,
> the
> deployer will attempt to connect to the server with no password, and if
> that fails, will prompt you for a password.
>
> --password: specifies a password to use to authenticate to the server
>
>
> Common Commands and Options
> ---------------------------
> deployer deploy [module] [plan]
>
> Normally both a module and plan are passed to the deployer.
> Sometimes the module contains a plan, or requires no plan, in which
> case
> the plan may be omitted. Sometimes the plan references a module
> already
> dpeloyed in the Geronimo server environment, in which case a module
> does
> not need to be provided.
> If the server is not currently running, the module will be marked
> to start next time the server is started.
>
> deployer undeploy [ModuleID|TargetModuleID]+
>
> Accepts the configId of a module, or the fully-qualified
> TargetModuleID identifying both the module and the server or cluster
> it's
> on, stops that module, and removes the deployment files for that module
> from the server environment. If multiple modules are specified, they
> will
> all be undeployed.
>
> deployer start [ModuleID|TargetModuleID]+
>
> Accepts the configId of a module, or the fully-qualified
> TargetModuleID identifying both the module and the server or cluster
> it's
> on, and starts that module. The module should be available to the
> server
> but not currently running. If multiple modules are specified, they
> will
> all be started.
> If the server is not running, the module will be marked to start
> next time the server is started.
>
> deployer stop [ModuleID|TargetModuleID]+
>
> Accepts the configId of a module, or the fully-qualified
> TargetModuleID identifying both the module and the server or cluster
> it's
> on, and stops that module. The module should be available to the
> server
> and running. After stop is completed, the server still has the module
> and
> deployment information available, it's just not running. If multiple
> modules are specified, they will all be stopped.
> If the server is not running, the module will be marked to not
> start next time the server is started.
>
> deployer redeploy [module] [plan] [ModuleID|TargetModuleID+]
>
> A shortcut to undeploy a module from one or more servers, then
> deploy a new version. This is not a smooth cutover -- some client
> requests may be rejected while the redeploy takes place.
> Normally both a module and plan are passed to the deployer.
> Sometimes the module contains a plan, or requires no plan, in which
> case
> the plan may be omitted. Sometimes the plan references a module
> already
> dpeloyed in the Geronimo server environment, in which case a module
> does
> not need to be provided.
> If more than one TargetModuleID is provided, all TargetModuleIDs
> must refer to the same module (just running on different targets).
> Regardless of whether the old module was running or not, the new
> module will be started (if the server is running) or marked to start
> (if
> the server is not running).
>
>
> Other Commands and Options
> --------------------------
> deployer distribute [module] [plan]
>
> Just like deploy, except the module is not started by this
> operation.
>
> deployer list-targets
>
> Lists the targets known to the server you've connected to.
> Currently, there is only ever one target, but this may eventually
> change.
>
> deployer list-modules [--all|--started|--stopped] [target*]
>
> Lists the modules available on the specified targets. If
> --started or --stopped is specified, only started or stopped modules
> will
> be listed; otherwise all modules will be listed. If no targets are
> specified, then modules on all targets will be listed; otherwise only
> modules on the specified targets. (But note that right now there's
> only
> ever 1 target.)
>
>
> Not For General Consumption Commands and Options
> ------------------------------------------------
> deployer package [--classPath path] [--mainClass class] \
> [module] [plan] fileName
>
> Creates a configuration JAR rather than installing into the server
> environment. The fileName argument specifies the JAR to create. The
> optional classPath argument specifies a Class-Path to include in the
> JAR
> manifest. The mainClass argument specifies the Main-Class to include
> in
> the JAR manifest.
> The standard arguments may not be used with this command -- it
> never connects to a remote server.
>
>
> Aaron
>
>
James
-------
http://radio.weblogs.com/0112098/
Re: Proposed Deployer Syntax
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Oct 28, 2004, at 11:01 PM, David Blevins wrote:
> I'd like to add the ability to have the password read from standard in
> (system.in) as is done with many unix tools that set or require
> passwords.
+1
> I don't like scripts that required the password to be part of the args
> (it shows up in your command history and the processes list). You
> might as well give the info to everyone on the box--not fun if you
> provide app server hosting.
+1
> Also, how do we feel about allowing users to put username and password
> information in their home directory and looking for them there.
+1
> Being a security conscious script kinda guy I like to do thing like
> this:
>
> cat myModuleWithPlan.ear | ssh myserver.acme.com java -jar
> geronimo/bin/deployer.jar deploy
>
> Then I don't need a deployer running on a port and the only way to
> deploy something is to have a public key installed on the box (don't
> even need an account with login). This would require the deploy tool
> to read from standard in (system.in) and some flag to tell the deploy
> command to do so.
+1
-dain
Re: Proposed Deployer Syntax
Posted by David Blevins <db...@gluecode.com>.
Looks good.
I'd like to add the ability to have the password read from standard in
(system.in) as is done with many unix tools that set or require
passwords. I don't like scripts that required the password to be part
of the args (it shows up in your command history and the processes
list). You might as well give the info to everyone on the box--not fun
if you provide app server hosting.
Also, how do we feel about allowing users to put username and password
information in their home directory and looking for them there.
Being a security conscious script kinda guy I like to do thing like
this:
cat myModuleWithPlan.ear | ssh myserver.acme.com java -jar
geronimo/bin/deployer.jar deploy
Then I don't need a deployer running on a port and the only way to
deploy something is to have a public key installed on the box (don't
even need an account with login). This would require the deploy tool
to read from standard in (system.in) and some flag to tell the deploy
command to do so.
-David
On Oct 28, 2004, at 7:12 PM, Aaron Mulder wrote:
> General syntax:
>
> deployer [--uri URI [--driver JarFile] [--user username [--password \
> password]]] command arguments
>
> --uri: a URI to contact the server. The server must be running for
> this
> to work. If not specified, the deployer default to operating on a
> Geronimo server running on the standard port on localhost, or if
> nothing
> is available there, then the Geronimo server installation that the
> deployer JAR is part of.
> A URI to connect to Geronimo has the form:
> geronimo:deployer:jmx:rmi://localhost/jndi/rmi:/JMXConnector
>
> --driver: if you want to use this tool with a server other than
> Geronimo,
> then you must provide the path to its driver JAR. Currently, manifest
> Class-Path entries in that JAR are ignored.
>
> --user: if the deployment operation requires authentication, then you
> can
> specify the username to use to connect. If no password is specified,
> the
> deployer will attempt to connect to the server with no password, and if
> that fails, will prompt you for a password.
>
> --password: specifies a password to use to authenticate to the server
>
>
> Common Commands and Options
> ---------------------------
> deployer deploy [module] [plan]
>
> Normally both a module and plan are passed to the deployer.
> Sometimes the module contains a plan, or requires no plan, in which
> case
> the plan may be omitted. Sometimes the plan references a module
> already
> dpeloyed in the Geronimo server environment, in which case a module
> does
> not need to be provided.
> If the server is not currently running, the module will be marked
> to start next time the server is started.
>
> deployer undeploy [ModuleID|TargetModuleID]+
>
> Accepts the configId of a module, or the fully-qualified
> TargetModuleID identifying both the module and the server or cluster
> it's
> on, stops that module, and removes the deployment files for that module
> from the server environment. If multiple modules are specified, they
> will
> all be undeployed.
>
> deployer start [ModuleID|TargetModuleID]+
>
> Accepts the configId of a module, or the fully-qualified
> TargetModuleID identifying both the module and the server or cluster
> it's
> on, and starts that module. The module should be available to the
> server
> but not currently running. If multiple modules are specified, they
> will
> all be started.
> If the server is not running, the module will be marked to start
> next time the server is started.
>
> deployer stop [ModuleID|TargetModuleID]+
>
> Accepts the configId of a module, or the fully-qualified
> TargetModuleID identifying both the module and the server or cluster
> it's
> on, and stops that module. The module should be available to the
> server
> and running. After stop is completed, the server still has the module
> and
> deployment information available, it's just not running. If multiple
> modules are specified, they will all be stopped.
> If the server is not running, the module will be marked to not
> start next time the server is started.
>
> deployer redeploy [module] [plan] [ModuleID|TargetModuleID+]
>
> A shortcut to undeploy a module from one or more servers, then
> deploy a new version. This is not a smooth cutover -- some client
> requests may be rejected while the redeploy takes place.
> Normally both a module and plan are passed to the deployer.
> Sometimes the module contains a plan, or requires no plan, in which
> case
> the plan may be omitted. Sometimes the plan references a module
> already
> dpeloyed in the Geronimo server environment, in which case a module
> does
> not need to be provided.
> If more than one TargetModuleID is provided, all TargetModuleIDs
> must refer to the same module (just running on different targets).
> Regardless of whether the old module was running or not, the new
> module will be started (if the server is running) or marked to start
> (if
> the server is not running).
>
>
> Other Commands and Options
> --------------------------
> deployer distribute [module] [plan]
>
> Just like deploy, except the module is not started by this
> operation.
>
> deployer list-targets
>
> Lists the targets known to the server you've connected to.
> Currently, there is only ever one target, but this may eventually
> change.
>
> deployer list-modules [--all|--started|--stopped] [target*]
>
> Lists the modules available on the specified targets. If
> --started or --stopped is specified, only started or stopped modules
> will
> be listed; otherwise all modules will be listed. If no targets are
> specified, then modules on all targets will be listed; otherwise only
> modules on the specified targets. (But note that right now there's
> only
> ever 1 target.)
>
>
> Not For General Consumption Commands and Options
> ------------------------------------------------
> deployer package [--classPath path] [--mainClass class] \
> [module] [plan] fileName
>
> Creates a configuration JAR rather than installing into the server
> environment. The fileName argument specifies the JAR to create. The
> optional classPath argument specifies a Class-Path to include in the
> JAR
> manifest. The mainClass argument specifies the Main-Class to include
> in
> the JAR manifest.
> The standard arguments may not be used with this command -- it
> never connects to a remote server.
>
>
> Aaron