You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2005/02/06 01:31:14 UTC
WARNING!! re: Request for backward-incompatible gbean plan change (related to GERONIMO-450)
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.
BE WARNED!
thanks
david jencks
On Jan 10, 2005, at 11:17 AM, David Jencks wrote:
> I recently committed a partial implementation of GERONIMO-450,
> simplifying the specification of a gbean name in a plan, and making
> gbean names similar to jsr-77 names.
>
> Currently the syntax is like this:
>
> <gbean namePart="SomeName" type="JCAWorkManager" class="...
>
> or
>
> <gbean
> name="geronimo.server:
> J2EEServer=geronimo,J2EEApplication=null,J2EEModule=org/apache/
> geronimo/Server,j2eeType=JCAWorkManager,name=SomeName" class="....
>
> I would like to change this to the more straightforward:
>
> <gbean name="SomeName" type="JCAWorkManager" class="...
>
> or
>
> <gbean
> objectname="geronimo.server:
> J2EEServer=geronimo,J2EEApplication=null,J2EEModule=org/apache/
> geronimo/Server,j2eeType=JCAWorkManager,name=SomeName" class="....
>
>
> Please comment on whether you think this is a good idea and when it
> should be committed. Do we need a vote?
>
> Many thanks,
> david jencks
>
Re: WARNING!! re: Request for backward-incompatible gbean plan change (related to GERONIMO-450)
Posted by David Jencks <da...@yahoo.com>.
On Feb 7, 2005, at 10:44 AM, Dain Sundstrom wrote:
> On Feb 7, 2005, at 10:04 AM, David Jencks wrote:
>
>>
>> On Feb 7, 2005, at 9:40 AM, Dain Sundstrom wrote:
>>
>>> On Feb 6, 2005, at 11:16 PM, David Jencks wrote:
>>>
>>>> Well, I need to think about all this some more to completely
>>>> understand it, and I don't think we'll be implementing more generic
>>>> naming strategies for a couple of weeks anyway.
>>>>
>>>> For now, I propose:
>>>>
>>>> 1. replace the two "hardcoded" fields on Configuration with a map
>>>
>>> Maybe I skimmed to fast, but what "hardcoded" fields?
>>
>> private final String domain;
>> private final String server;
>
> I remember these being in there for a reason, but don't remember why.
> Do you?
they let a configuration use the same domain and server as its parent.
If you had a configuration containing no gbeans, there would otherwise
be no way to determine domain and server
david jencks
>
> -dain
>
Re: WARNING!! re: Request for backward-incompatible gbean plan change (related to GERONIMO-450)
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Feb 7, 2005, at 10:04 AM, David Jencks wrote:
>
> On Feb 7, 2005, at 9:40 AM, Dain Sundstrom wrote:
>
>> On Feb 6, 2005, at 11:16 PM, David Jencks wrote:
>>
>>> Well, I need to think about all this some more to completely
>>> understand it, and I don't think we'll be implementing more generic
>>> naming strategies for a couple of weeks anyway.
>>>
>>> For now, I propose:
>>>
>>> 1. replace the two "hardcoded" fields on Configuration with a map
>>
>> Maybe I skimmed to fast, but what "hardcoded" fields?
>
> private final String domain;
> private final String server;
I remember these being in there for a reason, but don't remember why.
Do you?
-dain
Re: WARNING!! re: Request for backward-incompatible gbean plan change (related to GERONIMO-450)
Posted by David Jencks <da...@yahoo.com>.
On Feb 7, 2005, at 9:40 AM, Dain Sundstrom wrote:
> On Feb 6, 2005, at 11:16 PM, David Jencks wrote:
>
>> Well, I need to think about all this some more to completely
>> understand it, and I don't think we'll be implementing more generic
>> naming strategies for a couple of weeks anyway.
>>
>> For now, I propose:
>>
>> 1. replace the two "hardcoded" fields on Configuration with a map
>
> Maybe I skimmed to fast, but what "hardcoded" fields?
private final String domain;
private final String server;
>
>> 2. go forward with my original proposal in this thread of changing
>> namePart to name and name to gbeanName in the xml gbean descriptor.
>> (was to objectName, so its not entirely my original proposal).
>
> +1
>
>> I think that will get the "xml interface" looking better and remove
>> the inroads of jsr-77 on the kernel.
>
> What inroads?
primarily those two fields
david jencks
>
>
> On Feb 6, 2005, at 10:05 PM, Jeremy Boynes wrote:
>
>> David Jencks wrote:
>>> Do you think that the "domain" part should be forced to be the kernel
>>> name?
>>
>> No. IIRC JSR77 has rules here for the J2EEDomain object but that is
>> just a J2EE artifact and there's no reason to constrain this in the
>> general case.
>
> The kernel name is always the domain name. It has been that way for a
> while now.
>
> -dain
>
Re: WARNING!! re: Request for backward-incompatible gbean plan change (related to GERONIMO-450)
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Feb 6, 2005, at 11:16 PM, David Jencks wrote:
> Well, I need to think about all this some more to completely
> understand it, and I don't think we'll be implementing more generic
> naming strategies for a couple of weeks anyway.
>
> For now, I propose:
>
> 1. replace the two "hardcoded" fields on Configuration with a map
Maybe I skimmed to fast, but what "hardcoded" fields?
> 2. go forward with my original proposal in this thread of changing
> namePart to name and name to gbeanName in the xml gbean descriptor.
> (was to objectName, so its not entirely my original proposal).
+1
> I think that will get the "xml interface" looking better and remove
> the inroads of jsr-77 on the kernel.
What inroads?
On Feb 6, 2005, at 10:05 PM, Jeremy Boynes wrote:
> David Jencks wrote:
>> Do you think that the "domain" part should be forced to be the kernel
>> name?
>
> No. IIRC JSR77 has rules here for the J2EEDomain object but that is
> just a J2EE artifact and there's no reason to constrain this in the
> general case.
The kernel name is always the domain name. It has been that way for a
while now.
-dain
Re: WARNING!! re: Request for backward-incompatible gbean plan change
(related to GERONIMO-450)
Posted by Jeremy Boynes <jb...@apache.org>.
David Jencks wrote:
> Well, I need to think about all this some more to completely understand
> it, and I don't think we'll be implementing more generic naming
> strategies for a couple of weeks anyway.
>
> For now, I propose:
>
> 1. replace the two "hardcoded" fields on Configuration with a map
>
> 2. go forward with my original proposal in this thread of changing
> namePart to name and name to gbeanName in the xml gbean descriptor.
> (was to objectName, so its not entirely my original proposal).
>
> I think that will get the "xml interface" looking better and remove the
> inroads of jsr-77 on the kernel.
>
> Any objections?
>
Not to this. Let's open a JIRA issue though about the inroads to date
and make sure that we undo them at some point.
--
Jeremy
Re: WARNING!! re: Request for backward-incompatible gbean plan change (related to GERONIMO-450)
Posted by David Jencks <da...@yahoo.com>.
Well, I need to think about all this some more to completely understand
it, and I don't think we'll be implementing more generic naming
strategies for a couple of weeks anyway.
For now, I propose:
1. replace the two "hardcoded" fields on Configuration with a map
2. go forward with my original proposal in this thread of changing
namePart to name and name to gbeanName in the xml gbean descriptor.
(was to objectName, so its not entirely my original proposal).
I think that will get the "xml interface" looking better and remove the
inroads of jsr-77 on the kernel.
Any objections?
thanks
david jencks
On Feb 6, 2005, at 10:05 PM, Jeremy Boynes wrote:
> David Jencks wrote:
>> 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.
>
> Yes. So the parent/child relationship for Configurations allows name
> structures to be inherited - how that happens would depend on the
> strategy being used by the builder.
>
>> Do you think that the "domain" part should be forced to be the kernel
>> name?
>
> No. IIRC JSR77 has rules here for the J2EEDomain object but that is
> just a J2EE artifact and there's no reason to constrain this in the
> general case.
>
>
>> 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 configuration?
>
> I think that is a naming strategy for JSR77 and EARs. The strategy
> would be responsible for generating names that are unique across the
> entire EAR - IIRC JSR77 says that it is implementation defined. One
> naive approach would be to generate an arbitrary name (e.g. just a
> number); other more complex approaches could rely on the combination
> of module/name pairs being unique or by generating names based on the
> location in the EAR (e.g. name="foo/bar.war/servlet/My Cool Servlet"),
> not that I am advocating any particular strategy here.
>
>> 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?
>
> GBeanName is an interface whose implementation is provided by the
> kernel. For a JMX based kernel we would map these to the actual
> ObjectNames used for registration with the MBeanServer; for a non-JMX
> based kernel the implementation would handle the
> domain+name/value-pair structure.
>
> I quite don't get what you mean by "use these sort of abstract gbean
> names internally." The intention is to keep the concept of structured
> names comprised of name/value pairs but abstract that away from raw
> JMX. I see that as an orthoganal issue to the rules imposed by JSR77
> on what those name/value pairs actually are.
>
> Hope that helps
> --
> Jeremy
>
Re: WARNING!! re: Request for backward-incompatible gbean plan change
(related to GERONIMO-450)
Posted by Jeremy Boynes <jb...@apache.org>.
David Jencks wrote:
> 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.
Yes. So the parent/child relationship for Configurations allows name
structures to be inherited - how that happens would depend on the
strategy being used by the builder.
> Do you think that the "domain" part should be forced to be the kernel
> name?
>
No. IIRC JSR77 has rules here for the J2EEDomain object but that is just
a J2EE artifact and there's no reason to constrain this in the general case.
> 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
> configuration?
>
I think that is a naming strategy for JSR77 and EARs. The strategy would
be responsible for generating names that are unique across the entire
EAR - IIRC JSR77 says that it is implementation defined. One naive
approach would be to generate an arbitrary name (e.g. just a number);
other more complex approaches could rely on the combination of
module/name pairs being unique or by generating names based on the
location in the EAR (e.g. name="foo/bar.war/servlet/My Cool Servlet"),
not that I am advocating any particular strategy here.
> 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?
>
GBeanName is an interface whose implementation is provided by the
kernel. For a JMX based kernel we would map these to the actual
ObjectNames used for registration with the MBeanServer; for a non-JMX
based kernel the implementation would handle the domain+name/value-pair
structure.
I quite don't get what you mean by "use these sort of abstract gbean
names internally." The intention is to keep the concept of structured
names comprised of name/value pairs but abstract that away from raw JMX.
I see that as an orthoganal issue to the rules imposed by JSR77 on what
those name/value pairs actually are.
Hope that helps
--
Jeremy
Re: WARNING!! re: Request for backward-incompatible gbean plan change (related to GERONIMO-450)
Posted by David Jencks <da...@yahoo.com>.
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.
yes.
>
>>>
>>>> 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
configuration?
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?
thanks
david jencks
>
> --
> Jeremy
>
Re: WARNING!! re: Request for backward-incompatible gbean plan change
(related to GERONIMO-450)
Posted by Jeremy Boynes <jb...@apache.org>.
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
Re: WARNING!! re: Request for backward-incompatible gbean plan change (related to GERONIMO-450)
Posted by David Jencks <da...@yahoo.com>.
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
>
Re: WARNING!! re: Request for backward-incompatible gbean plan change
(related to GERONIMO-450)
Posted by Jeremy Boynes <jb...@apache.org>.
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.
--
Jeremy
Re: WARNING!! re: Request for backward-incompatible gbean plan change (related to GERONIMO-450)
Posted by David Jencks <da...@yahoo.com>.
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.
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.
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.
thanks
david jencks
>
> --
> Jeremy
>
Re: WARNING!! re: Request for backward-incompatible gbean plan change
(related to GERONIMO-450)
Posted by Jeremy Boynes <jb...@apache.org>.
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?
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.
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" ...
--
Jeremy