Marina
why would need to check for those events ? The monitoring framework
should process those events for you and since you have registered
being the ejb monitoring provider, it will be able to automatically
associate the new level to the monitoring events you are sending.
jerome
On Aug 28, 2009, at 11:26 AM, Jennifer Chou wrote:
> public UnprocessedChangeEvents changed(PropertyChangeEvent[]
> propertyChangeEvents) {
> for (PropertyChangeEvent event : propertyChangeEvents) {
> if (event.getSource() instanceof ContainerMonitoring) {
> ContainerMonitoring cm =
> (ContainerMonitoring)event.getSource();
> String name = cm.getName(); <--- check for ejb-
> container
> String level = cm.getLevel();
> }
> }
>
> Marina Vatkina wrote:
>> Jennifer, Jerome,
>>
>> To which events I need to listen now to be notified about specific
>> level change?
>>
>> thanks,
>> -marina
>>
>> 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
>>>>
>>>
>>
>