geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Proposed Deployer Syntax
Date Fri, 29 Oct 2004 02:12:06 GMT
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