|
From: Roger H. <ro...@fl...> - 2002-01-28 23:33:59
|
Hi Simon
I think I've got the general hang of this scheme :)
The only thing I'm still left wondering about, is the generation of
Notifications with a source field containing the MBean's object name...
> For example, (the spec is unclear on this) it is said that if listeners
> are registered via MBeanServer, then the field source of the
> Notification emitted is not the direct reference, but instead the object
> name of the emitter.
> Now, if you implement a std or dyn MBean that expose also
> add/removeNotificationListener via management interface, you have 2 ways
> of registering listeners:
>
> server.addNotificationListener(...)
>
> and
>
> server.invoke("addNotificationListener", ...)
>
> that will result in the notification having as source field the object
> name and the direct reference respectively.
>
> Both the RI and OpenJMX returns now the direct reference. OpenJMX for
> now, until the spec will clear this point.
If this behaviour were to be supported, just how might it be implemented?
Would any implementation not depend on an implicit assumption that all
broadcasting MBeans would obligingly choose to extend
NotificationBroadcasterSupport?
Without such an assumption, I don't see how the Notifications could
be effectively filtered to ensure that the appropriate ones did
indeed have the source field set to contain the desired object name,
rather than the direct bean reference that will have been passed
to the Notifications constructor.
The server would also need to be able to map from an MBean to its
object name?
Am I missing something here?
Roger
|