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: <no...@so...> - 2002-02-06 13:30:38
|
Bugs item #513698, was opened at 2002-02-06 03:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041 Category: Http Adapter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Glencross (chrisglencross) Assigned to: Carlos Quiroz (tibu) Summary: XSLTProcessor cannot read JARs on Win32 Initial Comment: Using beta 2 (same result in beta 1). Lines 287 and 291 use new File(this.path, path).toString() to build the path to a resource in a JAR file. Unfortunately, on Windows, this results in all '/' characters being replaced with '\', which means that no XSL resources can be found by the classloader. The user sees blank pages. Would it be problematic to change to using string concatenation to build JAR resource paths instead of File.toString()? ---------------------------------------------------------------------- >Comment By: Chris Glencross (chrisglencross) Date: 2002-02-06 05:30 Message: Logged In: YES user_id=337810 Slightly related: Elsewhere in the file URLs are generated by prefixing a file path with "file://". This only really works in Windows if the file path already contains a leading "/", which isn't conventional if a drive prefix is used. I would suggest that new File(path).toURL() be used to create the URL instead in a cross-platform manner. ---------------------------------------------------------------------- Comment By: Carlos Quiroz (tibu) Date: 2002-02-06 05:18 Message: Logged In: YES user_id=64333 Thanks for pointing this. It will be fixed ASAP ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041 |
|
From: <no...@so...> - 2002-02-06 13:18:24
|
Bugs item #513698, was opened at 2002-02-06 03:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041 Category: Http Adapter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Glencross (chrisglencross) >Assigned to: Carlos Quiroz (tibu) Summary: XSLTProcessor cannot read JARs on Win32 Initial Comment: Using beta 2 (same result in beta 1). Lines 287 and 291 use new File(this.path, path).toString() to build the path to a resource in a JAR file. Unfortunately, on Windows, this results in all '/' characters being replaced with '\', which means that no XSL resources can be found by the classloader. The user sees blank pages. Would it be problematic to change to using string concatenation to build JAR resource paths instead of File.toString()? ---------------------------------------------------------------------- >Comment By: Carlos Quiroz (tibu) Date: 2002-02-06 05:18 Message: Logged In: YES user_id=64333 Thanks for pointing this. It will be fixed ASAP ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041 |
|
From: <no...@so...> - 2002-02-06 11:55:18
|
Bugs item #513698, was opened at 2002-02-06 03:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041 Category: Http Adapter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Glencross (chrisglencross) Assigned to: Nobody/Anonymous (nobody) Summary: XSLTProcessor cannot read JARs on Win32 Initial Comment: Using beta 2 (same result in beta 1). Lines 287 and 291 use new File(this.path, path).toString() to build the path to a resource in a JAR file. Unfortunately, on Windows, this results in all '/' characters being replaced with '\', which means that no XSL resources can be found by the classloader. The user sees blank pages. Would it be problematic to change to using string concatenation to build JAR resource paths instead of File.toString()? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041 |
|
From: Carlos Q. <car...@we...> - 2002-02-05 22:09:49
|
On Wednesday 06 February 2002 00:06, Dmitri Colebatch wrote: > > > > Sorry problems again > > > > now @openjmx:description extends="" generates a class which doesn't > > > > extends anything but it has the extends word > > > > > > > > like MyServiceMBeanDescription extends > > > > > > > > @openjmx:description extends="XXX" generates the right > > > > > > > > MyServiceMBeanDescription extends XXX > > > > > > I think thats fair enough, I'm not sure what behaviour you'd prefer - > > > perhaps ignore the tag altogether? > > > > Actually now that you mention it, it is a debatable point of view. Then > > the right way to write should be > > @openjmx:description extends="openjmx.MBeanDescriptionAdaptor" > > > > in case you explicitely need it. That's probably clearer > > Any imports in the implementation class will also be imported into the > MBeanDescriptionAdaptor class. so the user should import the superclass > there, and the generated file will import it. This is how we've been doing > it with the ejb stuff. although I completely see the argument for fqcn. > Typically tho - its easier this way. > > > I'll leave as is and make a release > > still beta yes? do we want to get mlet generation done before final > release? I think it'd be a nice add-on. I hate those MLET files (o: of > course, completely your call. Yes beta2, no final yet and I agree about the MLET generation. We also discussed about using xdoclet for generation of configuration files, but that's somthing still in the future :-) > > cheers > dim |
|
From: Dmitri C. <di...@bi...> - 2002-02-05 22:06:56
|
> > > Sorry problems again > > > now @openjmx:description extends="" generates a class which doesn't > > > extends anything but it has the extends word > > > > > > like MyServiceMBeanDescription extends > > > > > > @openjmx:description extends="XXX" generates the right > > > > > > MyServiceMBeanDescription extends XXX > > > > I think thats fair enough, I'm not sure what behaviour you'd prefer - > > perhaps ignore the tag altogether? > Actually now that you mention it, it is a debatable point of view. Then the > right way to write should be > @openjmx:description extends="openjmx.MBeanDescriptionAdaptor" > > in case you explicitely need it. That's probably clearer Any imports in the implementation class will also be imported into the MBeanDescriptionAdaptor class. so the user should import the superclass there, and the generated file will import it. This is how we've been doing it with the ejb stuff. although I completely see the argument for fqcn. Typically tho - its easier this way. > I'll leave as is and make a release still beta yes? do we want to get mlet generation done before final release? I think it'd be a nice add-on. I hate those MLET files (o: of course, completely your call. cheers dim |
|
From: Carlos Q. <car...@we...> - 2002-02-05 22:00:16
|
On Tuesday 05 February 2002 23:42, Dmitri Colebatch wrote: > > On Tuesday 05 February 2002 23:03, Dmitri Colebatch wrote: > > > sorry about that - fixed in CVS now. > > > > Sorry problems again > > now @openjmx:description extends="" generates a class which doesn't > > extends anything but it has the extends word > > > > like MyServiceMBeanDescription extends > > > > @openjmx:description extends="XXX" generates the right > > > > MyServiceMBeanDescription extends XXX > > I think thats fair enough, I'm not sure what behaviour you'd prefer - > perhaps ignore the tag altogether? Actually now that you mention it, it is a debatable point of view. Then the right way to write should be @openjmx:description extends="openjmx.MBeanDescriptionAdaptor" in case you explicitely need it. That's probably clearer I'll leave as is and make a release > > but really, if someone has said it extends an empty class, then so be it. > javac behaves the same way (o: > > let me know what you'd like to see, and if its easy, then I have np with > it. > > cheers > dim |
|
From: Dmitri C. <di...@bi...> - 2002-02-05 21:43:05
|
> On Tuesday 05 February 2002 23:03, Dmitri Colebatch wrote: > > sorry about that - fixed in CVS now. > Sorry problems again > now @openjmx:description extends="" generates a class which doesn't extends > anything but it has the extends word > > like MyServiceMBeanDescription extends > > @openjmx:description extends="XXX" generates the right > > MyServiceMBeanDescription extends XXX I think thats fair enough, I'm not sure what behaviour you'd prefer - perhaps ignore the tag altogether? but really, if someone has said it extends an empty class, then so be it. javac behaves the same way (o: let me know what you'd like to see, and if its easy, then I have np with it. cheers dim |
|
From: Carlos Q. <car...@we...> - 2002-02-05 21:31:45
|
On Tuesday 05 February 2002 23:03, Dmitri Colebatch wrote: > sorry about that - fixed in CVS now. Sorry problems again now @openjmx:description extends=3D"" generates a class which doesn't ext= ends=20 anything but it has the extends word like MyServiceMBeanDescription extends=20 @openjmx:description extends=3D"XXX" generates the right MyServiceMBeanDescription extends XXX > > cheers > dim > > ----- Original Message ----- > From: "Carlos Quiroz" <car...@we...> > To: <ope...@li...> > Sent: Wednesday, February 06, 2002 7:34 AM > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > On Tuesday 05 February 2002 00:07, Dmitri Colebatch wrote: > > ahh shit... I didn't do a clean build, although I didn't change any > > classes, only templates, so it shouldn't be an issue. If you still h= ave > > a copy of a working jar, then just find the openjmx-descriptor.j temp= late > > (named something like that) and replace it with the one in XDoclet cv= s. > > > > I really do need to put that doco in dont I. let me know if the > > following doesn't seem logical: > > > > @jmx:mbean defines things that are related to the spec. Its presence > > indicates that a MyServiceMBean interface will be created for the > > MyService > > > class. the extends parameter specifies an interface for the > > MyServiceMBean > > > interface to extend. > > > > @openjmx:description defines things that are related to the openjmx > > description adaptor class. The absense of it means that all defaults > > will be followed for the openjmx description class. Its extends > > parameter allows the description class to extend a specific class - t= his > > class > > should > > > itself extend the openjmx abstract description class. If it is not > > there, and the MyService class extends FooService, then the > > MyServiceMBeanDescription class will extend FooServiceMBeanDescriptio= n > > (are > > > they the right class names?). If there is no @openjmx:descriptione > > extends=3D"" _and_ MyService doesn't extend anything, then > > MyServiceMBeanDescription will simply extend the OpenJMX abstract > > description class (sorry - cant remember the name). > > Hi sorry to bother you again. I did a built from CVS just a few moments= ago > and almost everything seems to work however > @openjmx:description extends=3D"" will produce a class > > MyServiceMBeanDescription extends Description > > and > @openjmx:description extends=3D"anything" will produce a class > > MyServiceMBeanDescription extends anythingDescription > > In the first case it should extend MBeanDescriptionAdaptor (notice that > this works fine if no @openjmx tag is present) > In the second case class should extend anything > > Regards > > > I'll do this in doco format, and it should seem clearer - any input i= s > > welcome (o: > > > > cheers > > dim > > > > ----- Original Message ----- > > From: "Carlos Quiroz" <car...@we...> > > To: <ope...@li...> > > Sent: Tuesday, February 05, 2002 8:44 AM > > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > > > On Monday 04 February 2002 23:07, Dmitri Colebatch wrote: > > > Ok - have a look in XDoclet CVS. > > > > > > example usage: > > > > > > /** > > > * Sample MBean implementation. > > > * @jmx:mbean name=3D":service=3DMyService" description=3D"My wonde= rful > > > service." * @openjmx:description extends=3D"AbstractMBeanDescriptio= n" > > > */ > > > > > > Over next weekend, I'll get the XDoclet side of the docs done so th= at > > > this is all a little bit more "proper" (o: > > > > Thanks a lot Dimitri... > > > > What is the name in jmx:mbean doing? Do you still have the jmx:mbean > > extends? > > > > I can't build it from CVS because of some serialveruid classes which > > don't compile, any idea? > > > > > > Regards > > > > > cheers > > > dim > > > > > > > > > ----- Original Message ----- > > > From: "J=E9r=F4me BERNARD" <jer...@xt...> > > > To: <ope...@li...> > > > Sent: Tuesday, February 05, 2002 1:10 AM > > > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > > > > > > > > Sounds good for me too. > > > > > > Jerome. > > > > > > Carlos Quiroz wrote: > > > >>-----Original Message----- > > > >>From: Dmitri Colebatch [mailto:di...@bi...] > > > >>Sent: 04 February 2002 13:47 > > > >>To: J=E9r=F4me BERNARD; ope...@li... > > > >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > > >> > > > >>Given that the description class is specific to OpenJMX and the > > > > > > > >interface > > > > > > > >>is > > > >>a spec thing, I would suggest keeping the current tag for the usu= al > > > >>scenario > > > >>(as you described), but allowing an optional @openjmx:description > > > >>extends=3D"" > > > >>for overriding this default behaviour. > > > >> > > > >>if you guys are agreeable with this I can check it into XDoclet c= vs > > > >>straight > > > >>away. > > > > > > > >I think this would be pretty OK > > > > > > > >>cheesr > > > >>dim > > > >> > > > >>----- Original Message ----- > > > >>From: "J=E9r=F4me BERNARD" <jer...@xt...> > > > >>To: <ope...@li...> > > > >>Sent: Monday, February 04, 2002 9:20 PM > > > >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > > >> > > > >>Carlos Quiroz wrote: > > > >>>On Sunday 03 February 2002 20:43, J=E9r=F4me BERNARD wrote: > > > >>>>What bug do you have? > > > >>>> > > > >>>>I think there a no changes planned in XDoclet. We will just add= an > > > >> > > > >>example > > > >> > > > >>>>and that's it. > > > >>>>So if there is still something wrong, let me know and I will fi= x it > > > > > > > >ASAP. > > > > > > > >>>Again with the extend=3D"XXX" which is expanded on the > > > >>> MBeanDescription > > > >> > > > >>class > > > >> > > > >>>to extends XXXMBeanDescription > > > >>> > > > >>>Now thinking a second time about it is maybe be design, is it? B= ut > > > >> > > > >>assumes > > > >> > > > >>>that your extended interface also has a Description class > > > >> > > > >>Yes. This is a design reason. I supposed that the class which wou= ld > > > >> be extended would be a MBeanDescription class too. This is also > > > >> because I found it easier to have only one extends attribute on = the > > > >> jmx:mbean > > > > > > > >tag > > > > > > > >>rather than having two (one for the interface and one for the > > > >>description) because I think that most of the cases will have a > > > >>description extending another one. > > > >> > > > >>What would you prefer/propose to do? > > > >> > > > >>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 > > > > > > > > > > > > _______________________________________________ > > > 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: Carlos Q. <car...@we...> - 2002-02-05 21:27:58
|
On Tuesday 05 February 2002 23:03, Dmitri Colebatch wrote: > sorry about that - fixed in CVS now. Thanks a lot I'll commit the new version to openjmx cvs > > cheers > dim > > ----- Original Message ----- > From: "Carlos Quiroz" <car...@we...> > To: <ope...@li...> > Sent: Wednesday, February 06, 2002 7:34 AM > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > On Tuesday 05 February 2002 00:07, Dmitri Colebatch wrote: > > ahh shit... I didn't do a clean build, although I didn't change any > > classes, only templates, so it shouldn't be an issue. If you still h= ave > > a copy of a working jar, then just find the openjmx-descriptor.j temp= late > > (named something like that) and replace it with the one in XDoclet cv= s. > > > > I really do need to put that doco in dont I. let me know if the > > following doesn't seem logical: > > > > @jmx:mbean defines things that are related to the spec. Its presence > > indicates that a MyServiceMBean interface will be created for the > > MyService > > > class. the extends parameter specifies an interface for the > > MyServiceMBean > > > interface to extend. > > > > @openjmx:description defines things that are related to the openjmx > > description adaptor class. The absense of it means that all defaults > > will be followed for the openjmx description class. Its extends > > parameter allows the description class to extend a specific class - t= his > > class > > should > > > itself extend the openjmx abstract description class. If it is not > > there, and the MyService class extends FooService, then the > > MyServiceMBeanDescription class will extend FooServiceMBeanDescriptio= n > > (are > > > they the right class names?). If there is no @openjmx:descriptione > > extends=3D"" _and_ MyService doesn't extend anything, then > > MyServiceMBeanDescription will simply extend the OpenJMX abstract > > description class (sorry - cant remember the name). > > Hi sorry to bother you again. I did a built from CVS just a few moments= ago > and almost everything seems to work however > @openjmx:description extends=3D"" will produce a class > > MyServiceMBeanDescription extends Description > > and > @openjmx:description extends=3D"anything" will produce a class > > MyServiceMBeanDescription extends anythingDescription > > In the first case it should extend MBeanDescriptionAdaptor (notice that > this works fine if no @openjmx tag is present) > In the second case class should extend anything > > Regards > > > I'll do this in doco format, and it should seem clearer - any input i= s > > welcome (o: > > > > cheers > > dim > > > > ----- Original Message ----- > > From: "Carlos Quiroz" <car...@we...> > > To: <ope...@li...> > > Sent: Tuesday, February 05, 2002 8:44 AM > > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > > > On Monday 04 February 2002 23:07, Dmitri Colebatch wrote: > > > Ok - have a look in XDoclet CVS. > > > > > > example usage: > > > > > > /** > > > * Sample MBean implementation. > > > * @jmx:mbean name=3D":service=3DMyService" description=3D"My wonde= rful > > > service." * @openjmx:description extends=3D"AbstractMBeanDescriptio= n" > > > */ > > > > > > Over next weekend, I'll get the XDoclet side of the docs done so th= at > > > this is all a little bit more "proper" (o: > > > > Thanks a lot Dimitri... > > > > What is the name in jmx:mbean doing? Do you still have the jmx:mbean > > extends? > > > > I can't build it from CVS because of some serialveruid classes which > > don't compile, any idea? > > > > > > Regards > > > > > cheers > > > dim > > > > > > > > > ----- Original Message ----- > > > From: "J=E9r=F4me BERNARD" <jer...@xt...> > > > To: <ope...@li...> > > > Sent: Tuesday, February 05, 2002 1:10 AM > > > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > > > > > > > > Sounds good for me too. > > > > > > Jerome. > > > > > > Carlos Quiroz wrote: > > > >>-----Original Message----- > > > >>From: Dmitri Colebatch [mailto:di...@bi...] > > > >>Sent: 04 February 2002 13:47 > > > >>To: J=E9r=F4me BERNARD; ope...@li... > > > >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > > >> > > > >>Given that the description class is specific to OpenJMX and the > > > > > > > >interface > > > > > > > >>is > > > >>a spec thing, I would suggest keeping the current tag for the usu= al > > > >>scenario > > > >>(as you described), but allowing an optional @openjmx:description > > > >>extends=3D"" > > > >>for overriding this default behaviour. > > > >> > > > >>if you guys are agreeable with this I can check it into XDoclet c= vs > > > >>straight > > > >>away. > > > > > > > >I think this would be pretty OK > > > > > > > >>cheesr > > > >>dim > > > >> > > > >>----- Original Message ----- > > > >>From: "J=E9r=F4me BERNARD" <jer...@xt...> > > > >>To: <ope...@li...> > > > >>Sent: Monday, February 04, 2002 9:20 PM > > > >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > > >> > > > >>Carlos Quiroz wrote: > > > >>>On Sunday 03 February 2002 20:43, J=E9r=F4me BERNARD wrote: > > > >>>>What bug do you have? > > > >>>> > > > >>>>I think there a no changes planned in XDoclet. We will just add= an > > > >> > > > >>example > > > >> > > > >>>>and that's it. > > > >>>>So if there is still something wrong, let me know and I will fi= x it > > > > > > > >ASAP. > > > > > > > >>>Again with the extend=3D"XXX" which is expanded on the > > > >>> MBeanDescription > > > >> > > > >>class > > > >> > > > >>>to extends XXXMBeanDescription > > > >>> > > > >>>Now thinking a second time about it is maybe be design, is it? B= ut > > > >> > > > >>assumes > > > >> > > > >>>that your extended interface also has a Description class > > > >> > > > >>Yes. This is a design reason. I supposed that the class which wou= ld > > > >> be extended would be a MBeanDescription class too. This is also > > > >> because I found it easier to have only one extends attribute on = the > > > >> jmx:mbean > > > > > > > >tag > > > > > > > >>rather than having two (one for the interface and one for the > > > >>description) because I think that most of the cases will have a > > > >>description extending another one. > > > >> > > > >>What would you prefer/propose to do? > > > >> > > > >>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 > > > > > > > > > > > > _______________________________________________ > > > 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: Dmitri C. <di...@bi...> - 2002-02-05 21:06:39
|
sorry about that - fixed in CVS now. cheers dim ----- Original Message ----- From: "Carlos Quiroz" <car...@we...> To: <ope...@li...> Sent: Wednesday, February 06, 2002 7:34 AM Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] On Tuesday 05 February 2002 00:07, Dmitri Colebatch wrote: > ahh shit... I didn't do a clean build, although I didn't change any > classes, only templates, so it shouldn't be an issue. If you still have a > copy of a working jar, then just find the openjmx-descriptor.j template > (named something like that) and replace it with the one in XDoclet cvs. > > I really do need to put that doco in dont I. let me know if the following > doesn't seem logical: > > @jmx:mbean defines things that are related to the spec. Its presence > indicates that a MyServiceMBean interface will be created for the MyService > class. the extends parameter specifies an interface for the MyServiceMBean > interface to extend. > > @openjmx:description defines things that are related to the openjmx > description adaptor class. The absense of it means that all defaults will > be followed for the openjmx description class. Its extends parameter > allows the description class to extend a specific class - this class should > itself extend the openjmx abstract description class. If it is not there, > and the MyService class extends FooService, then the > MyServiceMBeanDescription class will extend FooServiceMBeanDescription (are > they the right class names?). If there is no @openjmx:descriptione > extends="" _and_ MyService doesn't extend anything, then > MyServiceMBeanDescription will simply extend the OpenJMX abstract > description class (sorry - cant remember the name). Hi sorry to bother you again. I did a built from CVS just a few moments ago and almost everything seems to work however @openjmx:description extends="" will produce a class MyServiceMBeanDescription extends Description and @openjmx:description extends="anything" will produce a class MyServiceMBeanDescription extends anythingDescription In the first case it should extend MBeanDescriptionAdaptor (notice that this works fine if no @openjmx tag is present) In the second case class should extend anything Regards > > I'll do this in doco format, and it should seem clearer - any input is > welcome (o: > > cheers > dim > > ----- Original Message ----- > From: "Carlos Quiroz" <car...@we...> > To: <ope...@li...> > Sent: Tuesday, February 05, 2002 8:44 AM > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > On Monday 04 February 2002 23:07, Dmitri Colebatch wrote: > > Ok - have a look in XDoclet CVS. > > > > example usage: > > > > /** > > * Sample MBean implementation. > > * @jmx:mbean name=":service=MyService" description="My wonderful > > service." * @openjmx:description extends="AbstractMBeanDescription" > > */ > > > > Over next weekend, I'll get the XDoclet side of the docs done so that > > this is all a little bit more "proper" (o: > > Thanks a lot Dimitri... > > What is the name in jmx:mbean doing? Do you still have the jmx:mbean > extends? > > I can't build it from CVS because of some serialveruid classes which don't > compile, any idea? > > > Regards > > > cheers > > dim > > > > > > ----- Original Message ----- > > From: "Jérôme BERNARD" <jer...@xt...> > > To: <ope...@li...> > > Sent: Tuesday, February 05, 2002 1:10 AM > > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > > > > > Sounds good for me too. > > > > Jerome. > > > > Carlos Quiroz wrote: > > >>-----Original Message----- > > >>From: Dmitri Colebatch [mailto:di...@bi...] > > >>Sent: 04 February 2002 13:47 > > >>To: Jérôme BERNARD; ope...@li... > > >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > >> > > >>Given that the description class is specific to OpenJMX and the > > > > > >interface > > > > > >>is > > >>a spec thing, I would suggest keeping the current tag for the usual > > >>scenario > > >>(as you described), but allowing an optional @openjmx:description > > >>extends="" > > >>for overriding this default behaviour. > > >> > > >>if you guys are agreeable with this I can check it into XDoclet cvs > > >>straight > > >>away. > > > > > >I think this would be pretty OK > > > > > >>cheesr > > >>dim > > >> > > >>----- Original Message ----- > > >>From: "Jérôme BERNARD" <jer...@xt...> > > >>To: <ope...@li...> > > >>Sent: Monday, February 04, 2002 9:20 PM > > >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > >> > > >>Carlos Quiroz wrote: > > >>>On Sunday 03 February 2002 20:43, Jérôme BERNARD wrote: > > >>>>What bug do you have? > > >>>> > > >>>>I think there a no changes planned in XDoclet. We will just add an > > >> > > >>example > > >> > > >>>>and that's it. > > >>>>So if there is still something wrong, let me know and I will fix it > > > > > >ASAP. > > > > > >>>Again with the extend="XXX" which is expanded on the MBeanDescription > > >> > > >>class > > >> > > >>>to extends XXXMBeanDescription > > >>> > > >>>Now thinking a second time about it is maybe be design, is it? But > > >> > > >>assumes > > >> > > >>>that your extended interface also has a Description class > > >> > > >>Yes. This is a design reason. I supposed that the class which would be > > >>extended would be a MBeanDescription class too. This is also because I > > >>found it easier to have only one extends attribute on the jmx:mbean > > > > > >tag > > > > > >>rather than having two (one for the interface and one for the > > >>description) because I think that most of the cases will have a > > >>description extending another one. > > >> > > >>What would you prefer/propose to do? > > >> > > >>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 > > > > > > > > _______________________________________________ > > 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: Carlos Q. <car...@we...> - 2002-02-05 20:37:11
|
On Tuesday 05 February 2002 00:07, Dmitri Colebatch wrote: > ahh shit... I didn't do a clean build, although I didn't change any > classes, only templates, so it shouldn't be an issue. If you still hav= e a > copy of a working jar, then just find the openjmx-descriptor.j template > (named something like that) and replace it with the one in XDoclet cvs. > > I really do need to put that doco in dont I. let me know if the follow= ing > doesn't seem logical: > > @jmx:mbean defines things that are related to the spec. Its presence > indicates that a MyServiceMBean interface will be created for the MySer= vice > class. the extends parameter specifies an interface for the MyServiceM= Bean > interface to extend. > > @openjmx:description defines things that are related to the openjmx > description adaptor class. The absense of it means that all defaults w= ill > be followed for the openjmx description class. Its extends parameter > allows the description class to extend a specific class - this class sh= ould > itself extend the openjmx abstract description class. If it is not the= re, > and the MyService class extends FooService, then the > MyServiceMBeanDescription class will extend FooServiceMBeanDescription = (are > they the right class names?). If there is no @openjmx:descriptione > extends=3D"" _and_ MyService doesn't extend anything, then > MyServiceMBeanDescription will simply extend the OpenJMX abstract > description class (sorry - cant remember the name). Hi sorry to bother you again. I did a built from CVS just a few moments a= go=20 and almost everything seems to work however @openjmx:description extends=3D"" will produce a class=20 MyServiceMBeanDescription extends Description and=20 @openjmx:description extends=3D"anything" will produce a class=20 MyServiceMBeanDescription extends anythingDescription In the first case it should extend MBeanDescriptionAdaptor (notice that t= his=20 works fine if no @openjmx tag is present) In the second case class should extend anything=20 Regards > > I'll do this in doco format, and it should seem clearer - any input is > welcome (o: > > cheers > dim > > ----- Original Message ----- > From: "Carlos Quiroz" <car...@we...> > To: <ope...@li...> > Sent: Tuesday, February 05, 2002 8:44 AM > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > On Monday 04 February 2002 23:07, Dmitri Colebatch wrote: > > Ok - have a look in XDoclet CVS. > > > > example usage: > > > > /** > > * Sample MBean implementation. > > * @jmx:mbean name=3D":service=3DMyService" description=3D"My wonderf= ul > > service." * @openjmx:description extends=3D"AbstractMBeanDescription" > > */ > > > > Over next weekend, I'll get the XDoclet side of the docs done so that > > this is all a little bit more "proper" (o: > > Thanks a lot Dimitri... > > What is the name in jmx:mbean doing? Do you still have the jmx:mbean > extends? > > I can't build it from CVS because of some serialveruid classes which do= n't > compile, any idea? > > > Regards > > > cheers > > dim > > > > > > ----- Original Message ----- > > From: "J=E9r=F4me BERNARD" <jer...@xt...> > > To: <ope...@li...> > > Sent: Tuesday, February 05, 2002 1:10 AM > > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > > > > > Sounds good for me too. > > > > Jerome. > > > > Carlos Quiroz wrote: > > >>-----Original Message----- > > >>From: Dmitri Colebatch [mailto:di...@bi...] > > >>Sent: 04 February 2002 13:47 > > >>To: J=E9r=F4me BERNARD; ope...@li... > > >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > >> > > >>Given that the description class is specific to OpenJMX and the > > > > > >interface > > > > > >>is > > >>a spec thing, I would suggest keeping the current tag for the usual > > >>scenario > > >>(as you described), but allowing an optional @openjmx:description > > >>extends=3D"" > > >>for overriding this default behaviour. > > >> > > >>if you guys are agreeable with this I can check it into XDoclet cvs > > >>straight > > >>away. > > > > > >I think this would be pretty OK > > > > > >>cheesr > > >>dim > > >> > > >>----- Original Message ----- > > >>From: "J=E9r=F4me BERNARD" <jer...@xt...> > > >>To: <ope...@li...> > > >>Sent: Monday, February 04, 2002 9:20 PM > > >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > >> > > >>Carlos Quiroz wrote: > > >>>On Sunday 03 February 2002 20:43, J=E9r=F4me BERNARD wrote: > > >>>>What bug do you have? > > >>>> > > >>>>I think there a no changes planned in XDoclet. We will just add a= n > > >> > > >>example > > >> > > >>>>and that's it. > > >>>>So if there is still something wrong, let me know and I will fix = it > > > > > >ASAP. > > > > > >>>Again with the extend=3D"XXX" which is expanded on the MBeanDescri= ption > > >> > > >>class > > >> > > >>>to extends XXXMBeanDescription > > >>> > > >>>Now thinking a second time about it is maybe be design, is it? But > > >> > > >>assumes > > >> > > >>>that your extended interface also has a Description class > > >> > > >>Yes. This is a design reason. I supposed that the class which would= be > > >>extended would be a MBeanDescription class too. This is also becaus= e I > > >>found it easier to have only one extends attribute on the jmx:mbean > > > > > >tag > > > > > >>rather than having two (one for the interface and one for the > > >>description) because I think that most of the cases will have a > > >>description extending another one. > > >> > > >>What would you prefer/propose to do? > > >> > > >>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 > > > > > > > > _______________________________________________ > > 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: B. <jer...@xt...> - 2002-02-05 08:54:41
|
Dmitri Colebatch wrote: >>And then what does the name parameter do? >> > >atm - nothing. when we have an mlet template I imagine it'll be used there. sound reasonable? > Yes. This is a basic usage of this parameter. Moreover, it has been kept for historic reasons too. Jerome. |
|
From: Carlos Q. <car...@we...> - 2002-02-04 23:17:16
|
On Tuesday 05 February 2002 01:13, Dmitri Colebatch wrote: > > On Tuesday 05 February 2002 00:55, Dmitri Colebatch wrote: > > > > > @jmx:mbean defines things that are related to the spec. Its > > > > > presence indicates that a MyServiceMBean interface will be created > > > > > for the MyService class. the extends parameter specifies an > > > > > interface for the MyServiceMBean interface to extend. > > > > > > > > Ok, so @jmx:mbean will ONLY take a extends parameter, no name, no > > > > description > > > > > > sorry. no, @jmx:mbean does take a name and description parameter. > > > > And then what does the name parameter do? > > atm - nothing. when we have an mlet template I imagine it'll be used > there. sound reasonable? yes it does :-) We just say that in the docs Thanks a lot > > cheers > dim |
|
From: Dmitri C. <di...@bi...> - 2002-02-04 23:13:42
|
> On Tuesday 05 February 2002 00:55, Dmitri Colebatch wrote: > > > > @jmx:mbean defines things that are related to the spec. Its presence > > > > indicates that a MyServiceMBean interface will be created for the > > > > MyService class. the extends parameter specifies an interface for the > > > > MyServiceMBean interface to extend. > > > > > > Ok, so @jmx:mbean will ONLY take a extends parameter, no name, no > > > description > > > > sorry. no, @jmx:mbean does take a name and description parameter. > And then what does the name parameter do? atm - nothing. when we have an mlet template I imagine it'll be used there. sound reasonable? cheers dim |
|
From: Carlos Q. <car...@we...> - 2002-02-04 23:10:53
|
On Tuesday 05 February 2002 00:55, Dmitri Colebatch wrote: > > > @jmx:mbean defines things that are related to the spec. Its presence > > > indicates that a MyServiceMBean interface will be created for the > > > MyService class. the extends parameter specifies an interface for the > > > MyServiceMBean interface to extend. > > > > Ok, so @jmx:mbean will ONLY take a extends parameter, no name, no > > description > > sorry. no, @jmx:mbean does take a name and description parameter. And then what does the name parameter do? > > > > @openjmx:description defines things that are related to the openjmx > > > description adaptor class. The absense of it means that all defaults > > > will be followed for the openjmx description class. Its extends > > > parameter allows the description class to extend a specific class - > > > this class should itself extend the openjmx abstract description class. > > > If it is not there, and the MyService class extends FooService, then > > > the > > > > Is it that the class extends FooService or that the @jmx:mbean has > > parameter extends="FooService". The latter seems the correct to me > > sorry - yes, its if the @jmx:mbean has the extends paramter. my bad. > > > > MyServiceMBeanDescription class will extend FooServiceMBeanDescription > > > (are they the right class names?). If there is no > > > @openjmx:descriptione extends="" _and_ MyService doesn't extend > > > anything, then > > > MyServiceMBeanDescription will simply extend the OpenJMX abstract > > > description class (sorry - cant remember the name). > > > > it is MBeanDescriptionAdaptor > > ta > > cheers > dim |
|
From: Dmitri C. <di...@bi...> - 2002-02-04 22:55:31
|
> > @jmx:mbean defines things that are related to the spec. Its presence > > indicates that a MyServiceMBean interface will be created for the MyService > > class. the extends parameter specifies an interface for the MyServiceMBean > > interface to extend. > Ok, so @jmx:mbean will ONLY take a extends parameter, no name, no description sorry. no, @jmx:mbean does take a name and description parameter. > > @openjmx:description defines things that are related to the openjmx > > description adaptor class. The absense of it means that all defaults will > > be followed for the openjmx description class. Its extends parameter > > allows the description class to extend a specific class - this class should > > itself extend the openjmx abstract description class. If it is not there, > > and the MyService class extends FooService, then the > > Is it that the class extends FooService or that the @jmx:mbean has parameter > extends="FooService". The latter seems the correct to me sorry - yes, its if the @jmx:mbean has the extends paramter. my bad. > > MyServiceMBeanDescription class will extend FooServiceMBeanDescription (are > > they the right class names?). If there is no @openjmx:descriptione > > extends="" _and_ MyService doesn't extend anything, then > > MyServiceMBeanDescription will simply extend the OpenJMX abstract > > description class (sorry - cant remember the name). > it is MBeanDescriptionAdaptor ta cheers dim |
|
From: Carlos Q. <car...@we...> - 2002-02-04 22:37:50
|
On Tuesday 05 February 2002 00:07, Dmitri Colebatch wrote: > ahh shit... I didn't do a clean build, although I didn't change any > classes, only templates, so it shouldn't be an issue. If you still hav= e a > copy of a working jar, then just find the openjmx-descriptor.j template > (named something like that) and replace it with the one in XDoclet cvs. Ok will do > > I really do need to put that doco in dont I. let me know if the follow= ing > doesn't seem logical: > > @jmx:mbean defines things that are related to the spec. Its presence > indicates that a MyServiceMBean interface will be created for the MySer= vice > class. the extends parameter specifies an interface for the MyServiceM= Bean > interface to extend. Ok, so @jmx:mbean will ONLY take a extends parameter, no name, no descrip= tion > > @openjmx:description defines things that are related to the openjmx > description adaptor class. The absense of it means that all defaults w= ill > be followed for the openjmx description class. Its extends parameter > allows the description class to extend a specific class - this class sh= ould > itself extend the openjmx abstract description class. If it is not the= re, > and the MyService class extends FooService, then the Is it that the class extends FooService or that the @jmx:mbean has parame= ter=20 extends=3D"FooService". The latter seems the correct to me > MyServiceMBeanDescription class will extend FooServiceMBeanDescription = (are > they the right class names?). If there is no @openjmx:descriptione > extends=3D"" _and_ MyService doesn't extend anything, then > MyServiceMBeanDescription will simply extend the OpenJMX abstract > description class (sorry - cant remember the name). it is MBeanDescriptionAdaptor > > I'll do this in doco format, and it should seem clearer - any input is > welcome (o: > > cheers > dim > > ----- Original Message ----- > From: "Carlos Quiroz" <car...@we...> > To: <ope...@li...> > Sent: Tuesday, February 05, 2002 8:44 AM > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > On Monday 04 February 2002 23:07, Dmitri Colebatch wrote: > > Ok - have a look in XDoclet CVS. > > > > example usage: > > > > /** > > * Sample MBean implementation. > > * @jmx:mbean name=3D":service=3DMyService" description=3D"My wonderf= ul > > service." * @openjmx:description extends=3D"AbstractMBeanDescription" > > */ > > > > Over next weekend, I'll get the XDoclet side of the docs done so that > > this is all a little bit more "proper" (o: > > Thanks a lot Dimitri... > > What is the name in jmx:mbean doing? Do you still have the jmx:mbean > extends? > > I can't build it from CVS because of some serialveruid classes which do= n't > compile, any idea? > > > Regards > > > cheers > > dim > > > > > > ----- Original Message ----- > > From: "J=E9r=F4me BERNARD" <jer...@xt...> > > To: <ope...@li...> > > Sent: Tuesday, February 05, 2002 1:10 AM > > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > > > > > Sounds good for me too. > > > > Jerome. > > > > Carlos Quiroz wrote: > > >>-----Original Message----- > > >>From: Dmitri Colebatch [mailto:di...@bi...] > > >>Sent: 04 February 2002 13:47 > > >>To: J=E9r=F4me BERNARD; ope...@li... > > >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > >> > > >>Given that the description class is specific to OpenJMX and the > > > > > >interface > > > > > >>is > > >>a spec thing, I would suggest keeping the current tag for the usual > > >>scenario > > >>(as you described), but allowing an optional @openjmx:description > > >>extends=3D"" > > >>for overriding this default behaviour. > > >> > > >>if you guys are agreeable with this I can check it into XDoclet cvs > > >>straight > > >>away. > > > > > >I think this would be pretty OK > > > > > >>cheesr > > >>dim > > >> > > >>----- Original Message ----- > > >>From: "J=E9r=F4me BERNARD" <jer...@xt...> > > >>To: <ope...@li...> > > >>Sent: Monday, February 04, 2002 9:20 PM > > >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > >> > > >>Carlos Quiroz wrote: > > >>>On Sunday 03 February 2002 20:43, J=E9r=F4me BERNARD wrote: > > >>>>What bug do you have? > > >>>> > > >>>>I think there a no changes planned in XDoclet. We will just add a= n > > >> > > >>example > > >> > > >>>>and that's it. > > >>>>So if there is still something wrong, let me know and I will fix = it > > > > > >ASAP. > > > > > >>>Again with the extend=3D"XXX" which is expanded on the MBeanDescri= ption > > >> > > >>class > > >> > > >>>to extends XXXMBeanDescription > > >>> > > >>>Now thinking a second time about it is maybe be design, is it? But > > >> > > >>assumes > > >> > > >>>that your extended interface also has a Description class > > >> > > >>Yes. This is a design reason. I supposed that the class which would= be > > >>extended would be a MBeanDescription class too. This is also becaus= e I > > >>found it easier to have only one extends attribute on the jmx:mbean > > > > > >tag > > > > > >>rather than having two (one for the interface and one for the > > >>description) because I think that most of the cases will have a > > >>description extending another one. > > >> > > >>What would you prefer/propose to do? > > >> > > >>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 > > > > > > > > _______________________________________________ > > 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: bronwen.cassidy <bro...@ja...> - 2002-02-04 22:30:57
|
Sounds fine, at least i understood it :-) > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...]On Behalf Of Dmitri > Colebatch > Sent: 04 February 2002 22:08 > To: Carlos Quiroz; ope...@li... > Cc: Xdoclet-Devel@Lists. Sourceforge. Net > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > > ahh shit... I didn't do a clean build, although I didn't change > any classes, only templates, so it shouldn't be an issue. If you > still have a copy of a working jar, then just find the > openjmx-descriptor.j template (named something like that) and > replace it with > the one in XDoclet cvs. > > I really do need to put that doco in dont I. let me know if the > following doesn't seem logical: > > @jmx:mbean defines things that are related to the spec. Its > presence indicates that a MyServiceMBean interface will be created for > the MyService class. the extends parameter specifies an > interface for the MyServiceMBean interface to extend. > > @openjmx:description defines things that are related to the > openjmx description adaptor class. The absense of it means that all > defaults will be followed for the openjmx description class. Its > extends parameter allows the description class to extend a > specific class - this class should itself extend the openjmx > abstract description class. If it is not there, and the MyService > class extends FooService, then the MyServiceMBeanDescription > class will extend FooServiceMBeanDescription (are they the right class > names?). If there is no @openjmx:descriptione extends="" _and_ > MyService doesn't extend anything, then MyServiceMBeanDescription > will simply extend the OpenJMX abstract description class (sorry > - cant remember the name). > > I'll do this in doco format, and it should seem clearer - any > input is welcome (o: > > cheers > dim > > ----- Original Message ----- > From: "Carlos Quiroz" <car...@we...> > To: <ope...@li...> > Sent: Tuesday, February 05, 2002 8:44 AM > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > > On Monday 04 February 2002 23:07, Dmitri Colebatch wrote: > > Ok - have a look in XDoclet CVS. > > > > example usage: > > > > /** > > * Sample MBean implementation. > > * @jmx:mbean name=":service=MyService" description="My > wonderful service." > > * @openjmx:description extends="AbstractMBeanDescription" > > */ > > > > Over next weekend, I'll get the XDoclet side of the docs done > so that this > > is all a little bit more "proper" (o: > Thanks a lot Dimitri... > > What is the name in jmx:mbean doing? Do you still have the > jmx:mbean extends? > > I can't build it from CVS because of some serialveruid classes which don't > compile, any idea? > > > Regards > > > > > cheers > > dim > > > > > > ----- Original Message ----- > > From: "Jérôme BERNARD" <jer...@xt...> > > To: <ope...@li...> > > Sent: Tuesday, February 05, 2002 1:10 AM > > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > > > > > Sounds good for me too. > > > > Jerome. > > > > Carlos Quiroz wrote: > > >>-----Original Message----- > > >>From: Dmitri Colebatch [mailto:di...@bi...] > > >>Sent: 04 February 2002 13:47 > > >>To: Jérôme BERNARD; ope...@li... > > >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > >> > > >>Given that the description class is specific to OpenJMX and the > > > > > >interface > > > > > >>is > > >>a spec thing, I would suggest keeping the current tag for the usual > > >>scenario > > >>(as you described), but allowing an optional @openjmx:description > > >>extends="" > > >>for overriding this default behaviour. > > >> > > >>if you guys are agreeable with this I can check it into XDoclet cvs > > >>straight > > >>away. > > > > > >I think this would be pretty OK > > > > > >>cheesr > > >>dim > > >> > > >>----- Original Message ----- > > >>From: "Jérôme BERNARD" <jer...@xt...> > > >>To: <ope...@li...> > > >>Sent: Monday, February 04, 2002 9:20 PM > > >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > >> > > >>Carlos Quiroz wrote: > > >>>On Sunday 03 February 2002 20:43, Jérôme BERNARD wrote: > > >>>>What bug do you have? > > >>>> > > >>>>I think there a no changes planned in XDoclet. We will just add an > > >> > > >>example > > >> > > >>>>and that's it. > > >>>>So if there is still something wrong, let me know and I will fix it > > > > > >ASAP. > > > > > >>>Again with the extend="XXX" which is expanded on the MBeanDescription > > >> > > >>class > > >> > > >>>to extends XXXMBeanDescription > > >>> > > >>>Now thinking a second time about it is maybe be design, is it? But > > >> > > >>assumes > > >> > > >>>that your extended interface also has a Description class > > >> > > >>Yes. This is a design reason. I supposed that the class which would be > > >>extended would be a MBeanDescription class too. This is also because I > > >>found it easier to have only one extends attribute on the jmx:mbean > > > > > >tag > > > > > >>rather than having two (one for the interface and one for the > > >>description) because I think that most of the cases will have a > > >>description extending another one. > > >> > > >>What would you prefer/propose to do? > > >> > > >>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 > > > > > > > > _______________________________________________ > > 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: Dmitri C. <di...@bi...> - 2002-02-04 22:08:03
|
ahh shit... I didn't do a clean build, although I didn't change any classes, only templates, so it shouldn't be an issue. If you still have a copy of a working jar, then just find the openjmx-descriptor.j template (named something like that) and replace it with the one in XDoclet cvs. I really do need to put that doco in dont I. let me know if the following doesn't seem logical: @jmx:mbean defines things that are related to the spec. Its presence indicates that a MyServiceMBean interface will be created for the MyService class. the extends parameter specifies an interface for the MyServiceMBean interface to extend. @openjmx:description defines things that are related to the openjmx description adaptor class. The absense of it means that all defaults will be followed for the openjmx description class. Its extends parameter allows the description class to extend a specific class - this class should itself extend the openjmx abstract description class. If it is not there, and the MyService class extends FooService, then the MyServiceMBeanDescription class will extend FooServiceMBeanDescription (are they the right class names?). If there is no @openjmx:descriptione extends="" _and_ MyService doesn't extend anything, then MyServiceMBeanDescription will simply extend the OpenJMX abstract description class (sorry - cant remember the name). I'll do this in doco format, and it should seem clearer - any input is welcome (o: cheers dim ----- Original Message ----- From: "Carlos Quiroz" <car...@we...> To: <ope...@li...> Sent: Tuesday, February 05, 2002 8:44 AM Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] On Monday 04 February 2002 23:07, Dmitri Colebatch wrote: > Ok - have a look in XDoclet CVS. > > example usage: > > /** > * Sample MBean implementation. > * @jmx:mbean name=":service=MyService" description="My wonderful service." > * @openjmx:description extends="AbstractMBeanDescription" > */ > > Over next weekend, I'll get the XDoclet side of the docs done so that this > is all a little bit more "proper" (o: Thanks a lot Dimitri... What is the name in jmx:mbean doing? Do you still have the jmx:mbean extends? I can't build it from CVS because of some serialveruid classes which don't compile, any idea? Regards > > cheers > dim > > > ----- Original Message ----- > From: "Jérôme BERNARD" <jer...@xt...> > To: <ope...@li...> > Sent: Tuesday, February 05, 2002 1:10 AM > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > > Sounds good for me too. > > Jerome. > > Carlos Quiroz wrote: > >>-----Original Message----- > >>From: Dmitri Colebatch [mailto:di...@bi...] > >>Sent: 04 February 2002 13:47 > >>To: Jérôme BERNARD; ope...@li... > >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > >> > >>Given that the description class is specific to OpenJMX and the > > > >interface > > > >>is > >>a spec thing, I would suggest keeping the current tag for the usual > >>scenario > >>(as you described), but allowing an optional @openjmx:description > >>extends="" > >>for overriding this default behaviour. > >> > >>if you guys are agreeable with this I can check it into XDoclet cvs > >>straight > >>away. > > > >I think this would be pretty OK > > > >>cheesr > >>dim > >> > >>----- Original Message ----- > >>From: "Jérôme BERNARD" <jer...@xt...> > >>To: <ope...@li...> > >>Sent: Monday, February 04, 2002 9:20 PM > >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > >> > >>Carlos Quiroz wrote: > >>>On Sunday 03 February 2002 20:43, Jérôme BERNARD wrote: > >>>>What bug do you have? > >>>> > >>>>I think there a no changes planned in XDoclet. We will just add an > >> > >>example > >> > >>>>and that's it. > >>>>So if there is still something wrong, let me know and I will fix it > > > >ASAP. > > > >>>Again with the extend="XXX" which is expanded on the MBeanDescription > >> > >>class > >> > >>>to extends XXXMBeanDescription > >>> > >>>Now thinking a second time about it is maybe be design, is it? But > >> > >>assumes > >> > >>>that your extended interface also has a Description class > >> > >>Yes. This is a design reason. I supposed that the class which would be > >>extended would be a MBeanDescription class too. This is also because I > >>found it easier to have only one extends attribute on the jmx:mbean > > > >tag > > > >>rather than having two (one for the interface and one for the > >>description) because I think that most of the cases will have a > >>description extending another one. > >> > >>What would you prefer/propose to do? > >> > >>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 > > > > _______________________________________________ > 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: Carlos Q. <car...@we...> - 2002-02-04 21:47:31
|
On Monday 04 February 2002 23:07, Dmitri Colebatch wrote: > Ok - have a look in XDoclet CVS. > > example usage: > > /** > * Sample MBean implementation. > * @jmx:mbean name=3D":service=3DMyService" description=3D"My wonderful= service." > * @openjmx:description extends=3D"AbstractMBeanDescription" > */ > > Over next weekend, I'll get the XDoclet side of the docs done so that t= his > is all a little bit more "proper" (o: Thanks a lot Dimitri... What is the name in jmx:mbean doing? Do you still have the jmx:mbean exte= nds? I can't build it from CVS because of some serialveruid classes which don'= t=20 compile, any idea?=20 Regards > > cheers > dim > > > ----- Original Message ----- > From: "J=E9r=F4me BERNARD" <jer...@xt...> > To: <ope...@li...> > Sent: Tuesday, February 05, 2002 1:10 AM > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > > > Sounds good for me too. > > Jerome. > > Carlos Quiroz wrote: > >>-----Original Message----- > >>From: Dmitri Colebatch [mailto:di...@bi...] > >>Sent: 04 February 2002 13:47 > >>To: J=E9r=F4me BERNARD; ope...@li... > >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > >> > >>Given that the description class is specific to OpenJMX and the > > > >interface > > > >>is > >>a spec thing, I would suggest keeping the current tag for the usual > >>scenario > >>(as you described), but allowing an optional @openjmx:description > >>extends=3D"" > >>for overriding this default behaviour. > >> > >>if you guys are agreeable with this I can check it into XDoclet cvs > >>straight > >>away. > > > >I think this would be pretty OK > > > >>cheesr > >>dim > >> > >>----- Original Message ----- > >>From: "J=E9r=F4me BERNARD" <jer...@xt...> > >>To: <ope...@li...> > >>Sent: Monday, February 04, 2002 9:20 PM > >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > >> > >>Carlos Quiroz wrote: > >>>On Sunday 03 February 2002 20:43, J=E9r=F4me BERNARD wrote: > >>>>What bug do you have? > >>>> > >>>>I think there a no changes planned in XDoclet. We will just add an > >> > >>example > >> > >>>>and that's it. > >>>>So if there is still something wrong, let me know and I will fix it > > > >ASAP. > > > >>>Again with the extend=3D"XXX" which is expanded on the MBeanDescript= ion > >> > >>class > >> > >>>to extends XXXMBeanDescription > >>> > >>>Now thinking a second time about it is maybe be design, is it? But > >> > >>assumes > >> > >>>that your extended interface also has a Description class > >> > >>Yes. This is a design reason. I supposed that the class which would b= e > >>extended would be a MBeanDescription class too. This is also because = I > >>found it easier to have only one extends attribute on the jmx:mbean > > > >tag > > > >>rather than having two (one for the interface and one for the > >>description) because I think that most of the cases will have a > >>description extending another one. > >> > >>What would you prefer/propose to do? > >> > >>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 > > > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: Dmitri C. <di...@bi...> - 2002-02-04 21:10:43
|
Ok - have a look in XDoclet CVS. example usage: /** * Sample MBean implementation. * @jmx:mbean name=":service=MyService" description="My wonderful service." * @openjmx:description extends="AbstractMBeanDescription" */ Over next weekend, I'll get the XDoclet side of the docs done so that this is all a little bit more "proper" (o: cheers dim ----- Original Message ----- From: "Jérôme BERNARD" <jer...@xt...> To: <ope...@li...> Sent: Tuesday, February 05, 2002 1:10 AM Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] Sounds good for me too. Jerome. Carlos Quiroz wrote: > >>-----Original Message----- >>From: Dmitri Colebatch [mailto:di...@bi...] >>Sent: 04 February 2002 13:47 >>To: Jérôme BERNARD; ope...@li... >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] >> >>Given that the description class is specific to OpenJMX and the >> >interface > >>is >>a spec thing, I would suggest keeping the current tag for the usual >>scenario >>(as you described), but allowing an optional @openjmx:description >>extends="" >>for overriding this default behaviour. >> >>if you guys are agreeable with this I can check it into XDoclet cvs >>straight >>away. >> >I think this would be pretty OK > >>cheesr >>dim >> >>----- Original Message ----- >>From: "Jérôme BERNARD" <jer...@xt...> >>To: <ope...@li...> >>Sent: Monday, February 04, 2002 9:20 PM >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] >> >> >>Carlos Quiroz wrote: >> >>>On Sunday 03 February 2002 20:43, Jérôme BERNARD wrote: >>> >>>>What bug do you have? >>>> >>>>I think there a no changes planned in XDoclet. We will just add an >>>> >>example >> >>>>and that's it. >>>>So if there is still something wrong, let me know and I will fix it >>>> >ASAP. > >>>Again with the extend="XXX" which is expanded on the MBeanDescription >>> >>class >> >>>to extends XXXMBeanDescription >>> >>>Now thinking a second time about it is maybe be design, is it? But >>> >>assumes >> >>>that your extended interface also has a Description class >>> >>Yes. This is a design reason. I supposed that the class which would be >>extended would be a MBeanDescription class too. This is also because I >>found it easier to have only one extends attribute on the jmx:mbean >> >tag > >>rather than having two (one for the interface and one for the >>description) because I think that most of the cases will have a >>description extending another one. >> >>What would you prefer/propose to do? >> >>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: Bronwen C. <Bro...@ja...> - 2002-02-04 14:23:08
|
Sounds Great :-) > -----Original Message----- > From: J=E9r=F4me BERNARD [mailto:jer...@xt...] > Sent: 04 February 2002 14:10 > To: ope...@li... > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] >=20 >=20 > Sounds good for me too. >=20 > Jerome. >=20 > Carlos Quiroz wrote: >=20 > > > >>-----Original Message----- > >>From: Dmitri Colebatch [mailto:di...@bi...] > >>Sent: 04 February 2002 13:47 > >>To: J=E9r=F4me BERNARD; ope...@li... > >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > >> > >>Given that the description class is specific to OpenJMX and the > >> > >interface > > > >>is > >>a spec thing, I would suggest keeping the current tag for the usual > >>scenario > >>(as you described), but allowing an optional @openjmx:description > >>extends=3D"" > >>for overriding this default behaviour. > >> > >>if you guys are agreeable with this I can check it into XDoclet cvs > >>straight > >>away. > >> > >I think this would be pretty OK > > > >>cheesr > >>dim > >> > >>----- Original Message ----- > >>From: "J=E9r=F4me BERNARD" <jer...@xt...> > >>To: <ope...@li...> > >>Sent: Monday, February 04, 2002 9:20 PM > >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > >> > >> > >>Carlos Quiroz wrote: > >> > >>>On Sunday 03 February 2002 20:43, J=E9r=F4me BERNARD wrote: > >>> > >>>>What bug do you have? > >>>> > >>>>I think there a no changes planned in XDoclet. We will just add = an > >>>> > >>example > >> > >>>>and that's it. > >>>>So if there is still something wrong, let me know and I=20 > will fix it > >>>> > >ASAP. > > > >>>Again with the extend=3D"XXX" which is expanded on the=20 > MBeanDescription > >>> > >>class > >> > >>>to extends XXXMBeanDescription > >>> > >>>Now thinking a second time about it is maybe be design, is it? But > >>> > >>assumes > >> > >>>that your extended interface also has a Description class > >>> > >>Yes. This is a design reason. I supposed that the class=20 > which would be > >>extended would be a MBeanDescription class too. This is=20 > also because I > >>found it easier to have only one extends attribute on the jmx:mbean > >> > >tag > > > >>rather than having two (one for the interface and one for the > >>description) because I think that most of the cases will have a > >>description extending another one. > >> > >>What would you prefer/propose to do? > >> > >>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 > > >=20 >=20 >=20 > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel >=20 |
|
From: B. <jer...@xt...> - 2002-02-04 14:11:00
|
Sounds good for me too. Jerome. Carlos Quiroz wrote: > >>-----Original Message----- >>From: Dmitri Colebatch [mailto:di...@bi...] >>Sent: 04 February 2002 13:47 >>To: J=E9r=F4me BERNARD; ope...@li... >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] >> >>Given that the description class is specific to OpenJMX and the >> >interface > >>is >>a spec thing, I would suggest keeping the current tag for the usual >>scenario >>(as you described), but allowing an optional @openjmx:description >>extends=3D"" >>for overriding this default behaviour. >> >>if you guys are agreeable with this I can check it into XDoclet cvs >>straight >>away. >> >I think this would be pretty OK > >>cheesr >>dim >> >>----- Original Message ----- >>From: "J=E9r=F4me BERNARD" <jer...@xt...> >>To: <ope...@li...> >>Sent: Monday, February 04, 2002 9:20 PM >>Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] >> >> >>Carlos Quiroz wrote: >> >>>On Sunday 03 February 2002 20:43, J=E9r=F4me BERNARD wrote: >>> >>>>What bug do you have? >>>> >>>>I think there a no changes planned in XDoclet. We will just add an >>>> >>example >> >>>>and that's it. >>>>So if there is still something wrong, let me know and I will fix it >>>> >ASAP. > >>>Again with the extend=3D"XXX" which is expanded on the MBeanDescriptio= n >>> >>class >> >>>to extends XXXMBeanDescription >>> >>>Now thinking a second time about it is maybe be design, is it? But >>> >>assumes >> >>>that your extended interface also has a Description class >>> >>Yes. This is a design reason. I supposed that the class which would be >>extended would be a MBeanDescription class too. This is also because I >>found it easier to have only one extends attribute on the jmx:mbean >> >tag > >>rather than having two (one for the interface and one for the >>description) because I think that most of the cases will have a >>description extending another one. >> >>What would you prefer/propose to do? >> >>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: Carlos Q. <Car...@ge...> - 2002-02-04 14:00:38
|
> -----Original Message----- > From: Dmitri Colebatch [mailto:di...@bi...] > Sent: 04 February 2002 13:47 > To: J=E9r=F4me BERNARD; ope...@li... > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] >=20 > Given that the description class is specific to OpenJMX and the interface > is > a spec thing, I would suggest keeping the current tag for the usual > scenario > (as you described), but allowing an optional @openjmx:description > extends=3D"" > for overriding this default behaviour. >=20 > if you guys are agreeable with this I can check it into XDoclet cvs > straight > away. I think this would be pretty OK >=20 > cheesr > dim >=20 > ----- Original Message ----- > From: "J=E9r=F4me BERNARD" <jer...@xt...> > To: <ope...@li...> > Sent: Monday, February 04, 2002 9:20 PM > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] >=20 >=20 > Carlos Quiroz wrote: >=20 > >On Sunday 03 February 2002 20:43, J=E9r=F4me BERNARD wrote: > > > >>What bug do you have? > >> > >>I think there a no changes planned in XDoclet. We will just add an > example > >>and that's it. > >>So if there is still something wrong, let me know and I will fix it ASAP. > >> > >Again with the extend=3D"XXX" which is expanded on the = MBeanDescription > class > >to extends XXXMBeanDescription > > > >Now thinking a second time about it is maybe be design, is it? But > assumes > >that your extended interface also has a Description class > > > Yes. This is a design reason. I supposed that the class which would be > extended would be a MBeanDescription class too. This is also because I > found it easier to have only one extends attribute on the jmx:mbean tag > rather than having two (one for the interface and one for the > description) because I think that most of the cases will have a > description extending another one. >=20 > What would you prefer/propose to do? >=20 > Jerome. >=20 >=20 >=20 >=20 > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel >=20 >=20 >=20 > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: Dmitri C. <di...@bi...> - 2002-02-04 11:49:41
|
Given that the description class is specific to OpenJMX and the interface is a spec thing, I would suggest keeping the current tag for the usual scenario (as you described), but allowing an optional @openjmx:description extends="" for overriding this default behaviour. if you guys are agreeable with this I can check it into XDoclet cvs straight away. cheesr dim ----- Original Message ----- From: "Jérôme BERNARD" <jer...@xt...> To: <ope...@li...> Sent: Monday, February 04, 2002 9:20 PM Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] Carlos Quiroz wrote: >On Sunday 03 February 2002 20:43, Jérôme BERNARD wrote: > >>What bug do you have? >> >>I think there a no changes planned in XDoclet. We will just add an example >>and that's it. >>So if there is still something wrong, let me know and I will fix it ASAP. >> >Again with the extend="XXX" which is expanded on the MBeanDescription class >to extends XXXMBeanDescription > >Now thinking a second time about it is maybe be design, is it? But assumes >that your extended interface also has a Description class > Yes. This is a design reason. I supposed that the class which would be extended would be a MBeanDescription class too. This is also because I found it easier to have only one extends attribute on the jmx:mbean tag rather than having two (one for the interface and one for the description) because I think that most of the cases will have a description extending another one. What would you prefer/propose to do? Jerome. _______________________________________________ Openjmx-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
1 message has been excluded from this view by a project administrator.
