Tim,
An MBeanServer can be used in lieu of an MBeanServerConnection.
We are embarking on a bifurcated system: you must decide if your code
is remotable or not.
If it is remotable, then you should use MBeans.
If it is not remotable, then you have to use other APIs eg listening
for PropertyChangeEvent. I'm not sure if that's available on
ConfigBeanProxy objects or not. Jerome could answer that question.
Editorial:
In general, this choice will be an ongoing source of confusion
throughout the system (whether to use MBeans or not). I don't agree
with some of our design decisions, including the "MBeans are optional"
one; it makes MBeans a 2nd class add-on which discourages their use.
Lloyd
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
>>
>>
>>
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc