Use of NotificationListenerProxy

[tom.elrod]

I noticed that the implementation of MBeanServer creates a NotificationListenerProxy class that contains the NotificationListener passed when adding a listener to a MBean. I wanted to be able to extend the NotificationListener interface and then cast (or at least check the instanceof) of the original NotificationListener inside the MBean's NotificationBroadcaster. Can you explain why the NotificationListenerProxy is used instead of using the actual NotificationListener passed and if there might be any other suggestions on how to figure out the real type of the original NotificationListener (or if it would be ok to update the code for the NotificationListenerProxy to be a real proxy instead of just a wrapper).

Thanks.

[adrian.brock]

The spec requires that any NotificationListener
registered with the MBeanServer receives the MBean's
ObjectName as the "source" in the notification.
In fact, it discourages direct registration with
the broadcaster.

The actual NotificationBroadcaster doesn't necessarily
set the object name as the source, so we intercept the
notification and replace it.

You could add a getUnderlyingListener() method?

How would a real proxy help when using instanceof?
The MBeanServer would probably only care about the
NotificationListener interface when generating the
proxy?

Regards,
Adrian

[juha]

> The actual NotificationBroadcaster doesn't
> necessarily
> set the object name as the source

In fact, it rarely does, the resource doesn't usually need to know its own object name, so it just uses 'this' reference as its source for notifications

(which we then need to intercept and replace with the actual object name as Adrian explained)

You can only rely on the declared interface in the resource implementation (this is good design anyway).

However you can pass any custom object as part of handback when you register the listener. This is guaranteed by the spec to be immutable object as far as the server is concerned.

[tom.elrod]

I updated the code to the NotificationListenerProxy so that it will maintain the interface heirarchy of the original NotificationListener object passed when setting it within the NotificationBroadcaster. The only hitch is that it uses a dynamic proxy (java.lang.reflect.Proxy & java.lang.reflect.InvocationHandler), which is JDK 1.3+ specific and wasn't sure what the jdk compatibility requirements are for jboss-mx?

[tom.elrod]

I updated the code to the NotificationListenerProxy so that it will maintain the interface heirarchy of the original NotificationListener object passed when setting it within the NotificationBroadcaster. The only hitch is that it uses a dynamic proxy (java.lang.reflect.Proxy & java.lang.reflect.InvocationHandler), which is JDK 1.3+ specific and wasn't sure what the jdk compatibility requirements are for jboss-mx?

[tom.elrod]

I updated the code to the NotificationListenerProxy so that it will maintain the interface heirarchy of the original NotificationListener object passed when setting it within the NotificationBroadcaster. The only hitch is that it uses a dynamic proxy (java.lang.reflect.Proxy & java.lang.reflect.InvocationHandler), which is JDK 1.3+ specific and wasn't sure what the jdk compatibility requirements are for jboss-mx?

[tom.elrod]

I updated the code to the NotificationListenerProxy so that it will maintain the interface heirarchy of the original NotificationListener object passed when setting it within the NotificationBroadcaster. The only hitch is that it uses a dynamic proxy (java.lang.reflect.Proxy & java.lang.reflect.InvocationHandler), which is JDK 1.3+ specific and wasn't sure what the jdk compatibility requirements are for jboss-mx?

[tom.elrod]

I updated the code to the NotificationListenerProxy so that it will maintain the interface heirarchy of the original NotificationListener object passed when setting it within the NotificationBroadcaster. The only hitch is that it uses a dynamic proxy (java.lang.reflect.Proxy & java.lang.reflect.InvocationHandler), which is JDK 1.3+ specific and wasn't sure what the jdk compatibility requirements are for jboss-mx?

[tom.elrod]

I updated the code to the NotificationListenerProxy so that it will maintain the interface heirarchy of the original NotificationListener object passed when setting it within the NotificationBroadcaster. The only hitch is that it uses a dynamic proxy (java.lang.reflect.Proxy & java.lang.reflect.InvocationHandler), which is JDK 1.3+ specific and wasn't sure what the jdk compatibility requirements are for jboss-mx?

[tom.elrod]

Sorry about so many replies. Posted, but did not see the posting, so repeated. Once again, sorry.

[adrian.brock]

Jives caching sucks :-)

JBoss requires java 1.3 for ejb2.0

Show the code?

Regards,
Adrian

[tom.elrod]

Cool. Sent code via e-mail instead of posting. Please let me know if you did not get it.