Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ammulder@gmail.com designates
 64.233.162.199 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=WGjSojjBLNAVv4Bg1x5saJ9Tg/wppfzH88lzb9xf9v4dADylVsObhGxh9PFIZLJoDKY4MSNUKlYxhKKulv47GwbstDBLoRPMouPwoe3BW4bwsvIEtL62duGpl+IibvxPfjq81USX2udVDFIdESCANb57cia+r+P4p/ZsrhbiwvE=
Message-ID: <74e15baa0512060749i6176d2b0v1310384fe8e81edc@mail.gmail.com>
Date: Tue, 6 Dec 2005 10:49:20 -0500
From: Aaron Mulder <ammulder@alumni.princeton.edu>
Sender: ammulder@gmail.com
To: dev@geronimo.apache.org
Subject: Re: jsr88 DeploymentStatus messasages same as command line messages?
In-Reply-To: <BFBB15EF.B44%sppatel@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <BFBB15EF.B44%sppatel@gmail.com>

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.

Thanks,
   Aaron

On 12/6/05, Sachin Patel <sppatel@gmail.com> 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 th=
is
> 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
>
>
>