geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <hi...@hiramchirino.com>
Subject Re: Proposed Deployer Syntax
Date Fri, 29 Oct 2004 16:09:38 GMT
+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
>
>  
>


Mime
View raw message