geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: WARNING!! re: Request for backward-incompatible gbean plan change (related to GERONIMO-450)
Date Sun, 06 Feb 2005 23:31:29 GMT
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?

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.

> 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
-- its "type" attribute, or a type generated by 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.

--
Jeremy

Mime
View raw message