geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: WARNING!! re: Request for backward-incompatible gbean plan change (related to GERONIMO-450)
Date Mon, 07 Feb 2005 00:11:15 GMT

On Feb 6, 2005, at 3:31 PM, Jeremy Boynes wrote:

> David Jencks wrote:
>>> We need this in a more obvious place than just a JIRA entry.
>> agreed.  You seem to have basic objections to the functionality, so 
>> lets settle those before we document anything further.
> I don't have objections to the basic functionality - just concerns 
> about  consequences of the way its been implemented. Clearer 
> documentation would make it easier to understand the functionality in 
> the first place.
>>>> Basically, you can either set the name (currently namePart) or the 
>>>> entire gbeanName (currently name).  If you set the name, then:
>>>> J2EEDomain,
>>>> J2EEServer,
>>>> J2EEApplication, and
>>>> J2EEModule come from the Configuration
>>>> j2eeType comes from the GBeanInfo.
>>> I didn't realise that - I think this is a *REALLY BAD* idea as it is 
>>> putting J2EE concepts in the kernel, something we were trying to 
>>> avoid from the beginning.
>> I think this is pretty clearly stated in the original feature request 
>> from Nov 7 and comment from Nov 13 on dain's addition of the type 
>> from GBeanInfo, so you had nearly 2 months to object before I 
>> actually started implementing it... Anyway, what do you suggest 
>> instead?
> AIUI if you have GBeans in a plan, then you can specify this with the 
> "type" attribute. Or is that just setting a "type" property in the 
> name and so you would need to have a new "j2eeType" attribute?

Currently the gbeaninfo type is mapped into j2eeType by the service 
builder.  You can get a different type if you specify the complete name 
or if the gbean is configured by a different builder that installs some 
other type.  You can't specify the type in xml unless you supply the 
complete name.
> Also, AIUI a builder can override this so given the builder knows the 
> type of J2EE object it is trying to build it can just specify it 
> explicitly.
>>>> In addition, the J2EEDomain and J2EEServer of a Configuration are 
>>>> copied from its parent configuration, or if it has no parent you 
>>>> must specify them in the plan for that configuration.
>>>> For a gbean from a "service" (non-j2ee module) plan, the 
>>>> G2EEApplication is "null" and the J2EEModule is the configId.
>>>> Are you also asking about all the methods in NameFactory that 
>>>> builder code uses to construct object names?  Note that builders, 
>>>> such as the ejb builder, can set the type as they please, such as 
>>>> for the kind of ejb being deployed.
>>>>> I would suggest supporting "gbeanname" as an alias for objectname 
>>>>> - objectname makes sense for a JMX based kernel but back in Nov(?) 
>>>>> we were discussing moving away from JMX artifacts.
>>>> good idea.  Lets use it instead of objectName
>>>>> Finally, is it worth adding a hybrid mode where we mix in the 
>>>>> JSR77 parts but otherwise allow the user to specify the rest, 
>>>>> something like
>>>>> <gbean appname="name=SomeName,type=SomeType" ...
>>>> I haven't seen a use for this yet.  Lets wait until we can't get by 
>>>> without it.
>>>> There's at least one gbean that seems to need a specific fixed 
>>>> object name, namely  JaasLoginServiceRemotingServer.  Naming this 
>>>> with a normal jsr-77 name would require client who attempt to login 
>>>> to know the domain, server, and module this gbean was deployed in.  
>>>> When I suggested this there was considerable opposition.  I'm 
>>>> wondering if we should cater to these fixed name gbeans by 
>>>> supplying the name from GBeanInfo somehow.  Possibly just 
>>>> commenting the plan in which it appears would be sufficient.  On 
>>>> the other hand, we might be able to  eliminate the "whole object 
>>>> name" choice if we supplied the names for these singleton gbeans 
>>>> from the gbean info.
>>> GBeanInfo contains metadata about a class of GBean and not an 
>>> instance and hence should not contain anything instance specific 
>>> such as a name.
>>> The case you describe above is just one of convenience for the 
>>> client in dealing with the common case that there is only one 
>>> provider of such a service. However, both client and server need a 
>>> mechanism to support multiple providers. On the server side, this is 
>>> easily done by specifying a different GBean name (and any resource 
>>> specifics such as port number); on the client side a mirror 
>>> mechanism is needed to support configurations other than the 
>>> default. If we a missing that, it is a problem with the client 
>>> implementation not the kernel.
>> That was my original theory, but I got some complaints when I 
>> expressed it.
>>> We need a mechanism for specifying whole object names - KISS.
>> Indeed.  Specifying reference patterms is very painful.
>>> And remember, not every configuration is J2EE and should not need to 
>>> be contaminated with J2EE artifacts.
>> well, there are several levels we could go to here...
>> Currently the kernel does use ObjectNames for components.  Do you 
>> want to make that optional?  What do we use instead?
> I proposed back in Nov changing to a generic GBeanName to eliminate 
> the dependency on JMX. You did not object back then. Touche. Pax.

I'm hoping to understand more of what you have in mind...
>> ObjectNames do have a  "domain" part.  I think it's plausible to have 
>> this be determined for a gbean in a Configuration by the 
>> Configuration itself, and have Configurations copy their parent 
>> Configuration's domain, or set it explicitly if its top level.  
>> Alternatively we could say the domain is always the name of the 
>> kernel, and is determined as you start the Configuration in the 
>> kernel.  I'm not entirely sure of the consequences of this.
>> The rest of the object name is key-value pairs.  Roughly speaking, 
>> the jsr-77 name has these principles:
>> --names have to have a "name" key
>> --names have to have a "type" key
>> --names have to indicate what deployment unit they came from
>> --names have to indicate what conceptual "server" they are on.
>> the actual key names that jsr-77 specifies, j2eethis-and-that, are 
>> pretty much irrelevant to the structure.
>> I think requiring the first 3 is reasonable for any geronimo gbean 
>> naming system.  The utility of the "server" part is less clear to me, 
>> but it does make it fairly easy to run several separate "servers" in 
>> a single kernel without name collisions. If we make the "domain" 
>> always equal to the kernel name, then the "server" part would make 
>> most sense (to me) as the part determined from the Configuration.
>> What do you think?
> The basic concept to me is that name generation should inherit from 
> the parent. I would not seem to be too hard to add properties to the 
> Configuration itself that established defaults for names within that 
> configuration; these could also be inheritable from the parent config.
> So, in general, the GBeanName could be constructed from:
> -- its "config" attribute specifying the id of the config it belonged 
> to
>    this would normally be autogenerated by the builder
> -- other attributes inherited from the Configuration's name
> -- its "name" attribute, or a name generated by the builder
(from xml config)
> -- its "type" attribute, or a type generated by the builder
(from gbean info, or the builder)
> Uniqueness would be defined by "config" and "name" - everything else 
> is sugar used for readability, referencability, or spec (JSR77) 
> compliance
> This seems like a mechanism that allows for fairly generic name 
> generation strategies. We can provide JSR77 style naming as one of 
> those strategies used specifically for J2EE compliant implementations 
> but we can also support other strategies for non-J2EE servers.

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.  Do you think that the 
"domain" part should be forced to be the kernel name?

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 

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?

david jencks

> --
> Jeremy

View raw message