I like the Idea. I assume the new commands enable/disable-monitoring
would still make sense, handling both the ContainerMonitoring elements
and the old attributes.
Prashanth
Jerome Dochez wrote:
> Following some more discussions, I am even wondering if we need to
> change anything for the existing monitoring levels which we could well
> keep as attributes of the monitoring-service like in V2. The
> ContainerMonitoring and MonitoringItem could be used for new or
> external extensions that would come on top of v3.
>
> that way, we would not need to change much of the UI, asadmin
> commands, dotted names execution for existing monitoring levels.
>
> what do people feel ?
>
> jerome
>
> On Aug 28, 2009, at 10:48 AM, Jennifer Chou wrote:
>
>> With this change, to turn monitoring on/off use container-monitoring
>> instead of module-monitoring-levels.
>>
>> asadmin set server.monitoring-service.container-monitoring.<config
>> element>.level=OFF or HIGH or LOW
>>
>> where config element = v2 config like web-container, jvm,
>> jdbc-connection-pool, etc
>> or new v3 config- security,
>> jersey, etc.
>>
>> There is no container-monitoring element initially in domain.xml , so
>> you need to manually create it before using the set command (this
>> will be fixed soon).
>> <monitoring-service>
>> <container-monitoring level="HIGH" name="security" />
>> <container-monitoring level="HIGH"
>> name="connector-connection-pool" />
>> <container-monitoring level="HIGH" name="http-service" />
>> <container-monitoring level="HIGH" name="jdbc-connection-pool" />
>> <container-monitoring level="HIGH" name="jvm" />
>> <container-monitoring level="HIGH" name="transaction-service" />
>> <container-monitoring level="HIGH" name="web-container" />
>> <module-monitoring-levels />
>> </monitoring-service>
>>
>> Jennifer
>>
>> Jerome Dochez wrote:
>>> I have finished introducing the support for ContainerMonitoring
>>> which is the default monitoring configuration that any container or
>>> appserver part can use to set the monitoring level. In the process I
>>> removed bunch of MonitoringItem subclasses that became unnecessary
>>> as these containers will now use the new ContainerMonitoring
>>> interface only.
>>>
>>> I also removed the upgrade code that was added to change our old
>>> monitoring configuration data to these defunct MonitoringItem
>>> subclasses. This was I believe causing the startup regression we
>>> experienced in the last promotion build.
>>>
>>> So there are 2 ways to have monitoring configuration for your
>>> component, you can use the ContainerMonitoring and have the basic
>>> level setting capability, nothing else to do, the monitoring
>>> framework will take care of changing the levels upon certain asadmin
>>> commands etc...
>>>
>>> You can also have a more sophisticated monitoring configuration, by
>>> subclassing the MonitoringItem. In such case, you will be
>>> responsible for providing asdmin commands and set the appropriate
>>> levels on the monitoring framework yourself (set of APIs to do that
>>> being worked on right now).
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>