Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 44528 invoked from network); 17 Nov 2005 12:46:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 17 Nov 2005 12:46:17 -0000 Received: (qmail 19760 invoked by uid 500); 17 Nov 2005 12:46:13 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 19709 invoked by uid 500); 17 Nov 2005 12:46:12 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 19698 invoked by uid 99); 17 Nov 2005 12:46:12 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Nov 2005 04:46:12 -0800 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=FROM_HAS_MIXED_NUMS,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of c1vamsi1c@gmail.com designates 64.233.182.194 as permitted sender) Received: from [64.233.182.194] (HELO nproxy.gmail.com) (64.233.182.194) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Nov 2005 04:47:46 -0800 Received: by nproxy.gmail.com with SMTP id i2so463364nfe for ; Thu, 17 Nov 2005 04:45:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=R9FljAChK4cKwai9OwAoHkyf62wMjS9nG52xSnD00lKnsriTGRqbxITotIaxHYasO8cPAZYTK9LnuARoKbeacNve00h1MvSTGKQJaAMkPq+KupE1HLws2tujFq2efUCKIW0BSfnaa7zvievcYZc+SYXjHsBldid17s7rrdU1ErE= Received: by 10.48.236.15 with SMTP id j15mr403021nfh; Thu, 17 Nov 2005 04:45:50 -0800 (PST) Received: by 10.48.234.13 with HTTP; Thu, 17 Nov 2005 04:45:50 -0800 (PST) Message-ID: <22d56c4d0511170445t5969d296we2663aae3a3c4b2a@mail.gmail.com> Date: Thu, 17 Nov 2005 18:15:50 +0530 From: Vamsavardhana Reddy To: dev@geronimo.apache.org Subject: Re: Constructing deployment plans from Configuration GBeanData In-Reply-To: <5fe06e27c9131035126fcf8cb7075ddc@yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10014_14991122.1132231550774" References: <22d56c4d0511160410t1d099c47g6522e1607ff56909@mail.gmail.com> <5fe06e27c9131035126fcf8cb7075ddc@yahoo.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_10014_14991122.1132231550774 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline If deployment plans are inside the archive (ear, war, etc.) they can be obtained from config-store. If the deployment plan is supplied as an external file to the deployer and if the original file is not available, th= e only way to get any information on the configuration is from the Configuration GBeanData obtained from the kernel at runtime or from deserializing config.ser files under config-store. For analyzing any problems after an application is deployed, deployment plans will certainly be helpful. -Vamsi On 11/16/05, David Jencks wrote: > > > On Nov 16, 2005, at 4:10 AM, Vamsavardhana Reddy wrote: > > > I am trying to reconstruct deployment plan from the Configuration > > GBeanData. > > umm, why? > > > > > I have a code segment like the following. > > ObjectName configName =3D > > Configuration.getConfigurationObjectName(configId); > > GBeanData configData =3D kernel.getGBeanData(configName); > > > > Once I have the GBeanData object, I am retreiving the attributes, > > references & any GBeans inside the configuration and printing out the > > information. With this procedure, I am able to reconstruct the > > deployment plan for some, but not all :(, of the configurations in > > Geronimo. Is there any other way of getting deployment plan out of > > configuration GBeanData object? > > > > this will probably work for gbeans that came from a configuration > directly, rather than e.g. an ejb container gbean, and that do not have > any xml-attributes. I don't think you will succeed in generating a > gbean configuration for something like an ejb container. Again, what > is your goal? This is very much akin to writing a java disassembler. > > thanks > david jencks > > ------=_Part_10014_14991122.1132231550774 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline If deployment plans are inside the archive (ear, war, etc.) they can be obtained from config-store.  If the deployment plan is supplied as an external file to the deployer and if the original file is not available, the only way to get any information on the configuration is from the Configuration GBeanData obtained from the kernel at runtime or from deserializing config.ser files under config-store.  For analyzing any problems after an application is deployed, deployment plans will certainly be helpful.

-Vamsi
On 11/16/05, David Jencks <d= avid_jencks@yahoo.com> wrote:

On Nov 16, 2005, at 4:10 AM, Vamsavardhana Reddy wrote:

> I a= m trying to reconstruct deployment plan from the Configuration
> GBea= nData.

umm, why?

>
>  I have a code segmen= t like the following.
>   ObjectName configName =3D
> Configuration.getCon= figurationObjectName(configId);
>   GBeanData configData = =3D kernel.getGBeanData(configName);
>
>  Once I have= the GBeanData object, I am retreiving the attributes,
> references & any GBeans inside the configuration and printing = out the
> information. With this procedure, I am able to reconstruct = the
> deployment plan for some, but not all :(, of the configurations= in
> Geronimo. Is there any other way of getting deployment plan out of=
> configuration GBeanData object?
>

this will probably = work for gbeans that came from a configuration
directly, rather than=20 e.g. an ejb container gbean, and that do not have
any xml-attributes.&nb= sp; I don't think you will succeed in generating a
gbean configurat= ion for something like an ejb container.  Again, what
is your = goal?  This is very much akin to writing a java disassembler.

thanks
david jencks


------=_Part_10014_14991122.1132231550774--