Menu
▾
▴
openjmx-devel — OpenJMX Developers list
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(277) |
Dec
(103) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(320) |
Feb
(100) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Carlos Q. <car...@we...> - 2002-01-30 08:05:33
|
On Tuesday 29 January 2002 20:00, J=E9r=F4me BERNARD wrote: > Hi, Hi I commited my solution. Please take a look and give me your comments Regards > > I have been experiencing problems with ObjectNames containing spaces. > The way the XSTL stylesheets are built is a problem because the URL > produced are not valid. > > I have found (and implemented) a "trick" in order to solve that: we can > add a method in common.xsl (I called it urlencode) that encodes properl= y > the URL and do a window.location to this newly created url. > > We replace all href values with urlencode(the old href value) and we're > done. > > Is anyone ok for such a fix? > > If so I will start updating all the stylesheet and commit. > > > Jerome. > > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: Carlos Q. <car...@we...> - 2002-01-29 20:39:47
|
On Tuesday 29 January 2002 20:00, J=E9r=F4me BERNARD wrote: > Hi, > > I have been experiencing problems with ObjectNames containing spaces. > The way the XSTL stylesheets are built is a problem because the URL > produced are not valid. > > I have found (and implemented) a "trick" in order to solve that: we can > add a method in common.xsl (I called it urlencode) that encodes properl= y > the URL and do a window.location to this newly created url. Hi I added one template which uses a xalan extension. It basically passes= the=20 URL via URLEncode.encode(). This is better than using XSLT default output= =20 becuse it warantees that some characters will be right encoded in particu= lar=20 '&' It is working with Konqueror and Mozilla (Linux) but it should be tested = with=20 IE and Netscape in M$ Windows which I don't use The big problem is that we are now stuck with xalan. Opinions? If this is= ok=20 I can commit it ASAP > > We replace all href values with urlencode(the old href value) and we're > done. > > Is anyone ok for such a fix? > > If so I will start updating all the stylesheet and commit. > > > Jerome. > > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: Carlos Q. <car...@we...> - 2002-01-29 19:26:26
|
On Tuesday 29 January 2002 20:00, J=E9r=F4me BERNARD wrote: > Hi, > > I have been experiencing problems with ObjectNames containing spaces. > The way the XSTL stylesheets are built is a problem because the URL > produced are not valid. How does this happen exactly? The XSLT requires that if output is set to = html=20 href elements are escaped and that's what happens in my testing here. I'm= =20 having a MBean called 'Http Adaptor:name=3DHttp Adaptor' and the link wor= ks ok. What XSLT processor are you using? > > I have found (and implemented) a "trick" in order to solve that: we can > add a method in common.xsl (I called it urlencode) that encodes properl= y > the URL and do a window.location to this newly created url. > > We replace all href values with urlencode(the old href value) and we're > done. > > Is anyone ok for such a fix? > > If so I will start updating all the stylesheet and commit. > > > Jerome. > > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: Carlos Q. <car...@we...> - 2002-01-29 19:00:44
|
On Tuesday 29 January 2002 20:52, J=E9r=F4me BERNARD wrote: > Another one would be to use some XSL:PI (processing instructions) but I > guess we would be "linked" to the XSL transformer which is problably no= t > even better. > Any other suggestion? We could use a xalan extension. That will tie us to xalan but we are alre= ady=20 tied since both saxon and JDK 1.4 keep throwing exception, and I was thin= king=20 to use them anyway for handling custom data types. I'll investigate this and if nothing else works you can commit the JavaSc= ript=20 solution > > Jerome. > > > ----- Original Message ----- > From: "Carlos Quiroz" <car...@we...> > To: <ope...@li...> > Sent: Tuesday, January 29, 2002 7:44 PM > Subject: Re: [Openjmx-devel] Proposed bug fix in the XSLT stylesheets > > > On Tuesday 29 January 2002 20:40, J=E9r=F4me BERNARD wrote: > > > I forgot to precise that the method is implemented in JavaScript (s= o > > > running on client-side). > > > > I'm not a very big fan of JavaScript, specially when I think of usage > > with non supporting browser. This happens to me when I can only ssh t= o a > > server and I can only use Lynx. > > > > I'd prefer some other solution > > > > > Jerome. > > > > > > ----- Original Message ----- > > > From: "J=E9r=F4me BERNARD" <jer...@xt...> > > > To: <ope...@li...> > > > Sent: Tuesday, January 29, 2002 7:00 PM > > > Subject: [Openjmx-devel] Proposed bug fix in the XSLT stylesheets > > > > > > > Hi, > > > > > > > > I have been experiencing problems with ObjectNames containing spa= ces. > > > > The way the XSTL stylesheets are built is a problem because the U= RL > > > > produced are not valid. > > > > > > > > I have found (and implemented) a "trick" in order to solve that: = we > > can > > > > > add a method in common.xsl (I called it urlencode) that encodes > > properly > > > > > the URL and do a window.location to this newly created url. > > > > > > > > We replace all href values with urlencode(the old href value) and > > we're > > > > > done. > > > > > > > > Is anyone ok for such a fix? > > > > > > > > If so I will start updating all the stylesheet and commit. > > > > > > > > > > > > Jerome. > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > _______________________________________________ > > 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: <jer...@xt...> - 2002-01-29 18:53:01
|
Another one would be to use some XSL:PI (processing instructions) but I guess we would be "linked" to the XSL transformer which is problably not even better. Any other suggestion? Jerome. ----- Original Message ----- From: "Carlos Quiroz" <car...@we...> To: <ope...@li...> Sent: Tuesday, January 29, 2002 7:44 PM Subject: Re: [Openjmx-devel] Proposed bug fix in the XSLT stylesheets > On Tuesday 29 January 2002 20:40, Jérôme BERNARD wrote: > > I forgot to precise that the method is implemented in JavaScript (so > > running on client-side). > I'm not a very big fan of JavaScript, specially when I think of usage with > non supporting browser. This happens to me when I can only ssh to a server > and I can only use Lynx. > > I'd prefer some other solution > > > > > Jerome. > > > > ----- Original Message ----- > > From: "Jérôme BERNARD" <jer...@xt...> > > To: <ope...@li...> > > Sent: Tuesday, January 29, 2002 7:00 PM > > Subject: [Openjmx-devel] Proposed bug fix in the XSLT stylesheets > > > > > Hi, > > > > > > I have been experiencing problems with ObjectNames containing spaces. > > > The way the XSTL stylesheets are built is a problem because the URL > > > produced are not valid. > > > > > > I have found (and implemented) a "trick" in order to solve that: we can > > > add a method in common.xsl (I called it urlencode) that encodes properly > > > the URL and do a window.location to this newly created url. > > > > > > We replace all href values with urlencode(the old href value) and we're > > > done. > > > > > > Is anyone ok for such a fix? > > > > > > If so I will start updating all the stylesheet and commit. > > > > > > > > > Jerome. > > > > > > > > > _______________________________________________ > > > 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 > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel > |
|
From: <jer...@xt...> - 2002-01-29 18:49:43
|
----- Original Message ----- From: "Carlos Quiroz" <car...@we...> To: <ope...@li...> Sent: Tuesday, January 29, 2002 7:09 PM Subject: Re: [Openjmx-devel] Proposed bug fix in the XSLT stylesheets [...] > > I have found (and implemented) a "trick" in order to solve that: we can > > add a method in common.xsl (I called it urlencode) that encodes properly > > the URL and do a window.location to this newly created url. > Where exactly do you want to put that? For instance to jump from the server > view to the mbean view? It will be perhaps necessary in many places Yes, this is where my first problem is but I guess that this must happen somewhere else too. > > We replace all href values with urlencode(the old href value) and we're > > done. > Is this XSL? Or are you using some extension? Nope JavaScript :-) > > Is anyone ok for such a fix? > > > > If so I will start updating all the stylesheet and commit. > I think is ok, but could you send me a copy beforehand I will send you tomorrow the updated common.xsl stylesheet and an update serverbydomain.xsl. Jerome. |
|
From: Carlos Q. <car...@we...> - 2002-01-29 18:47:53
|
On Tuesday 29 January 2002 20:40, J=E9r=F4me BERNARD wrote: > I forgot to precise that the method is implemented in JavaScript (so > running on client-side). I'm not a very big fan of JavaScript, specially when I think of usage wit= h=20 non supporting browser. This happens to me when I can only ssh to a serve= r=20 and I can only use Lynx. I'd prefer some other solution > > Jerome. > > ----- Original Message ----- > From: "J=E9r=F4me BERNARD" <jer...@xt...> > To: <ope...@li...> > Sent: Tuesday, January 29, 2002 7:00 PM > Subject: [Openjmx-devel] Proposed bug fix in the XSLT stylesheets > > > Hi, > > > > I have been experiencing problems with ObjectNames containing spaces. > > The way the XSTL stylesheets are built is a problem because the URL > > produced are not valid. > > > > I have found (and implemented) a "trick" in order to solve that: we c= an > > add a method in common.xsl (I called it urlencode) that encodes prope= rly > > the URL and do a window.location to this newly created url. > > > > We replace all href values with urlencode(the old href value) and we'= re > > done. > > > > Is anyone ok for such a fix? > > > > If so I will start updating all the stylesheet and commit. > > > > > > Jerome. > > > > > > _______________________________________________ > > 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: <jer...@xt...> - 2002-01-29 18:40:33
|
I forgot to precise that the method is implemented in JavaScript (so running on client-side). Jerome. ----- Original Message ----- From: "Jérôme BERNARD" <jer...@xt...> To: <ope...@li...> Sent: Tuesday, January 29, 2002 7:00 PM Subject: [Openjmx-devel] Proposed bug fix in the XSLT stylesheets > Hi, > > I have been experiencing problems with ObjectNames containing spaces. > The way the XSTL stylesheets are built is a problem because the URL > produced are not valid. > > I have found (and implemented) a "trick" in order to solve that: we can > add a method in common.xsl (I called it urlencode) that encodes properly > the URL and do a window.location to this newly created url. > > We replace all href values with urlencode(the old href value) and we're > done. > > Is anyone ok for such a fix? > > If so I will start updating all the stylesheet and commit. > > > Jerome. > > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel > |
|
From: Carlos Q. <car...@we...> - 2002-01-29 18:12:34
|
On Tuesday 29 January 2002 20:00, J=E9r=F4me BERNARD wrote: Hi > Hi, > > I have been experiencing problems with ObjectNames containing spaces. > The way the XSTL stylesheets are built is a problem because the URL > produced are not valid. Checking the specs now I discovered that this is indeed legal, never=20 thougt about before. > > I have found (and implemented) a "trick" in order to solve that: we can > add a method in common.xsl (I called it urlencode) that encodes properl= y > the URL and do a window.location to this newly created url. Where exactly do you want to put that? For instance to jump from the serv= er=20 view to the mbean view? It will be perhaps necessary in many places > > We replace all href values with urlencode(the old href value) and we're > done. Is this XSL? Or are you using some extension? > > Is anyone ok for such a fix? > > If so I will start updating all the stylesheet and commit. I think is ok, but could you send me a copy beforehand > > > Jerome. > > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: B. <jer...@xt...> - 2002-01-29 18:01:10
|
Hi, I have been experiencing problems with ObjectNames containing spaces. The way the XSTL stylesheets are built is a problem because the URL produced are not valid. I have found (and implemented) a "trick" in order to solve that: we can add a method in common.xsl (I called it urlencode) that encodes properly the URL and do a window.location to this newly created url. We replace all href values with urlencode(the old href value) and we're done. Is anyone ok for such a fix? If so I will start updating all the stylesheet and commit. Jerome. |
|
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 |
|
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: Carlos Q. <car...@we...> - 2002-01-29 08:31:08
|
Hi Shall we put a date for the beta2? Tomorrow? My status is: Basic Authentication/SSL support working. Several new views Some fixes. For RC: More HttpAdaptor views Support for (some) custom data types in HttpAdaptor SMTPMBean (This can go to next release) Lots of documentation... Anyway I feel we can go for a beta2. Opinions? Regards Carlos Quiroz > On Tuesday 22 January 2002 20:10, Bordet, Simone wrote: > Hi > > > Hi, > > > > > What about OpenMBean is it interesting enough to make a > > > (pre)release beofre > > > the final specs are settled? > > > > Uhm, can't remember exactly, but this will take quite a while to do, I'd > > better go with 1.0, and then with 1.1 with OpenMBeans... > > I agree specially because the specs is not clear enough IMHO > > > Simon > > > > _______________________________________________ > > 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: 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-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: 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: 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: 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: 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 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: <no...@so...> - 2002-01-28 15:37:26
|
Bugs item #507764, was opened at 2002-01-23 17:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=507764&group_id=34041 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Simone Bordet (biorn_steedom) Summary: RequiredModelMBean.invoke() Initial Comment: RequiredModelMBean.invoke(opName,...) makes no attempt to match any of the methods defined in its own class tree, it only looks in ModelMBeanInfo for the named operation. In other words the following will fail: server.invoke(mbeanObjectName, "setManagedResource", new Object[] {new TestBean(), "ObjectReference"}, new String[] {"java.lang.Object", "java.lang.String"}); when mbeanObjectName refers to a RequiredModelMBean that has been successfully registered with the server - note the method name 'setManagedResource' is defined by the class ReqiredModelMBean(). ---------------------------------------------------------------------- >Comment By: Simone Bordet (biorn_steedom) Date: 2002-01-28 07:31 Message: Logged In: YES user_id=128193 The RI examples are bad coded. The JMX specification forbids that type of calls. The issue has been discussed also in jmx-forum, and confirmed as a bug in the RI and in the RI examples. Closed, resolution being not a bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=507764&group_id=34041 |
|
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: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: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: Bordet, S. <Sim...@co...> - 2002-01-28 09:18:38
|
Hi Tom, > I have been working with the JMX Reference Implementation to=20 > build some > additional features (similar to the JDMK). I have everything=20 > working using > the JMX RI and found your implementation. =20 Be aware that coding against the RI is very different from coding = against the JMX spec. Many threads have been discussed here that start = with "cannot run this in OpenJMX, it runs in the RI, why ?" and that = ends up with "a bug in the RI". > I found that your version of the > NotificationBroadcaster interface has 3 method signatures for > removeNotificationListener() and the JMX RI implementation=20 > has 1. After > looking at the JMX spec., it says that: >=20 > "This method takes a reference to a NotificationListener=20 > object, as well as > a hand-back object." >=20 > The JMX RI implementation isn't even correct, in it only takes the > NotificationListener as a parameter. I know the specs. are vague, but > wondering why you added the extra ones? Because they are very much needed :) Furthermore, the spec should upgrade and fix this mess: the only way I = see not to break the already written code is to add the spec compliant = method and/or the third one, that was missed by the spec writers, but is = indeed needed. For further info, you can look in the archives of this mailing list, or = in the ones of jmx...@ja..., where this issue has been = discusses in detail. > P.S. Also wondering if there are any future plans to add=20 > some of the extra > features as in the JDMK to OpenJMX in the future, or will you=20 > wait till > solid specs. are release on these types of features (i.e.=20 > Cascading Agents, > auto-detection, etc.)? For what pertain JSR 160, I guess we will wait the spec, even if I'm on = the expert group for that JSR. For other feautures such as SNMP support and other stuff, we are wide = open to contributions. Regards Simon |
1 message has been excluded from this view by a project administrator.
