OK, thanks.
Yes, it's fine to register them prior to the parent existing, but once
AMX loads, it will want the correct behavior from getParent().
There is a potential race condition: AMX starts the validation thread
as soon as DomainRoot and its immediate children load.
If the parent is an MBean that is not yet registered by the time the
validation thread checks, then validation would fail, because the
parent would not be found.
Lloyd
On Jun 29, 2009, at 1:37 PM, Ken Cavanaugh wrote:
> Lloyd Chambers wrote:
>>
>> There is one other potential problem: when are the MBeans being
>> created?
>>
>> If they are created before DomainRoot, how can they have a parent?
> So long as they are created with the correct ObjectName of the
> parent, creation is fine.
> The parent isn't actually needed until someone calls getParent on
> the Gmbal ManagedObjectManager root,
> which must result in the ObjectName of the parent.
>>
>> Could that be the problem?
> Doesn't seem like it.
>
> Ken.
>>
>> Lloyd
>>
>> On Jun 29, 2009, at 1:17 PM, Ken Cavanaugh wrote:
>>
>>> Lloyd Chambers wrote:
>>>> Someone has been creating AMX MBeans in Glassfish V3 using Gmbal
>>>> (good).
>>>>
>>>> Except that the MBeans are in violation of the AMX spec: the
>>>> Parent attribute is being returned as null. This will cause all
>>>> sorts of downstream problems, namely breaking any client proxy
>>>> code involving any non-complaint MBeans. It is also causing a
>>>> mess in the server log and interfering with my progress elsewhere
>>>> in AMX.
>>>>
>>>> In particular, the following MBeans fail when asked for the
>>>> critical 'Parent' attribute, returning 'null':
>>>>
>>>> v3:type=JVMClassLoadingStatsProvider,name=jvm/class-loading-
>>>> system,pp=/mon/server-mon[das]
>>>> v3:type=JVMRuntimeStatsProvider,name=jvm/runtime,pp=/mon/server-
>>>> mon[das]
>>>> v3:type=JVMMemoryStatsProvider,name=jvm/memory,pp=/mon/server-
>>>> mon[das]
>>>> v3:type=JVMGCStatsProvider,name=jvm/garbage-collectors,pp=/mon/
>>>> server-mon[das]
>>>> v3:type=JVMCompilationStatsProvider,name=jvm/compilation-
>>>> system,pp=/mon/server-mon[das]
>>>> v3:type=JVMOSStatsProvider,name=jvm/operating-system,pp=/mon/
>>>> server-mon[das]
>>>> v3:pp=/mon/server-
>>>> mon[das],type=HttpServiceStatsProvider,name=http-service/__asadmin
>>>>
>>>> Will whoever is responsible for these MBeans please contact me to
>>>> resolve this--thanks.
>>>>
>>> Keep me in the loop on this, in case this is a Gmbal problem. I'm
>>> concerned about
>>> MBeans registered at the Gmbal root using a ManagedObjectManager
>>> that was created
>>> with createFederated (the normal case in GFv3). I'm checking my
>>> tests and investigating this now.
>>>
>>> Thanks,
>>>
>>> Ken.
>>>
>>>
>>
>> Lloyd Chambers
>> lloyd.chambers_at_sun.com
>> GlassFish Team
>>
>>
>>
>
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish Team