[Openjmx-devel] OpenJMX and RI Examples - ModelMBean

[Roger Holbrook]

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"});

generated the following stack trace:

javax.management.MBeanException: nested exception is
javax.management.ServiceNotFoundException:
Cannot find ModelMBeanOperationInfo for operation
javax.management.modelmbean.RequiredModelMBean.setManagedResource
at javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:550)
at openjmx.MBeanIntrospector.invoke(MBeanIntrospector.java:204)
at openjmx.MBeanServerImpl.invoke(MBeanServerImpl.java:158)
at ModelAgent.createMBean(ModelAgent.java:236)
at ModelAgent.doSimpleDemo(ModelAgent.java:146)
at ModelAgent.main(ModelAgent.java:96)

Trying to invoke any of the other DynamicMBean or ModelMBean methods seems to produce
similar results...

Roger

[Bordet, Simone]

Hi Roger,

Post by Roger Holbrook
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,
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

[Roger Holbrook]

Hi Simon

Post by Roger Holbrook

Post by Roger Holbrook
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,
server.invoke(mbeanObjectName,
"javax.management.modelmbean.RequiredModelMBean.setManagedResource",
new Object[] { new TestBean(), "ObjectReference"},
new String[]{"java.lang.Object",
"java.lang.String"});

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 = (this.getClass()).getMethod(opMethodName, mmbSig);
} catch (NoSuchMethodException nsml)
{
mmbLocalInvoke = 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.

[Bordet, Simone]

Roger,

Post by Roger Holbrook
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!

[snip]

you're right, please file a bug in sourceforge, I'll take care of it. Thanks for the good catch.

[Bordet, Simone]

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-----
Sent: giovedì 24 gennaio 2002 0:32
Subject: [Openjmx-devel] RE: OpenJMX and RI Examples - ModelMBean
Hi Simon

Post by Roger Holbrook

Post by Roger Holbrook
I am now trying to run the RI ModelMBean example on OpenJMX
There are several problems that are obviously linked to

the coding of

Post by Roger Holbrook

Post by Roger Holbrook
the example itself - but then there appears to be a more

significant

Post by Roger Holbrook

Post by Roger Holbrook
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,
server.invoke(mbeanObjectName,

"javax.management.modelmbean.RequiredModelMBean.setManagedResource",

Post by Roger Holbrook

Post by Roger Holbrook
new Object[] { new TestBean(),

"ObjectReference"},

Post by Roger Holbrook

Post by Roger Holbrook
new String[]{"java.lang.Object",
"java.lang.String"});

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
try
{
mmbOpHandle =
(this.getClass()).getMethod(opMethodName, mmbSig);
} catch (NoSuchMethodException nsml)
{
mmbLocalInvoke = 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.

[Carlos Quiroz]

Post by Bordet, Simone
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.

Ejem... ;-)

Then, what's the correct way? via server.setAttribute("ManagedResource",
object)

Post by Bordet, Simone
Simon
-----Original Message-----
Sent: giovedì 24 gennaio 2002 0:32
Subject: [Openjmx-devel] RE: OpenJMX and RI Examples - ModelMBean
Hi Simon

Post by Roger Holbrook

Post by Roger Holbrook
I am now trying to run the RI ModelMBean example on OpenJMX
There are several problems that are obviously linked to

the coding of

Post by Roger Holbrook

Post by Roger Holbrook
the example itself - but then there appears to be a more

significant

Post by Roger Holbrook

Post by Roger Holbrook
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,
server.invoke(mbeanObjectName,

"javax.management.modelmbean.RequiredModelMBean.setManagedResource",

Post by Roger Holbrook

Post by Roger Holbrook
new Object[] { new TestBean(),

"ObjectReference"},

Post by Roger Holbrook

Post by Roger Holbrook
new String[]{"java.lang.Object",
"java.lang.String"});

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
try
{
mmbOpHandle =
(this.getClass()).getMethod(opMethodName, mmbSig);
} catch (NoSuchMethodException nsml)
{
mmbLocalInvoke = 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.

[Bordet, Simone]

Hi,

Post by Carlos Quiroz
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.

Simon

[Carlos Quiroz]

Post by Bordet, Simone
Hi,

Post by Carlos Quiroz
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?

Carlos

Post by Bordet, Simone
Simon

[Bordet, Simone]

Hi,

Post by Carlos Quiroz

Post by Bordet, Simone
Hi,

Post by Carlos Quiroz
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 = server.instantiate("javax.management.modelmbean.RequiredModelMBean", ...);
rmmb.setModelMBeanInfo(...);
rmmb.setManagedResource(..., "ObjectReference");
server.registerMBean(rmmb, ...);

No other way.

The first line may be:

ModelMBean rmmb = new RequiredModelMBean();

but the rest is mandated.

See also the tests for examples.

Simon

[Carlos Quiroz]

Post by Bordet, Simone
Hi,

Post by Carlos Quiroz

Post by Bordet, Simone
Hi,

Post by Carlos Quiroz
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 =
server.instantiate("javax.management.modelmbean.RequiredModelMBean", ...);
rmmb.setModelMBeanInfo(...);
rmmb.setManagedResource(..., "ObjectReference");
server.registerMBean(rmmb, ...);
No other way.
ModelMBean rmmb = new RequiredModelMBean();
but the rest is mandated.
See also the tests for examples.

Ok, thanks for the clarification. it still feels a bit counterintuitive though


Simon

[Roger Holbrook]

Hi Simon

Post by Bordet, Simone
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

[Bordet, Simone]

Hi Roger,

Post by Roger Holbrook
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?

Correct.

Post by Roger Holbrook
The functionality that is exposed via the MBeanInfo will not
be accessible until
the MBean has been successfully registered with the server.

Correct.

Post by Roger Holbrook
It would therefore, not be a good idea to try & expose any of
the following
- setModelMBeanInfo
- setManagedResource
- load
- store
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

[Bordet, Simone]

Post by Bordet, Simone
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.
One is free to implement ModelMBean interface and have also this
possibility: at the end, it's a dynamic MBean.

Simon

[Roger Holbrook]

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...

Post by Bordet, Simone
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
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

[Bordet, Simone]

Hi,

Post by Roger Holbrook
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... :)

Post by Roger Holbrook

Post by Bordet, Simone
For example, (the spec is unclear on this) it is said that

if listeners

Post by Bordet, Simone
are registered via MBeanServer, then the field source of the
Notification emitted is not the direct reference, but

instead the object

Post by Bordet, Simone
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

Post by Bordet, Simone
server.addNotificationListener(...)
and
server.invoke("addNotificationListener", ...)
that will result in the notification having as source field

the object

Post by Bordet, Simone
name and the direct reference respectively.
Both the RI and OpenJMX returns now the direct reference.

OpenJMX for

Post by Bordet, Simone
now, until the spec will clear this point.

If this behaviour were to be supported, just how might it be
implemented?

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

Post by Roger Holbrook
Would any implementation not depend on an implicit assumption
that all
broadcasting MBeans would obligingly choose to extend
NotificationBroadcasterSupport?

Of course no.
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.

Post by Roger Holbrook
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.

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.

Post by Roger Holbrook
The server would also need to be able to map from an MBean to its
object name?

This may be possible, but why ?

Post by Roger Holbrook
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.
For now more complex tricks are needed to know this, but it is already
possible to provide this behavior.

Hope this clarifies

Simon

[Roger Holbrook]

Hi Simon

Post by Bordet, Simone

Post by Roger Holbrook
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]

Post by Bordet, Simone
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