openjmx-devel

Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean]

[Dmitri C. <di...@bi...>]

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

Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean]

[Carlos Q. <car...@we...>]

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

Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean]

[Carlos Q. <car...@we...>]

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

Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean]

[Dmitri C. <di...@bi...>]

> 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

Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean]

[Carlos Q. <car...@we...>]

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

Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean]

[Dmitri C. <di...@bi...>]

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

Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean]

[Carlos Q. <car...@we...>]

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

Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean]

[B. <jer...@xt...>]

Carlos Quiroz wrote:

>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 :-)
>
I am beginning to work on the mlet template. Just need to dig a little 
bit more in the merge system of XDoclet though.

I hope to have something working by the end of the week or the beginning 
of the next one. Depending on how fast the service configuration goes 
on, I might also add a template for it. When the format of the XML 
document is defined, I will worked on it too.

Jerome.

Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean]

[Dmitri C. <di...@bi...>]

if you need any help - just ask.

cheers
dim

----- Original Message -----
From: "Jérôme Bernard" <jer...@xt...>
To: <ope...@li...>
Sent: Thursday, February 07, 2002 3:20 AM
Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean]


> Carlos Quiroz wrote:
>
> >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 :-)
> >
> I am beginning to work on the mlet template. Just need to dig a little
> bit more in the merge system of XDoclet though.
>
> I hope to have something working by the end of the week or the beginning
> of the next one. Depending on how fast the service configuration goes
> on, I might also add a template for it. When the format of the XML
> document is defined, I will worked on it too.
>
> Jerome.
>
>
> _______________________________________________
> Openjmx-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openjmx-devel
>

RE: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean]

[Bronwen C. <Bro...@ja...>]

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

RE: [Openjmx-devel] [Fwd: Source code generation of MBean interfaces and descriptions]

[Bordet, S. <Sim...@co...>]

Hi Jerome,

> >1) there is a managed attribute "dummy", but no setDummy and=20
> getDummy in the MBean interface. Beware also of the fact that=20
> I can call the data member "m_dummy", does this impact the=20
> MBean interface (I don't want getm_dummy() ;) ? And also,=20
> beware of the fact that a "dummy" attribute *must* generate a=20
> getdummy() and setdummy(), not getDummy() and setDummy(). Can=20
> I specify if it's read-only ?
> >
> Ok. There are plenty of questions out there :-)
> First, as there is a diffence between a java field and a JMX=20
> attribute,=20
> where should we put the description?
> I think it should not be on the field itself because I am not sure it=20
> will be easy to check for the presence of the getter/setter methods.
> But then, should we put it on the getter or setter method? both=20
> (redundant information and possible mistakes -- don't like that)?
> Or we could put in the class javadoc and indicate something=20
> like that:=20
> "@openjmx:attribute name=3D"Dummy" description=3D"A dummy attribute". =
It=20
> would be up to the developer to implement the getDummy and setDummy=20
> methods. If the variable itself is m_dummy, then we don't care: the=20
> developer has to code the right stuff in the getter/setter methods.
>=20
> Regarding access-mode, i suggest we add another attribute on the=20
> "openjmx:attribute" tag such "access" or "access-mode" and=20
> the possible=20
> values would be "ro", "wo" or "both".

Ok, I thought some more on it, what about this ?

/**
 * @openjmx:managed-attribute description=3D"The status of this MBean"
 */
public int getStatus() {return 0;}
/**
 * @openjmx:managed-attribute
 */
public void setStatus(int status) {}

I specify always on getter the description information; I just put the =
tag on the setter so that it will appear in the MBean interface. I will =
do a small change to the code so that getters are always processed =
before setters, so setters can have no description; if the attribute is =
write-only, then the setter will have the description.

About access I don't care anymore.

> >3) setStatus is an attribute, not an operation.
> >
> As explained in 1) it would be up to the developer to specify=20
> that. If=20
> the "openjmx:attribute" tag is missing, the output will be wrong.
>=20
> > Is there a way to enforce check of this kind of mistakes ?=20
> If a method is described as operation, but it's an attribute,=20
> can i know this when I'm generating the code with XDoclet ?
> >
> This is linked to question 1). I will look for a way to check those=20
> things but I am not sure it will be so easy.

Should not be that difficult; you can copy/paste the method =
Utils.isAttributeGetter/Setter to know if a method is an attribute =
accessor; if you find the managed-operation tag on the method, emit a =
warning or an error. The opposite for operations.

> >If you have time, can you write a document on this beautiful=20
> feauture, when will be ready ?
> >If you don't have time just tell, we must absolutely write=20
> something about for users.
> >
> I guess I could, but english is not my native language, and I am not=20
> sure to be the best person for writing documentation: my=20
> english style=20
> is quite poor. I can however write a draft that someone could=20
> "re-style" i guess :-)

Too modest :)
Write it, I guess will be perfect.

Simon

Re: [Openjmx-devel] [Fwd: Source code generation of MBean interfaces and descriptions]

[B. <jer...@xt...>]

Bordet, Simone wrote:

>Hi Jerome,
>
>
>Ok, I thought some more on it, what about this ?
>
>/**
> * @openjmx:managed-attribute description="The status of this MBean"
> */
>public int getStatus() {return 0;}
>/**
> * @openjmx:managed-attribute
> */
>public void setStatus(int status) {}
>
>I specify always on getter the description information; I just put the tag on the setter so that it will appear in the MBean interface. I will do a small change to the code so that getters are always processed before setters, so setters can have no description; if the attribute is write-only, then the setter will have the description.
>
>About access I don't care anymore.
>
I have attached another proposition I have. There is the implementation 
(a little bit more complex than before) and the resulting interface and 
description.
I am now trying to verify if there are the getter/setter methods.

>>>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 ?
>>
>>This is linked to question 1). I will look for a way to check those 
>>things but I am not sure it will be so easy.
>>
>
>Should not be that difficult; you can copy/paste the method Utils.isAttributeGetter/Setter to know if a method is an attribute accessor; if you find the managed-operation tag on the method, emit a warning or an error. The opposite for operations.
>
Where do you want to emit the warning? in the resulting description? or 
on screen during the build process?
The first option is easier and the later is more complex.

>>>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.
>>
>>I guess I could, but english is not my native language, and I am not 
>>sure to be the best person for writing documentation: my 
>>english style 
>>is quite poor. I can however write a draft that someone could 
>>"re-style" i guess :-)
>>
>
>Too modest :)
>Write it, I guess will be perfect.
>
Ok. Anyway we will see :-)



Jerome.

>

RE: [Openjmx-devel] [Fwd: Source code generation of MBean interfaces and descriptions]

[Bordet, S. <Sim...@co...>]

Hi Jerome,

> >Ok, I thought some more on it, what about this ?
> >
> >/**
> > * @openjmx:managed-attribute description=3D"The status of this =
MBean"
> > */
> >public int getStatus() {return 0;}
> >/**
> > * @openjmx:managed-attribute
> > */
> >public void setStatus(int status) {}
> >
> >I specify always on getter the description information; I=20
> just put the tag on the setter so that it will appear in the=20
> MBean interface. I will do a small change to the code so that=20
> getters are always processed before setters, so setters can=20
> have no description; if the attribute is write-only, then the=20
> setter will have the description.
> >
> >About access I don't care anymore.
> >
> I have attached another proposition I have. There is the=20
> implementation=20
> (a little bit more complex than before) and the resulting=20
> interface and=20
> description.
> I am now trying to verify if there are the getter/setter methods.

-1 :)
Because you have to specify at class level the attribute name, which in =
case of renaming is a pain...
I still prefer my solution.

> Where do you want to emit the warning? in the resulting=20
> description? or=20
> on screen during the build process?
> The first option is easier and the later is more complex.

The later will be perfect ;)=20

Simon

Re: [Openjmx-devel] [Fwd: Source code generation of MBean interfaces and descriptions]

[B. <jer...@xt...>]

Bordet, Simone wrote:

>Hi Jerome,
>
>>>Ok, I thought some more on it, what about this ?
>>>
>>>/**
>>>* @openjmx:managed-attribute description="The status of this MBean"
>>>*/
>>>public int getStatus() {return 0;}
>>>/**
>>>* @openjmx:managed-attribute
>>>*/
>>>public void setStatus(int status) {}
>>>
>>>I specify always on getter the description information; I 
>>>
>>just put the tag on the setter so that it will appear in the 
>>MBean interface. I will do a small change to the code so that 
>>getters are always processed before setters, so setters can 
>>have no description; if the attribute is write-only, then the 
>>setter will have the description.
>>
How can you deal with write-only attributes?
You would only have a setStatus method in the implementation with 
no-comment??

>>I have attached another proposition I have. There is the 
>>implementation 
>>(a little bit more complex than before) and the resulting 
>>interface and 
>>description.
>>I am now trying to verify if there are the getter/setter methods.
>>
>
>-1 :)
>Because you have to specify at class level the attribute name, which in case of renaming is a pain...
>I still prefer my solution.
>
Ok. As soon as I will have understood how to deal with write-only 
attribute, I will make changes in your way.

>>Where do you want to emit the warning? in the resulting 
>>description? or 
>>on screen during the build process?
>>The first option is easier and the later is more complex.
>>
>
>The later will be perfect ;) 
>
I did my best in order to avoid writing some specific XDoclet handlers 
for OpenJMX but due to the logic we want to put in, I have no choice :-(.
Sniff... More pain scheduled :-)

BTW, the project administrator of XDoclet has commited my patch. YES!!!!
At least we won't have to use a modified XDoclet release :-)

So to conclude, when I have the clarifications about WO attributes, I 
will update the templates and start coding the custom handlers...


Jerome.

RE: [Openjmx-devel] [Fwd: Source code generation of MBean interfaces and descriptions]

[Bordet, S. <Sim...@co...>]

Hi Jerome,

> >Hi Jerome,
> >
> >>>Ok, I thought some more on it, what about this ?
> >>>
> >>>/**
> >>>* @openjmx:managed-attribute description=3D"The status of this =
MBean"
> >>>*/
> >>>public int getStatus() {return 0;}
> >>>/**
> >>>* @openjmx:managed-attribute
> >>>*/
> >>>public void setStatus(int status) {}
> >>>
> >>>I specify always on getter the description information; I=20
> >>>
> >>just put the tag on the setter so that it will appear in the=20
> >>MBean interface. I will do a small change to the code so that=20
> >>getters are always processed before setters, so setters can=20
> >>have no description; if the attribute is write-only, then the=20
> >>setter will have the description.
> >>
> How can you deal with write-only attributes?
> You would only have a setStatus method in the implementation with=20
> no-comment??

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.

> >>Where do you want to emit the warning? in the resulting=20
> >>description? or=20
> >>on screen during the build process?
> >>The first option is easier and the later is more complex.
> >>
> >
> >The later will be perfect ;)=20
> >
> I did my best in order to avoid writing some specific XDoclet=20
> handlers=20
> for OpenJMX but due to the logic we want to put in, I have no=20
> choice :-(.
> Sniff... More pain scheduled :-)

No choice othen than... implement the latter ;) ? Or what ?

Simon

Re: [Openjmx-devel] [Fwd: Source code generation of MBean interfaces and descriptions]

[B. <jer...@xt...>]

Bordet, Simone wrote:

>Hi Jerome,
>
>>>Hi Jerome,
>>>
>>>>>Ok, I thought some more on it, what about this ?
>>>>>
>>>>>/**
>>>>>* @openjmx:managed-attribute description="The status of this MBean"
>>>>>*/
>>>>>public int getStatus() {return 0;}
>>>>>/**
>>>>>* @openjmx:managed-attribute
>>>>>*/
>>>>>public void setStatus(int status) {}
>>>>>
>>>>>I specify always on getter the description information; I 
>>>>>
>>>>just put the tag on the setter so that it will appear in the 
>>>>MBean interface. I will do a small change to the code so that 
>>>>getters are always processed before setters, so setters can 
>>>>have no description; if the attribute is write-only, then the 
>>>>setter will have the description.
>>>>
>>How can you deal with write-only attributes?
>>You would only have a setStatus method in the implementation with 
>>no-comment??
>>
>
>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 :-)

>>>>Where do you want to emit the warning? in the resulting 
>>>>description? or 
>>>>on screen during the build process?
>>>>The first option is easier and the later is more complex.
>>>>
>>>The later will be perfect ;) 
>>>
>>I did my best in order to avoid writing some specific XDoclet 
>>handlers 
>>for OpenJMX but due to the logic we want to put in, I have no 
>>choice :-(.
>>Sniff... More pain scheduled :-)
>>
>
>No choice othen than... implement the latter ;) ? Or what ?
>
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).
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?


Jerome.

RE: [Openjmx-devel] [Fwd: Source code generation of MBean interfaces and descriptions]

[Bordet, S. <Sim...@co...>]

Hi,

> I do not need it because it has no impact on my output. It has just=20
> impact on the MBean itself.
> When I have finished, it will be good to have it asap though.

Ok.

> Ok. I hope to finish the whole thing for the beginning of next week=20
> (except the documentation perhaps). BTW where in the doc should I add=20
> some stuff?

I guess you can add a chapter called "tools" and a section called =
"xdoclet" under it. Or whatever seems more appropriate to you.

Thanks

Simon

Re: [Openjmx-devel] [Fwd: Source code generation of MBean interfaces and descriptions]

[B. <jer...@xt...>]

Hi,

I have something that should be it now.
Can you check if the generated code matches your expectations?

The implementation, interface and description sources are attached.

BTW, there is no need for you to handle the getter/setter description 
problem. It is handled at XDoclet level (I found a quite easy way to do so).


Jerome.

Re: [Openjmx-devel] [Fwd: Source code generation of MBean interfaces and descriptions]

[B. <jer...@xt...>]

Bordet, Simone wrote:

>>I have attached to the following mail the MBean implementation with
>>proper XDoclet comments.
>>I have also attached the results of XDoclet on the 
>>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 ?
>
Ok. There are plenty of questions out there :-)
First, as there is a diffence between a java field and a JMX attribute, 
where should we put the description?
I think it should not be on the field itself because I am not sure it 
will be easy to check for the presence of the getter/setter methods.
But then, should we put it on the getter or setter method? both 
(redundant information and possible mistakes -- don't like that)?
Or we could put in the class javadoc and indicate something like that: 
"@openjmx:attribute name="Dummy" description="A dummy attribute". It 
would be up to the developer to implement the getDummy and setDummy 
methods. If the variable itself is m_dummy, then we don't care: the 
developer has to code the right stuff in the getter/setter methods.

Regarding access-mode, i suggest we add another attribute on the 
"openjmx:attribute" tag such "access" or "access-mode" and the possible 
values would be "ro", "wo" or "both".

>2) just for consistency with JMX, i would change "managed-method" to "managed-operation"
>
Fixed.

>3) setStatus is an attribute, not an operation.
>
As explained in 1) it would be up to the developer to specify that. If 
the "openjmx:attribute" tag is missing, the output will be wrong.

> 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 ?
>
This is linked to question 1). I will look for a way to check those 
things but I am not sure it will be so easy.

>4) I see that the parameter information for operations is not included, it's just because start() has no parameters ?
>
No. I have to apology, I have forgotten some few methods from the 
MBeanDescription class. Was playing too much with the example given in 
the documentation and forgot to check the definition of the interface :-(

>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 
>>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 
>>send you the
>>modified xdoclet.jar file.
>>
>
>Ok !
>
The patch has been sent and the administrator is currently reviewing it. 
Should be made available soon I hope...

>>If we want to add this features to OpenJMX (I think this is a really
>>nice thing), 
>>
>
>Absolutely agree !
>
We're at least two then ;-p

>>let me know where in the distribution I should do so...
>>
>
>Ok, let me play a bit with CVS, I will tell you soon.
>
Ok. Anyway I have to fix/enhance the generator, but I wanted to have 
some initial feedback before :-)

>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.
>
I guess I could, but english is not my native language, and I am not 
sure to be the best person for writing documentation: my english style 
is quite poor. I can however write a draft that someone could "re-style" 
i guess :-)


Jerome.