Menu
▾
▴
openjmx-devel
|
From: Bordet, S. <Sim...@co...> - 2002-01-18 11:44:53
|
Hi Jerome
> Oups, wrong mailing-list...
No, it is something that may interest also the user's list :)
> Hi,
>=20
> I have finally finished a source code generator base on XDoclet. It is
> able to generate the MBean interface and the MBean=20
> description based on
> comment you put in the implementation source file.
Just sweet !
> I have attached to the following mail the MBean implementation with
> proper XDoclet comments.
> I have also attached the results of XDoclet on the=20
> implementation source.
Yes. But I have few questions:
1) there is a managed attribute "dummy", but no setDummy and getDummy in =
the MBean interface. Beware also of the fact that I can call the data =
member "m_dummy", does this impact the MBean interface (I don't want =
getm_dummy() ;) ? And also, beware of the fact that a "dummy" attribute =
*must* generate a getdummy() and setdummy(), not getDummy() and =
setDummy(). Can I specify if it's read-only ?
2) just for consistency with JMX, i would change "managed-method" to =
"managed-operation"
3) setStatus is an attribute, not an operation. Is there a way to =
enforce check of this kind of mistakes ? If a method is described as =
operation, but it's an attribute, can i know this when I'm generating =
the code with XDoclet ?
4) I see that the parameter information for operations is not included, =
it's just because start() has no parameters ?
Well, it's a great job, Jerome !
Let me know if you need clarification on the questions above, but I =
guess the xdoclet generation will rock !
I didn't know that XDoclet became so powerful.
> I had to patch XDoclet because the template engine does not=20
> support yet
> constructors. I am working with one of the XDoclet administrator in
> order to put my modifications into CVS.
> If you want to use it for now on, send me a mail and I will=20
> send you the
> modified xdoclet.jar file.
Ok !
> If we want to add this features to OpenJMX (I think this is a really
> nice thing),=20
Absolutely agree !
> let me know where in the distribution I should do so...
Ok, let me play a bit with CVS, I will tell you soon.
If you have time, can you write a document on this beautiful feauture, =
when will be ready ?
If you don't have time just tell, we must absolutely write something =
about for users.
Thanks
Simon
> Below is an extract of the ant stuff you need to add before=20
> compilation:
> <taskdef name=3D"templatedoclet" classname=3D"xdoclet.DocletTask">
> <classpath refid=3D"xdoclet"/>
> </taskdef>
>=20
> <!-- Generate the MBean sources -->
> <templatedoclet sourcepath=3D"${src}" destdir=3D"${src}"
> classpathref=3D"xdoclet" force=3D"yes">
> <fileset dir=3D"${src}">
> <include name=3D"com/xtremejava/webos/jmx/MyService.java"/>
> </fileset>
> <template templateFile=3D"${src}/mbean.j"
> destinationFile=3D"{0}MBean.java" havingClassTag=3D"openjmx:mbean"/>
> </templatedoclet>
> <!-- Generate the MBeanDescription sources -->
> <templatedoclet sourcepath=3D"${src}" destdir=3D"${src}"
> classpathref=3D"xdoclet" force=3D"yes">
> <fileset dir=3D"${src}">
> <include name=3D"com/xtremejava/webos/jmx/MyService.java"/>
> </fileset>
> <template templateFile=3D"${src}/mbean-description.j"
> destinationFile=3D"{0}MBeanDescription.java"=20
> havingClassTag=3D"openjmx:mbean"/>
> </templatedoclet>
>=20
>=20
|
|
From: Bordet, S. <Sim...@co...> - 2002-01-18 17:39:09
|
Hi, > >No, see above... "if the attribute is write-only, then the=20 > setter will have the description." > >It's in the openjmx implementation that I will do the trick:=20 > if getter present take its description and ignore the=20 > setter's, if no getter take the setter's one. However the=20 > trick costs nothing and it's completely transparent. > > > Ok. This will make it easier for me. Thanks :-) It's not done however. Do you need it asap ? > I will have to make a custom handler for the warning (whether=20 > or not we=20 > are trying to tell it's an operation when it's an attribute). Well, if it's too complicated, you know, keep it simple for now. > Anyway I have to because of the difficulty with indexes taken as=20 > parameters on the methods. There is no way using regulars=20 > XDoclet tags=20 > to solve this problem. Would I be allowed to extend the=20 > MBeanDescriptionAdaptor in order to take as input the name of the=20 > parameter? or do I have to solve this issue at source code=20 > generation time? Not sure I understand, but for the last question, no. The MBeanServer is calling the description implementation, and I don't = know the *names* of the parameters of operations or constructors, and I = cannot know them. So I cannot pass them to the description = implementation. Hope helped Simon |
|
From: B. <jer...@xt...> - 2002-01-18 17:46:05
|
Bordet, Simone wrote: >Hi, > >>>No, see above... "if the attribute is write-only, then the >>> >>setter will have the description." >> >>>It's in the openjmx implementation that I will do the trick: >>> >>if getter present take its description and ignore the >>setter's, if no getter take the setter's one. However the >>trick costs nothing and it's completely transparent. >> >>Ok. This will make it easier for me. Thanks :-) >> > >It's not done however. Do you need it asap ? > I do not need it because it has no impact on my output. It has just impact on the MBean itself. When I have finished, it will be good to have it asap though. >>I will have to make a custom handler for the warning (whether >>or not we >>are trying to tell it's an operation when it's an attribute). >> > >Well, if it's too complicated, you know, keep it simple for now. > I will experiment and see what I can do. >>Anyway I have to because of the difficulty with indexes taken as >>parameters on the methods. There is no way using regulars >>XDoclet tags >>to solve this problem. Would I be allowed to extend the >>MBeanDescriptionAdaptor in order to take as input the name of the >>parameter? or do I have to solve this issue at source code >>generation time? >> > >Not sure I understand, but for the last question, no. > >The MBeanServer is calling the description implementation, and I don't know the *names* of the parameters of operations or constructors, and I cannot know them. So I cannot pass them to the description implementation. > Yes. Stupid question :-) Ok. I hope to finish the whole thing for the beginning of next week (except the documentation perhaps). BTW where in the doc should I add some stuff? Jerome. |
|
From: Bordet, S. <Sim...@co...> - 2002-01-21 13:21:04
|
Jerome, > -----Original Message----- > From: J=E9r=F4me BERNARD [mailto:jer...@xt...] > Sent: luned=EC 21 gennaio 2002 12:46 > To: ope...@li... > Subject: Re: [Openjmx-devel] [Fwd: Source code generation of MBean > interfaces and descriptions] >=20 >=20 > Hi, >=20 > I have something that should be it now. > Can you check if the generated code matches your expectations? No, it has the drawback of having the name of the attribute at class = level; in case of method renaming, a pain... It's not possible to implement my solution ? Simon >=20 > The implementation, interface and description sources are attached. >=20 > BTW, there is no need for you to handle the getter/setter description=20 > problem. It is handled at XDoclet level (I found a quite easy=20 > way to do so). >=20 >=20 > Jerome. >=20 |
|
From: B. <jer...@xt...> - 2002-01-21 13:29:30
Attachments:
MyService.java
|
Bordet, Simone wrote: >Jerome, > >>-----Original Message----- >>From: J=E9r=F4me BERNARD [mailto:jer...@xt...] >>Sent: luned=EC 21 gennaio 2002 12:46 >>To: ope...@li... >>Subject: Re: [Openjmx-devel] [Fwd: Source code generation of MBean >>interfaces and descriptions] >> >> >>Hi, >> >>I have something that should be it now. >>Can you check if the generated code matches your expectations? >> > >No, it has the drawback of having the name of the attribute at class lev= el; in case of method renaming, a pain... > >It's not possible to implement my solution ? > Either I do not understand what you mean or you don't have the good=20 implementation. I attached it once more. The javadoc tags are defined at method level and not class level like=20 what you said last time. Jerome. |
|
From: Bordet, S. <Sim...@co...> - 2002-01-21 13:35:51
|
Jerome, > Either I do not understand what you mean or you don't have the good=20 > implementation. I attached it once more. > The javadoc tags are defined at method level and not class level like=20 > what you said last time. sorry, I looked at the wrong files, last version it's just perfect. I will finish what I have in mind for CVS later, so that you can commit = it. Thanks Simon |
|
From: Bordet, S. <Sim...@co...> - 2002-01-21 13:44:00
|
Hi, > Ok. Meanwhile I will start writing the documentation. Do you think we=20 > need more examples than the one I gave (I mean attached all=20 > the time)? I=20 > think this example illustrates all the basic/advanced features of the=20 > automatic generation of source code... I agree, it covers all the cases. For me it's clear and simple. Simon |
|
From: B. <jer...@xt...> - 2002-01-21 13:47:29
|
Bordet, Simone wrote: >Hi, > >>Ok. Meanwhile I will start writing the documentation. Do you think we >>need more examples than the one I gave (I mean attached all >>the time)? I >>think this example illustrates all the basic/advanced features of the >>automatic generation of source code... >> > >I agree, it covers all the cases. For me it's clear and simple. > Ok. Great. As soon as you will have prepared the CVS arbo, I will commit the sources. Jerome. |
|
From: Carlos Q. <Car...@ge...> - 2002-02-01 15:26:18
|
> -----Original Message----- > From: J=E9r=F4me BERNARD [mailto:jer...@xt...] > Sent: 01 February 2002 17:22 > To: ope...@li... > Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] >=20 > Carlos Quiroz wrote: >=20 > > > > > >>Ok. I am facing a classic "chicken and the egg" problem :-) > >>I have updated the example and am ready to commit BUT it will break > >>examples compilation since we need XDoclet to go through the MBean > >>implementation file in order to generate at least the interface. So I > >>have to add in CVS the xdoclet.jar file. > >> > >Yes I noticed the problem. Perhaps you could add a test via setting an > >available property which is true if the XXXMBean.java file is available, > and > >only then it will invoke the xdoclet task. > > > XDoclet requires ant.jar to be in the classpath or somewhere else (but > then precised in the build.xml file) and I am wondering what I should > do. Should I check if there is an ant.jar file in the lib directory? Or > should I add ant.jar in CVS in the lib directory? Ant.jar is in the build dir >=20 > Jerome. >=20 >=20 > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: B. <jer...@xt...> - 2002-02-01 15:38:24
|
Carlos Quiroz wrote: >Ant.jar is in the build dir > Ok. Thank you. I have commited the example and the required changes now. Jerome. |
|
From: Carlos Q. <car...@ge...> - 2002-02-01 15:43:19
|
>Carlos Quiroz wrote: > >>Ant.jar is in the build dir >> >Ok. Thank you. I have commited the example and the required changes now. I noticed and thanks a lot what about a beta2 release this weekend? > >Jerome. > > >_______________________________________________ >Openjmx-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openjmx-devel > |
|
From: B. <jer...@xt...> - 2002-02-01 15:48:41
|
Well fine for me. I guess the documentation has to be updated a bit and I won't be free for working on it this week-end but if I am lucky I will be able to finish it today. Anyway, I suppose that with the example, some developers in need of this feature will be able to figure out how to use it :-) Jerome. Carlos Quiroz wrote: >>Carlos Quiroz wrote: >> >>>Ant.jar is in the build dir >>> >>Ok. Thank you. I have commited the example and the required changes now. >> >I noticed and thanks a lot > >what about a beta2 release this weekend? > |
|
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: 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: 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: 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 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: 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: 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: 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 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 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: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: 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-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 |
Thanks for helping keep SourceForge clean.
X