dev@glassfish.java.net

Re: [v3 monitoring] 2 monitoring level settings for each type?

From: Marina Vatkina <Marina.Vatkina_at_Sun.COM>
Date: Fri, 21 Aug 2009 00:10:00 -0700

(I didn't realize the discussion went away from the dev alias)

Nandini Ektare wrote:
> Hi Marina,
>
> Marina Vatkina wrote:
>
>> Hi Nandini,
>>
>> Yes, I suspected that something is caused by the changes that are
>> happening now, and while I hope only 1 level will need to be set in
>> v3, it's still (or may be even more so) very confusing...
>>
>> 1. Why is there a need to a *transaction-service-mi* element is the
>> tree? With your example level is just a sub-element of the
>> transaction-service, which in turn is a child of the monitoring-service?
>
> A monitoring module can have any config. Flexible config includes
> attribs and sub elements. Level happens to be an attrib of
> transaction-service-mi.

It's currently an attrib of the transaction-service (which is being added to the
transaction-service-mi)
>
>> 2. What does *-mi* stands for in that name?
>
> I think that will go away. Not sure why it was included. But in any case
> a monitorable module has the final say in name, attribs, sub-elements-
> basically full control over its complete tree structure. So the element
> name with *-mi is not incorrect. But I agree it is not as intuitive as
> transaction-service and considering v2's terminology, -mi should not
> have been there.
>

"transaction-service-mi" is somehow getting generated into the
target/apt-generated-sources/.../TransactionServiceMIInjector.java - so I don't
think that I can control it :(.

thanks,
-marina

> Nandini
>
>> thanks,
>> -marina
>>
>> Nandini Ektare wrote:
>>
>>>
>>> I will let Monitoring team answer your query as they would know
>>> best...but if you are interested here is some legacy context of
>>> existence of two levels:
>>>
>>> /configs.config.server-config.monitoring-service.module-monitoring-levels.transaction-service=OFF
>>> /comes from v2.
>>>
>>> In v3, monitoring-service is allowed to have a free form config per
>>> monitoring module
>>> For example in your case,
>>> /configs.config.server-config.*monitoring-service.transaction-service-mi*.transaction-service.level=OFF
>>> /
>>> transaction-service-mi is the new module with monitoring config and
>>> it can choose to have any config tree as follows
>>> <monitoring-service>
>>> <transaction-service//>
>>> / .... free form config of transaction service with new attribs
>>> and sub elements./
>>> </transaction-service>
>>> </monitoring-service>
>>> Right now it is:
>>> <monitoring-service>
>>> <transaction-service level="ON" />
>>> </monitoring-service>
>>>
>>> Presently both forms co-exist for module that came from v2 (so say we
>>> have a new scripting engine xxx, you will not find an attribute in
>>> module-monitoring-levels for that)
>>>
>>> Going forward v3 approach will be used. So using
>>> /configs.config.server-config.monitoring-service.transaction-service-mi.transaction-service.level=OFF
>>>
>>> /would make more sense. But I don't know what field the monitoring
>>> infrastructure is presently hooked into.
>>>
>>> -Nandini
>>>
>>> Marina Vatkina wrote:
>>>
>>>> Prashanth, Sreeni,
>>>>
>>>> Which one is the actual monitoring level:
>>>>
>>>> configs.config.server-config.monitoring-service.module-monitoring-levels.transaction-service=OFF
>>>>
>>>> configs.config.server-config.monitoring-service.transaction-service-mi.transaction-service.level=OFF
>>>>
>>>>
>>>> thanks,
>>>> -marina
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>
>