Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <4207052C.4060204@apache.org>
References: <50E0B0EA-633C-11D9-8400-000D93361CAA@yahoo.com>
 <6876D8DC-77D6-11D9-9CF9-000D93361CAA@yahoo.com> <420656C2.10209@apache.org>
 <4DBF30D3-786A-11D9-9CF9-000D93361CAA@yahoo.com>
 <4206631D.9060304@apache.org>
 <92293718-7873-11D9-9CF9-000D93361CAA@yahoo.com>
 <4206A8D1.1030506@apache.org>
 <C845AFD6-789C-11D9-9CF9-000D93361CAA@yahoo.com>
 <4207052C.4060204@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <328ECEEA-78D8-11D9-9CF9-000D93361CAA@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: WARNING!! re: Request for backward-incompatible gbean plan change
 (related to GERONIMO-450)
Date: Sun, 6 Feb 2005 23:16:34 -0800
To: dev@geronimo.apache.org

Well, I need to think about all this some more to completely understand 
it, and I don't think we'll be implementing more generic naming 
strategies for a couple of weeks anyway.

For now, I propose:

1. replace the two "hardcoded" fields on Configuration with a map

2. go forward with my original proposal in this thread of changing 
namePart to name and name to gbeanName in the xml gbean descriptor.  
(was to objectName, so its not entirely my original proposal).

I think that will get the "xml interface" looking better and remove the 
inroads of jsr-77 on the kernel.

Any objections?

thanks
david jencks


On Feb 6, 2005, at 10:05 PM, Jeremy Boynes wrote:

> David Jencks wrote:
>> Are you suggesting that instead of 2 name parts, domain and server, 
>> Configuration should have a map that different strategies can stuff 
>> things into?  That seems quite reasonable.
>
> Yes. So the parent/child relationship for Configurations allows name 
> structures to be inherited - how that happens would depend on the 
> strategy being used by the builder.
>
>> Do you think that the "domain" part should be forced to be the kernel
>> name?
>
> No. IIRC JSR77 has rules here for the J2EEDomain object but that is 
> just a J2EE artifact and there's no reason to constrain this in the 
> general case.
>
>
>> However, I don't yet see how this can be mapped into jsr-77 naming, 
>> at least without some more tweaks:
>> For an ear, all the gbeans get the same J2EEApplication, but 
>> different J2eeModule (also named different things like WebModule, etc 
>> etc).  How could this be handled while keeping all the gbeans for the 
>> ear in one configuration?
>
> I think that is a naming strategy for JSR77 and EARs. The strategy 
> would be responsible for generating names that are unique across the 
> entire EAR - IIRC JSR77 says that it is implementation defined. One 
> naive approach would be to generate an arbitrary name (e.g. just a 
> number); other more complex approaches could rely on the combination 
> of module/name pairs being unique or by generating names based on the 
> location in the EAR (e.g. name="foo/bar.war/servlet/My Cool Servlet"), 
> not that I am advocating any particular strategy here.
>
>> Also, if I understand this correctly, we'd use these sort of abstract 
>> gbean names internally and map them to jsr-77 names "on request"?  Or 
>> we'd have a flexible name generation strategy and still use 
>> ObjectNames corresponding to jsr-77 in j2ee compliant setups?
>
> GBeanName is an interface whose implementation is provided by the 
> kernel. For a JMX based kernel we would map these to the actual 
> ObjectNames used for registration with the MBeanServer; for a non-JMX 
> based kernel the implementation would handle the 
> domain+name/value-pair structure.
>
> I quite don't get what you mean by "use these sort of abstract gbean 
> names internally." The intention is to keep the concept of structured 
> names comprised of name/value pairs but abstract that away from raw 
> JMX. I see that as an orthoganal issue to the rules imposed by JSR77 
> on what those name/value pairs actually are.
>
> Hope that helps
> --
> Jeremy
>