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
>