geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: jsr88 DeploymentStatus messasages same as command line messages?
Date Tue, 06 Dec 2005 15:49:20 GMT
There is one setting that affects JSR-88 output.  The
DeploymentManager you get is an instance of JMXDeploymentManager, and
JMXDeploymentManager has a method to set the message verbosity.  There
are actually two booleans, one that controls whether the
DeploymentManager itself logs exceptions, and one that controls
whether it puts more detail like stack traces into the status
messages.  It may be that in your environment those are buth
defaulting to false and you can cast to JMXDeploymentManager and call
the method to set one or both to true.  I don't recall the name of the
method, but it's probably the only one that takes two booleans as an
argument.  :)  Under the covers, it sets flags on its internal
CommandContext object.

All that said, in your case (deploying same app twice), the CLI deploy
tool may manually check to see whether the thing you're trying to
deploy is already depoyed (by listing the available modules via JSR-88
and comparing to that list), or it may have special handling for that
condition.  I'll take a look later.


On 12/6/05, Sachin Patel <> wrote:
> Aaron,
> Do we want to make status messages returned back from the jsr88 commands the
> same as the messages returned back from cli deploy?  In particular, the
> messages when a command is completed or failed.
> For example, in a scenario where I attempt to deploy an app where the app is
> already deployed and running, in the cli the message displayed is...
> Error: Unable to distribute snoop.war: Module snoop already exists
>     in the server.  Try to undeploy it first or use the redeploy
>     command.
> IIRC, all I get in the jsr88 status message is "Unable to distribute
> snoop.war".
> Would it be good for client code such as the tools to get rest of the
> message appended to the message?
> Also, I need to react to different scenarios to recover if errors like this
> occur so not only would a specfic message would be good, but it would be
> nice if we could have error codes, so I can code against the error codes
> rather then the entire message.
> Sachin

View raw message