geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: WARNING!! re: Request for backward-incompatible gbean plan change (related to GERONIMO-450)
Date Mon, 07 Feb 2005 06:05:32 GMT
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 

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

View raw message