look at ResourceManager in javaee-core, that's a example...
in short, just implement the ConfigListener interface when being
injected with configuration, you will be called back each time any of
your injected configuration has changed.
jerome
On Mar 17, 2008, at 12:16 PM, Timothy Quinn wrote:
> Jerome Dochez wrote:
>> Tim,
>>
>> The autodeployer running in the server process should not use the
>> MBean notification but should use the lower level admin
>> notification mechanism based on the ConfigListener.
> This is what I expected but I wanted to be very clear on this.
>> Are you injected with your configuration at the first place ?
> Yes, from my earlier note:
>> And currently it is using @Inject to obtain a reference to the
>> config information of interest.
> Can you point me to examples of the ConfigListener usage already in
> the code or doc for its usage? I know a while ago you pointed me a
> JUnit test but I didn't get much help from that because that was not
> code that runs as part of the app server.
>
> Thanks.
>
> - Tim
>>
>> jerome
>>
>> On Mar 17, 2008, at 10:48 AM, Timothy Quinn wrote:
>>
>>> Thanks for the thorough explanation. I need to work through it
>>> more carefully to understand it fully.
>>>
>>> One quick question - Is the notification predicated on a
>>> connection to the MBeanServer? In my case - in which the
>>> autodeployer wants to be aware of changes to certain config values
>>> - the interested code is in the server JVM, not a remote JVM. And
>>> currently it is using @Inject to obtain a reference to the config
>>> information of interest.
>>> Is there a similar or parallel mechanism that works for co-located
>>> listeners without going through the MBeanServer?
>>>
>>> Thanks.
>>>
>>> - Tim
>>>
>>> Lloyd L Chambers wrote:
>>>> Tim,
>>>>
>>>> [cc'ing 'admin' as this is of general interest]
>>>>
>>>> It's standard JMX Notification, documented somewhere in the JMX
>>>> code. But AMX provides some tools to make it easier, at least
>>>> for more advanced cases.
>>>>
>>>> For an example of a listener, see
>>>> com.sun.appserv.management.util.jmx.MBeanRegistrationListener.
>>>>
>>>> You don't need to extend
>>>> com.sun.appserv.management.util.jmx.NotificationListenerBase, but
>>>> doing so provides some benefits, especially if the intent is to
>>>> listen to more than one MBean: NotificationListenerBase can
>>>> except an ObjectName *pattern*, thus allowing listening to many
>>>> different MBeans eg all AMX MBeans.
>>>>
>>>> Assuming you want to listen for AttributeChangeNotification, do
>>>> this:
>>>>
>>>> import com.sun.appserv.management.util.jmx.JMXUtil;
>>>> import com.sun.appserv.management.util.jmx.
>>>> NotificationListenerBase;
>>>> import com.sun.appserv.management.base.AMX;
>>>> import com.sun.appserv.management.client.ProxyFactory;
>>>>
>>>> MBeanServerConnection mbsc = <an MBeanServer or
>>>> MBeanServerConnection>;
>>>>
>>>> // eg JMXUtil.newObjectNamePattern( AMX.JMX_DOMAIN, "*" );
>>>> // If you have an 'amx', you can do
>>>> Util.getExtra(amx).getObjectName(amx)
>>>> final ObjectName objectName = <an ObjectName or ObjectName pattern>
>>>> MyAttributeChangeListener myListener = new
>>>> MyAttributeChangeListener( "AutoDeployer listener", mbsc,
>>>> objectName );
>>>> myListener.startListening();
>>>>
>>>>
>>>> Always call myListener.cleanup() when done, because listeners
>>>> listen forever.
>>>>
>>>> ...........
>>>>
>>>> class MyAttributeChangeListener extends NotificationListenerBase {
>>>> MyAttributeChangeListener(
>>>> final String name,
>>>> final MBeanServerConnection conn,
>>>> final ObjectName objectName ) {
>>>> super( name, conn, objectName );
>>>> mRegUnregFilter = constrain;
>>>> }
>>>>
>>>> public void
>>>> handleNotification( final Notification notifIn, final Object
>>>> handback)
>>>> {
>>>> if
>>>> ( notifIn
>>>> .getType
>>>> ().equals( AttributeChangeNotification.ATTRIBUTE_CHANGE) ) {
>>>> final AttributeChangeNotification acn =
>>>> (AttributeChangeNotification)notifIn;
>>>>
>>>> // AMX always emits an ObjectName for 'source'
>>>> ObjectName src = (ObjectName)acn.getSource();
>>>> String attrName = acn.getAttributeName();
>>>> Object oldValue = acn.getOldValue();
>>>> Object newValue = acn.getNewValue();
>>>>
>>>> // You can turn the ObjectName into an AMX proxy if you like:
>>>> if ( ObjectName.getDomain().equals( AMX.JMX_DOMAIN ) )
>>>> {
>>>> final <? extends AMX> amx =
>>>> ProxyFactory.getInstance(getConn()).getProxy( src );
>>>> // proxy is the correct type (class), not just an 'AMX'.
>>>> }
>>>> }
>>>> }
>>>> }
>>>>
>>>>
>>>> Lloyd
>>>>
>>>> On Mar 17, 2008, at 7:17 AM, Timothy Quinn wrote:
>>>>
>>>>> Hi, Lloyd.
>>>>>
>>>>> Apologies if this has been documented or discussed somewhere
>>>>> already. Please point me if there is something already written
>>>>> up.
>>>>>
>>>>> I noticed that you mentioned in a recent update that config
>>>>> change notification is now working. The autodeployer uses some
>>>>> information from the config, and although I suspect it is rare
>>>>> that users change that information it could happen. I'd like the
>>>>> autodeployer to detect and respond when the autodeployer config
>>>>> is changed.
>>>>> Can you point me to some doc or a simple example that shows how
>>>>> to do this?
>>>>>
>>>>> Thanks a lot.
>>>>>
>>>>> - Tim
>>>>
>>>> ---
>>>> Lloyd L Chambers
>>>> lloyd.chambers_at_sun.com
>>>> Sun Microsystems, Inc
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>