geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: Deploy Tool: deploy vs redeploy
Date Sun, 26 Mar 2006 23:08:28 GMT
The problem is, this turns out to be kind of painful to use in
practice.  If you're actively developing an app for Geronimo, and you
deploy it say 100 times, like 80% of those might be redeploys and 20%
deploys, depending on whether the previous attempt succeeded or
failed.  You can't script this or run the same command over and over
again with the up arrow -- instead you have to actively think about
what to run every time.

There are two ways to fix this -- one is not to undeploy if the old
version if the new version of the app doesn't work, and the other is
to make the command-line command smart enough to figure it out.  I'll
grant that the first solution is better.  However, I think it's pretty
hard too, since it essentially requires us to be able to install two
copies of the same app/configId at the same time (we can't fully
validate a deployment without going through with it, as far as I
know).  So I think the command-line fix is the better short-term
workaround.

Thanks,
    Aaron

On 3/26/06, Gianny Damour <gianny.damour@optusnet.com.au> wrote:
> Hi,
>
> I am not really keen to see this change: I prefer users to explicitly
> state that they want to redeploy a module instead of having a command,
> which transparently does it under the cover. Also, as per the J2EE
> Deployment API, there is a clear distinction between distribute and
> redeploy and I think that such a distinction is great: a client
> explicitly instructs that a module should be redeployed.
>
> Thanks,
> Gianny
>
>
> Aaron Mulder wrote:
>
> >Currently if you use the command-line deploy tool, you have to specify
> >different deploy commands depending on whether the module is already
> >deployed.  That is, you use "deploy" the first time, and "redeploy"
> >thereafter:
> >
> >java -jar bin/deployer.jar deploy foo.war
> >java -jar bin/deployer.jar deploy foo.war   <-- fails, already deployed
> >java -jar bin/deployer.jar redeploy foo.war
> >java -jar bin/deployer.jar undeploy foo.war
> >java -jar bin/deployer.jar redeploy foo.war   <-- fails, not deployed
> >
> >After using this a bit, I'd lean toward combining these into one
> >command where the deploy tool will deploy the app if it's not already
> >running, and redeploy it if it is already running.
> >
> >Any objections to that?  I wonder if there are real-world cases where
> >you'd rather get the error if the deployment state isn't what you'd
> >expect.  On the other hand, that seems seriously outweighed by the
> >number of times I up-arrow and repeat the previous command and it
> >gives an error because it's already deployed or whatever.  At this
> >point, I think making things easier during development ought to be the
> >higher priority.
> >
> >Thanks,
> >    Aaron
> >
> >
> >
> >
> >
>
>
>

Mime
View raw message