Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <Pine.LNX.4.58.0410282019160.12237@saturn.opentools.org>
References: <Pine.LNX.4.58.0410282019160.12237@saturn.opentools.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <0219EE71-2952-11D9-9E88-000D93C5B79C@gluecode.com>
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom <dsundstrom@gluecode.com>
Subject: Re: Proposed Deployer Syntax
Date: Thu, 28 Oct 2004 19:26:58 -0700
To: dev@geronimo.apache.org

+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