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 Sun, 06 Feb 2005 18:34:05 GMT
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.

> 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.

> 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.

We need a mechanism for specifying whole object names - KISS.

And remember, not every configuration is J2EE and should not need to be 
contaminated with J2EE artifacts.


View raw message