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