On Oct 28, 2004, at 11:35 AM, Aaron Mulder wrote:
On Thu, 28 Oct 2004, Dain Sundstrom wrote:These are the main commands. I like hiram's idea of dropping the -- from them like svn and cvs do. I don't see why you have extra restrictions on install. Actually, why not just drop install since it is just deploy?
Sure, we can restructure the syntax. The difference
between install and deploy would be clearer if we called them "distribute"
and "deploy" to match the JSR-88 terms -- I only used "install" because I
thought we wanted to preserve the existing syntax. So long as we're going
to change it anyway...
But the difference is that "distribute" does not start a module,
so "deploy == distribute + start". In concept, you could distribute an
app, make sure it gets processed and loaded on to all the servers, and
then bang! issue a start command to start them all at once. I guess. I
don't really plan to use that much myself, but since the API capability is
there, why not allow it from the tool? We can just list that under
"rarely used".
+ 1
Also, "start" is not meaningful for the current deployer -- not
only can it not start because the server is not running, it does not alter
the configuration in such a way that the module should be started next
time the server is started. So "install" in the current tool really is
equivalent to "distribute" not "deploy". If we want the default command
to be "deploy", then when the tool runs in "server is offline" mode (like
the current tool), it should update var/config/config.list to add the
module to that.
+1
--modulelist a list of TargetModuleID names to start, stop, or undeploy
--list-modules gives you a list of modules available from the management server you connected to. defaults to all targets, or use --targets
What is the difference between these two?
Well, when starting, stopping, or undeploying, you must give the
server a list of TargetModuleIDs to start, stop, or undeploy. Where a
TargetModuleID is some product-specific amalgamation of a unique server or
cluster ("Target") ID and a module ID. So if the same EAR is deployed on
3 servers, you could stop it on 2 of them with 2 TargetModuleID's. We'll
have to think about what our Target IDs should look like, but they'll
likely be ugly (host name and installation path, perhaps?) or else a
unique name that a user configures somewhere, and the Target Module ID's
will presumably be that plus either a ConfigId or ObjectName identifying
the module. I need to look at what the current TargetModuleID
implementation does.
Anyway, one of these arguments gives the list of TargetModuleIDs
that you want to start, stop, etc. The other is an inquiry command, where
you give it a list of targets, and it gives you back a list of
TargetModuleIDs available on those targets. So if you don't know what
you're dealing with, it might go like this:
deployer list-targetsserver1 server2 clusterdeployer list-modules --targets clustercluster/app1.ear cluster/webapp2.war cluster/dbpool.rardeployer stop --modules cluster/webapp2.war,cluster/app1.earcluster/app1.ear stopped cluster/webapp2.war stopped
Perhaps we could omit the --modules argument and just assume everything at
the end of the command without a -- prefix is a module to operate on.
+1
--list-targets gives you a list of targets available from the management server you connected to
--targets a list of targets to get modules for, or to install
or deploy to. defaults to all targets available
from the current management server if a URL is
specified or defaulted to. defaults to the current
server environment only if the URL is null.
These are almost never going to be used, so should be documented as such
Well, until we implement clusters, or a single administration point for multiple servers (similar to WebLogic admin server + many managed servers).
Ya, but until we implement clusters, I doubt they will be used, and then we won't need them :)
--classPath classpath to set for an executable module
--mainClass main class for an executable module
--outfile build a CAR instead of deploying into the server environment
Options of creating an output Jar... these are rarely used and should be documented as such.
I don't like them at all because they can't be done via JSR-88. So this introduces not only an additional implementation path, but also incompatibility with many of the other options that require JSR-88.
What do we care about 88 purity? We can add what ever we want to our own tool. If someone wants to use a limited cross platform tool, the can still use our raw driver.
If nothing else, can we please please have another tool just to build output JARs? This mode of operation has no relation to the normal deployer operation.
I agree, but that is another tool for another day.
(Though in truth, deploying while the server is not running has the same disadvantage.)
And it has some advantages... like if you mess up you server so it won't start, you can start over by redeploying the server plan.
--driver JAR of the server driver, if not already on classpath.
only necessary when non-Geronimo server targeted
I don't think there is any reason for us to support other app servers
drivers. This is a tool by geronimo for geronimo. Let the ide vendors
come up with the universal adapter.
If we implement it using JSR-88, which is the most straightforward
way for all normal operations (so long as the server is running), then we
get support for other app servers for free.
Who cares? I don't think we should limit our selves to pure 88 just so we can have support for other servers. Frankly, I would be shocked if anyone used our command line tool for anther server, when every server ships with a tool custom to the server (with enhancements).
Deployment while the server is not running is the tricky case.
We can shoehorn it into JSR-88 by having a URL mode that requires that a
local Kernel be started before JSR-88 is invoked (like the way the
deployer tool runs now), but Jeremy seemed to be strongly opposed to this.
I don't really like having 2 different code paths for standard operation,
though, so if we go with one tool I might favor this, hacky as it is.
I was totally with you, up to this section. I don't think we shoe horn it at all. If you are running offline, you simply execute the exiting code, which isn't 88 at all. Use 88 when it is nice fit and something custom when it isn't.
So I see the following as being the most common usage:
deployer deploy funk.war deployer undeploy funk
Unfortunately, both of these are illegal according to JSR-88. You need to specify a deployment plan for the module, and to undeploy you need to specify a target module ID including the target name and the module name.
Again, I frankly don't care what 88 says is legal. Geronimo lets you deploy most application without plans. David Jencks just committed a big change to resource adapter naming so most ears don't need a plan at all. If we followed this logic, we would have to have the following plan most of the time:
<?xml> <plan/>
We could build a workaround for the first -- if no plan is specified we load the driver, assume the driver loads the plan or creates a default one from deployment information in the archives, save the plan to a temp file, and then send the module and plan together as required and delete the temp file.
No just pass a null plan to our driver, and it will happily continue without one.
For the second one, we'd assume you want to operate on all
targets. Then we'd get the list of all TargetModuleIDs for all targets,
and for each, check if the name you specified is either equal to
TargetModuleID.toString, or TargetModuleID.getModuleID.
Sure... what ever we are doing today in the maven plugin
So I guess we could support both usages with a sufficiently clever tool.
+1
I'm thinking that the current Commons CLI logic for the arguments
isn't going to work, since there will be different available arguments
depending on your primary command. Perhaps we can read the first argument
and then construct a different CLI chain accordingly.
I don't know. There is a new version of the CLI package that may support this, but if it doesn't, I would just write some code that can parse all arguments and have an external method that does the semantic verification.
Also, with all the votes for 1 tool, I'm assuming that you're OK with the basic Geronimo deployment tool depending on JSR-88.
Yes
-dain
