Hi Jeff,

You cannot implement it like this:

        // make a copy of the notification, replacing with the real
source of the event
        Notification n = new
Notification(notification.getType(),source,notification.getSequenceNumber(),notification.getTimeStamp(),notification.getMessage());
        n.setUserData(notification.getUserData());
        return this.delegate.isNotificationEnabled(n);

The filter will likely rely upon the type of the Notification
which is lost in this implementation.

The big problem is that notifications are not required to be clonable,
so the only thing you can do is setSource() on the notification
with the ObjectName (changing the source for subsequent notification
listeners).

This is a known issue with the spec.

See NotificationListenerProxy.

Regards,
Adrian

On Tue, 2004-01-06 at 14:18, SourceForge.net wrote:
> Bugs item #871649, was opened at 2004-01-06 08:16
> Message generated for change (Comment added) made by jhaynie
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=376685&aid=871649&group_id=22866
> 
> Category: JBossMX
> Group: v3.2
> >Status: Closed
> >Resolution: Fixed
> Priority: 5
> Submitted By: Jeff Haynie (jhaynie)
> Assigned to: Jeff Haynie (jhaynie)
> Summary: Problem with source of JMX Notifications
> 
> Initial Comment:
> According to the JMX spec, the source of a Notification 
> must be of type ObjectName.
> 
> At line 420 in ServerImpl:
> 
> Notification msg = new Notification
> (START_NOTIFICATION_TYPE, this, 1);
> 
> should be changed to:
> 
> Notification msg = new Notification
> (START_NOTIFICATION_TYPE, 
> ServerImplMBean.OBJECT_NAME, 1);
> 
> 
> We should also update JMX to check this (although I 
> thought it did before - maybe its happening at the at a 
> higher level in the BasicMBeanRegistry).
> 
> The problem is that the ListenerRegistration in the 
> NotificationBroadcasterSupport.sendNotification() will 
> evaluate the NotificationFilter before being dispatched 
> up to the listener. The listener is being wrapped at a 
> higher level by the mbean server using the 
> NotificationListenerProxy which sets the source - but 
> this happens after the filter is applied  -- which causes 
> problems if you're checking the ObjectName in the filter.
> 
> An easy enough fix for this particular problem is just to 
> do above.  However, I'm worried we'll still see this in 
> other places.  Another thought is to wrap the 
> MBeanServerListenerRegistration (which creates 
> NotificationListenerProxy) and pass in a proxy to the 
> filter, such that it will set the appropriate source using 
> the MBeanServerListenerRegistration and then delegate 
> to the appropriate filter.
> 
> The other thing is to enforce in our Notification 
> implementation ObjectName in setSource and the 
> constructor -- which according to the JMX spec we're 
> suppose to throw an IllegalArgumentException.
> 
> ----------------------------------------------------------------------
> 
> >Comment By: Jeff Haynie (jhaynie)
> Date: 2004-01-06 09:18
> 
> Message:
> Logged In: YES 
> user_id=4529
> 
> This is implemented in 3.2 branch.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Adrian Brock (ejort)
> Date: 2004-01-06 08:50
> 
> Message:
> Logged In: YES 
> user_id=9459
> 
> Yes, go ahead.
> 
> Regards,
> Adrian
> 
> ----------------------------------------------------------------------
> 
> Comment By: Jeff Haynie (jhaynie)
> Date: 2004-01-06 08:44
> 
> Message:
> Logged In: YES 
> user_id=4529
> 
> OK, looking at the JMX 1.2 spec javadoc for Notification, it
> states:
> 
> "The Notification class represents a notification emitted by an
>  MBean.  It contains a reference to the source MBean: if the
> notification has been forwarded through the MBean server,
> this is the object name of the MBean. If the listener has
> registered directly with the MBean, this is either the
> object name or a direct reference to the MBean.
> 
> It is strongly recommended that notification senders use the
> object name rather than a reference to the MBean object as
> the source."
> 
> 
> In my case, and in the case for jboss mx, we're not
> registering directly with the mbean.  I like the idea of
> filter proxy since it would enforce the ObjectName
> externally and still allow either ObjectName or direct
> reference in the implementation of an MBean.
> 
> Is this something you would like me to apply?
> 
> 
> 
> ----------------------------------------------------------------------
> 
> Comment By: Adrian Brock (ejort)
> Date: 2004-01-06 08:34
> 
> Message:
> Logged In: YES 
> user_id=9459
> 
> The only requirement from the spec is that notification
> listeners
> registered through the MBeanServer receive notifications
> with the ObjectName they registered against.
> 
> Direct notifications (i.e. where you register directly with
> the MBean)
> are not required to use the ObjectName,
> but direct notifications are frowned upon.
> 
> You cannot setSource() a normal object but there is no
> such requirement on the constructor.
> Unless the broadcaster also implements MBeanRegistration
> it does not know its own ObjectName.
> 
> One way to fix the problem would be to add a
> NotificationFilterProxy
> that replaces the source with the ObjectName in the same
> way that is done for the NotificationListener.
> 
> Regards,
> Adrian
> 
> ----------------------------------------------------------------------
> 
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=376685&aid=871649&group_id=22866
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> JBoss-Development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
-- 
xxxxxxxxxxxxxxxxxxxxxxxx 
Adrian Brock
Director of Support
Back Office
JBoss Group, LLC 
xxxxxxxxxxxxxxxxxxxxxxxx 



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to