ok, so did we already change the containers code to use the new
configuration data or are they still using the old attributes ?
AFAIR, in v2, the monitoring levels were set using dotted names which
of course will continue to work unmodified. We indeed should have the
new enable/disable commands to handle transparently the old attributes
and new ContainerMonitoring elements.
Jerome
On Aug 28, 2009, at 8:00 PM, Prashanth Abbagani wrote:
> 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
>>>>
>>>
>>
>