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
>
>
>