Jerome,
I am getting really nervous about this approach of bypassing AMX for
virtually everything. I want such decisions to be made as a team, not
based on your personal preferences or prior conceptions, which is how
they feel to me.
For example, if the autodeployer performs some tasks, how can remote
clients learn about such changes other than through AMX? Such things
could be highly relevant to IDEs and management clients. Granted
things could be dealt with internally without AMX, but system state
needs to be exposed remotely.
Lloyd
On Mar 17, 2008, at 11:14 AM, 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. Are you injected with your
> configuration at the first place ?
>
> 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
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc