Menu
▾
▴
openjmx-devel
|
From: Bordet, S. <Sim...@co...> - 2002-01-24 00:16:32
|
Roger, > The behaviour is just the same either way - same stack trace=20 > - the problem is=20 > simply that RequiredModelMBean.invoke() make no attempt to=20 > match any of the=20 > methods defined in its own class tree! =20 [snip] you're right, please file a bug in sourceforge, I'll take care of it. = Thanks for the good catch. > From the javadoc: >=20 > RequiredModelMBean.invoke(java.lang.String opName, ...) >=20 > opName - The name of the method to be invoked. The name can=20 > be the fully qualified=20 > method name including the classname, or just the method name=20 > if the classname is=20 > defined in the 'class' field of the operation descriptor. Must investigate this, it seems to me counter-intuitive... Simon |
|
From: Bordet, S. <Sim...@co...> - 2002-01-28 15:08:34
|
Hi,
so, the question has been closed in jmx-forum. Guess what ?
It is a RI bug.
The spec says you cannot invoke setManagedResource via management =
interface, nor any other method belonging to the ModelMBean interface.
The examples in the RI are bad coded.
Simon
> -----Original Message-----
> From: Roger Holbrook [mailto:ro...@fl...]
> Sent: gioved=EC 24 gennaio 2002 0:32
> To: ope...@li...
> Subject: [Openjmx-devel] RE: OpenJMX and RI Examples - ModelMBean
>=20
>=20
>=20
> Hi Simon
>=20
> >> I am now trying to run the RI ModelMBean example on OpenJMX
> >>=20
> >> There are several problems that are obviously linked to=20
> the coding of=20
> >> the example itself - but then there appears to be a more=20
> significant
> >> issue when trying to invoke a method of class DynamicMBean or=20
> >> ModelMBean,
> >> on an instance of RequiredModelMBean, that has been successfully=20
> >> registered with the mbean server.
> >>=20
> >> For example, when mbeanObjectName referred to a successfully=20
> >> registered instance,
> >> the following call:
> >>=20
> >> server.invoke(mbeanObjectName,=20
> >> =20
> "javax.management.modelmbean.RequiredModelMBean.setManagedResource",
> >> new Object[] { new TestBean(),=20
> "ObjectReference"},
> >> new String[]{"java.lang.Object",=20
> >> "java.lang.String"});
> >
> > It's wrong, try this:
> >
> > server.invoke(mbeanObjectName,
> > "setManagedResource",
> > new Object[] {new TestBean(), "ObjectReference"},
> > new String[] {"java.lang.Object",=20
> > "java.lang.String"});
> >
> > Note the operation name.
> >
> > Hope helped
> >
> > Simon
>=20
> The behaviour is just the same either way - same stack trace=20
> - the problem is=20
> simply that RequiredModelMBean.invoke() make no attempt to=20
> match any of the=20
> methods defined in its own class tree! CF the code from the=20
> RI that tries
> to do the following:
>=20
> try
> {
> mmbOpHandle =3D=20
> (this.getClass()).getMethod(opMethodName, mmbSig);
> } catch (NoSuchMethodException nsml)
> {
> mmbLocalInvoke =3D false;
> }
>=20
> before checking the ModelMBeanInfo for the named operation.
>=20
> Sorry to cause confusion by including the fully qualified=20
> method name - I was=20
> actually just trying to draw attention to the fact that the=20
> javadoc specifically=20
> allows for this as well - in case this may not have been=20
> recognised/catered for.
>=20
> From the javadoc:
>=20
> RequiredModelMBean.invoke(java.lang.String opName, ...)
>=20
> opName - The name of the method to be invoked. The name can=20
> be the fully qualified=20
> method name including the classname, or just the method name=20
> if the classname is=20
> defined in the 'class' field of the operation descriptor.
>=20
> Roger
>=20
>=20
> _______________________________________________
> Openjmx-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openjmx-devel
>=20
|
|
From: Carlos Q. <car...@ge...> - 2002-01-28 15:18:10
|
>Hi,
>
>so, the question has been closed in jmx-forum. Guess what ?
>
>It is a RI bug.
>
>The spec says you cannot invoke setManagedResource via management interf=
ace,
> nor any other method belonging to the ModelMBean interface. The example=
s in
> the RI are bad coded.
Ejem... ;-)
Then, what's the correct way? via server.setAttribute("ManagedResource",=20
object)
>
>Simon
> -----Original Message-----
> From: Roger Holbrook [mailto:ro...@fl...]
> Sent: gioved=EC 24 gennaio 2002 0:32
> To: ope...@li...
> Subject: [Openjmx-devel] RE: OpenJMX and RI Examples - ModelMBean
>
>
>
> Hi Simon
>
> >> I am now trying to run the RI ModelMBean example on OpenJMX
> >>
> >> There are several problems that are obviously linked to
>
> the coding of
>
> >> the example itself - but then there appears to be a more
>
> significant
>
> >> issue when trying to invoke a method of class DynamicMBean or
> >> ModelMBean,
> >> on an instance of RequiredModelMBean, that has been successfully
> >> registered with the mbean server.
> >>
> >> For example, when mbeanObjectName referred to a successfully
> >> registered instance,
> >> the following call:
> >>
> >> server.invoke(mbeanObjectName,
>
> "javax.management.modelmbean.RequiredModelMBean.setManagedResource",
>
> >> new Object[] { new TestBean(),
>
> "ObjectReference"},
>
> >> new String[]{"java.lang.Object",
> >> "java.lang.String"});
> >
> > It's wrong, try this:
> >
> > server.invoke(mbeanObjectName,
> > "setManagedResource",
> > new Object[] {new TestBean(), "ObjectReference"},
> > new String[] {"java.lang.Object",
> > "java.lang.String"});
> >
> > Note the operation name.
> >
> > Hope helped
> >
> > Simon
>
> The behaviour is just the same either way - same stack trace
> - the problem is
> simply that RequiredModelMBean.invoke() make no attempt to
> match any of the
> methods defined in its own class tree! CF the code from the
> RI that tries
> to do the following:
>
> try
> {
> mmbOpHandle =3D
> (this.getClass()).getMethod(opMethodName, mmbSig);
> } catch (NoSuchMethodException nsml)
> {
> mmbLocalInvoke =3D false;
> }
>
> before checking the ModelMBeanInfo for the named operation.
>
> Sorry to cause confusion by including the fully qualified
> method name - I was
> actually just trying to draw attention to the fact that the
> javadoc specifically
> allows for this as well - in case this may not have been
> recognised/catered for.
>
> From the javadoc:
>
> RequiredModelMBean.invoke(java.lang.String opName, ...)
>
> opName - The name of the method to be invoked. The name can
> be the fully qualified
> method name including the classname, or just the method name
> if the classname is
> defined in the 'class' field of the operation descriptor.
>
> Roger
>
>
> _______________________________________________
> Openjmx-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openjmx-devel
_______________________________________________
Openjmx-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openjmx-devel
|
|
From: Bordet, S. <Sim...@co...> - 2002-01-28 15:27:03
|
Hi,
> Then, what's the correct way? via=20
> server.setAttribute("ManagedResource",=20
> object)
No, there is no way to do it via MBeanServer.
You must call it directly on the ModelMBean reference.
Simon
|
|
From: Carlos Q. <car...@ge...> - 2002-01-28 15:40:59
|
>
>Hi,
>
>> Then, what's the correct way? via
>> server.setAttribute("ManagedResource",
>> object)
>No, there is no way to do it via MBeanServer.
>You must call it directly on the ModelMBean reference.
But you should create the ModelMBean via MBeanServer, how can you access =
the=20
instance then?
Carlos
>Simon
_______________________________________________
Openjmx-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openjmx-devel
|
|
From: Bordet, S. <Sim...@co...> - 2002-01-28 16:10:45
|
Hi,
> >Hi,
> >
> >> Then, what's the correct way? via
> >> server.setAttribute("ManagedResource",
> >> object)
>=20
> >No, there is no way to do it via MBeanServer.
>=20
> >You must call it directly on the ModelMBean reference.
>=20
> But you should create the ModelMBean via MBeanServer, how can=20
> you access the instance then?
ModelMBean rmmb =3D =
server.instantiate("javax.management.modelmbean.RequiredModelMBean", =
...);
rmmb.setModelMBeanInfo(...);
rmmb.setManagedResource(..., "ObjectReference");
server.registerMBean(rmmb, ...);
No other way.
The first line may be:
ModelMBean rmmb =3D new RequiredModelMBean();
but the rest is mandated.
See also the tests for examples.
Simon
|
|
From: Carlos Q. <car...@ge...> - 2002-01-28 16:21:27
|
>Hi,
>
>> >Hi,
>> >
>> >> Then, what's the correct way? via
>> >> server.setAttribute("ManagedResource",
>> >> object)
>> >
>> >No, there is no way to do it via MBeanServer.
>> >
>> >You must call it directly on the ModelMBean reference.
>>
>> But you should create the ModelMBean via MBeanServer, how can
>> you access the instance then?
>
>ModelMBean rmmb =3D
> server.instantiate("javax.management.modelmbean.RequiredModelMBean", ..=
=2E);
> rmmb.setModelMBeanInfo(...);
>rmmb.setManagedResource(..., "ObjectReference");
>server.registerMBean(rmmb, ...);
>
>No other way.
>
>The first line may be:
>
>ModelMBean rmmb =3D new RequiredModelMBean();
>
>but the rest is mandated.
>See also the tests for examples.
Ok, thanks for the clarification. it still feels a bit counterintuitive t=
hough
Simon
_______________________________________________
Openjmx-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openjmx-devel
|
|
From: Roger H. <ro...@fl...> - 2002-01-28 18:49:27
|
Hi Simon > Hi, > > so, the question has been closed in jmx-forum. Guess what ? > > It is a RI bug. > > The spec says you cannot invoke setManagedResource via management interface, > nor any other method belonging to the ModelMBean interface. > The examples in the RI are bad coded. > > Simon Many thanks for pursuing this - lets just see if I understand correctly? Unless the functionality of a Dynamic/ModelMBean is published via its MBeanInfo, it will not be accessible as part of the management interface via the mbean server? The functionality that is exposed via the MBeanInfo will not be accessible until the MBean has been successfully registered with the server. It would therefore, not be a good idea to try & expose any of the following ModelMBean methods via the MBeanInfo: - setModelMBeanInfo - setManagedResource - load - store Is that about it? Roger |
|
From: Bordet, S. <Sim...@co...> - 2002-01-28 20:48:26
|
Hi Roger,
> Many thanks for pursuing this - lets just see if I understand=20
> correctly?
>=20
> Unless the functionality of a Dynamic/ModelMBean is published via its
> MBeanInfo, it will not be accessible as part of the=20
> management interface=20
> via the mbean server?
Correct.
> The functionality that is exposed via the MBeanInfo will not=20
> be accessible until
> the MBean has been successfully registered with the server.
Correct.
> It would therefore, not be a good idea to try & expose any of=20
> the following=20
> ModelMBean methods via the MBeanInfo:
> - setModelMBeanInfo
> - setManagedResource
> - load
> - store
>=20
> Is that about it?
Correct.
Add also methods from NotificationBroadcaster interfaces.
The above holds for ModelMBeans, however, whose implementation is
already given.
For plain dynamic MBeans, however, the implementor is responsible of
both the metadata and the dispatching.
So you can implement a dynamic MBean that implements also
PersistentMBean, and expose load and store via the management interface,
since you also implement invoke. Same for NotificationBroadcaster
interface.
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.
The above to say that there is a possibility to have methods of
implemented interfaces be part of the management interface. Necessary
condition is being in control of management interface and dispatching.
With std and dyn MBean you have this control; with ModelMBeans,
dispatching is not under control of the user.
Regards
Simon
|
|
From: Bordet, S. <Sim...@co...> - 2002-01-28 20:52:24
|
> The above to say that there is a possibility to have methods of > implemented interfaces be part of the management interface. Necessary > condition is being in control of management interface and dispatching. > With std and dyn MBean you have this control; with ModelMBeans, > dispatching is not under control of the user. Better yet, with RequiredModelMBeans it is not.=20 One is free to implement ModelMBean interface and have also this possibility: at the end, it's a dynamic MBean. Simon |
|
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
|
|
From: Bordet, S. <Sim...@co...> - 2002-01-29 09:33:49
|
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
|
|
From: Roger H. <ro...@fl...> - 2002-01-29 11:13:46
|
Hi Simon >> The only thing I'm still left wondering about, is the generation of >> Notifications with a source field containing the MBean's >> 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... :) No just idle curiosity really - you know when you come across something new and the first thing you do is start wondering how it works... [snip] > 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. Ok - no magic required ;) Thanks for your patience Roger |
Thanks for helping keep SourceForge clean.
X