geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: WARNING!! re: Request for backward-incompatible gbean plan change (related to GERONIMO-450)
Date Sun, 06 Feb 2005 19:16:15 GMT

On Feb 6, 2005, at 10:34 AM, Jeremy Boynes wrote:

> David Jencks wrote:
>> On Feb 6, 2005, at 9:41 AM, Jeremy Boynes wrote:
>>> David Jencks wrote:
>>>
>>>> I think there was no response to this, so unless someone speaks up  
>>>> really soon I'm going to implement the change.  IMO the sooner its  
>>>> changed the less confusion it will cause.
>>>
>>>
>>> Lost it in the noise - sorry.
>>>
>>> I find the construction stuff confusing, mostly due to unfamiliarity 
>>> - is there doco somewhere on what the new syntax is and what you can 
>>> set when building the name?
>> GERONIMO-450 has some info.
>
> 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.
>
>> 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?
>
>> 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?

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?

thanks
david jencks

>
> --
> Jeremy
>


Mime
View raw message