geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jastrac...@mac.com
Subject Re: Proposed Deployer Syntax
Date Fri, 29 Oct 2004 18:01:45 GMT
+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/


Mime
View raw message