admin@glassfish.java.net

Re: <engine> has no unique ID

From: Lloyd L Chambers <Lloyd.Chambers_at_Sun.COM>
Date: Fri, 21 Mar 2008 10:21:21 -0700

I want to clarify one thing: AMX can (with special handling) support
anonymous sub-elements.

But this requires special handling. Since these elements are not
MBeans, the code has to somehow recognized this (possibly
recursively), and provide an API for dealing with it, deciding on []
or List or Set to represent the sub-elements. And if those sub-
elements have sub-sub-elements, it becomes a real headache, and one
loses all the benefits of first-class MBeans.

AMX could insert automatic IDs into such elements, but it's better to
have a native "unique id" or "key" which maps to something actually in
the element.

The <jvm-options> elements (not currently working in AMX) are another
example.

In V3, I would prefer to avoid special-case code. So for now I think
I will invent automatic IDs for such anonymous elements so as to make
them 1st-class MBeans.

Lloyd

On Mar 21, 2008, at 10:03 AM, Hong Zhang wrote:
> Lloyd: thanks for finding a solution for this. The sniffer attribute
> is unique at least for the standalone war case, so it will be ok for
> TP2.
>
> Jerome: if we need to have a unique name for the Engine element,
> what should it be? I am not yet clear about how the application
> element would look like for the ear case where we have multiple wars
> inside of ear. Would we have multiple engines with sniffer value as
> "web" in that case?
>
> Thanks,
>
> - Hong
>
> Lloyd L Chambers wrote:
>
>> AMX MBeans look like this for now:
>>
>> amx:j2eeType=X-EngineConfig,name=security,X-ApplicationConfig=hello1
>> amx:j2eeType=X-EngineConfig,name=web,X-ApplicationConfig=hello1
>>
>> The "sniffer" attribute can be used as the unique ID, but I'm not
>> sure that it's unique...?
>>
>> It is preferable to have a name or id.
>>
>> Lloyd
>>
>>
>> On Mar 20, 2008, at 6:43 PM, Lloyd L Chambers wrote:
>>
>>> Hong,
>>>
>>> I see that the <engine> element has no "id" or "name". This
>>> causes a headache for MBeans; a unique ObjectName can't be
>>> generated that way. All MBeans to date are either singletons
>>> within their scope, or have a "name" or "id" or other primary key.
>>>
>>> Could we please add a name field?
>>>
>>>
>>> For now I can force the unique id to be the value of "sniffer",
>>> but that's a hack.
>>>
>>>
>>> Lloyd
>>>
>>> ---
>>> Lloyd L Chambers
>>> lloyd.chambers_at_sun.com
>>> Sun Microsystems, Inc
>>>
>>>
>>>
>>
>>
>>
>> ---
>> Lloyd L Chambers
>> lloyd.chambers_at_sun.com
>> Sun Microsystems, Inc
>>
>>
>>
>

---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc