RE: [Openjmx-devel] RE: OpenJMX and RI Examples - ModelMBean

[Bordet, S. <Sim...@co...>]

Hi,

> The only thing I'm still left wondering about, is the generation of
> Notifications with a source field containing the MBean's=20
> object name...

Acc, it was just an example on how to have implemented methods in the
management interface as well, now I opened up another big hole... :)

> > For example, (the spec is unclear on this) it is said that=20
> if listeners
> > are registered via MBeanServer, then the field source of the
> > Notification emitted is not the direct reference, but=20
> instead the object
> > name of the emitter.
> > Now, if you implement a std or dyn MBean that expose also
> > add/removeNotificationListener via management interface,=20
> you have 2 ways
> > of registering listeners:
> >
> > server.addNotificationListener(...)
> >
> > and
> >
> > server.invoke("addNotificationListener", ...)
> >
> > that will result in the notification having as source field=20
> the object
> > name and the direct reference respectively.
> >
> > Both the RI and OpenJMX returns now the direct reference.=20
> OpenJMX for
> > now, until the spec will clear this point.
>=20
> If this behaviour were to be supported, just how might it be=20
> implemented?

Well, I thought about it some time ago, and it seemed to me not that
difficult, why ?

> Would any implementation not depend on an implicit assumption=20
> that all=20
> broadcasting MBeans would obligingly choose to extend=20
> NotificationBroadcasterSupport? =20

Of course no.=20
If the user decides to implement from scratch NotificationBroadcaster
and to expose the direct reference there is nothing I can do about;
however things are different for example for Timer MBean, Monitor MBean
and in general for Agent services. And for
NotificationBroadcasterSupport.

> Without such an assumption, I don't see how the Notifications could=20
> be effectively filtered to ensure that the appropriate ones did=20
> indeed have the source field set to contain the desired object name,
> rather than the direct bean reference that will have been passed=20
> to the Notifications constructor.

As it is the spec now, you cannot enforce it.
But you can provide means to help in this, by using the
NotificationBroadcasterSupport class. You're not forced to use it; if
you do, you will save boring coding and be spec compliant; if you don't
it's upon you being compliant: a listener that register via MBeanServer
may expect correctly to get a Notification and cast the source to a
ObjectName.

> The server would also need to be able to map from an MBean to its =20
> object name?

This may be possible, but why ?

> Am I missing something here?

No, it's just an academic discussion until the spec clarifies if the
behavior must be enforced or not.

The real problem is to have a mean to distinguish how listeners are
registered. This involves a spec/API change, for example a new property
in NotificationListener interface to know this. Once you know, from any
NotificationBroadcaster implementation it is easy to provide correct
sources to Notifications.=20
For now more complex tricks are needed to know this, but it is already
possible to provide this behavior.

Hope this clarifies

Simon