Re: Service MBeans getting attributes initialized twice

[David Jencks]

On Thursday, December 4, 2003, at 02:13 PM, Cabrera, Alan wrote:

-----Original Message-----
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 04, 2003 1:18 PM
To: [EMAIL PROTECTED]
Subject: Re: Service MBeans getting attributes initialized twice

On Thursday, December 4, 2003, at 05:05 AM, Alan D. Cabrera wrote:

-----Original Message-----
From: David Jencks [mailto:[EMAIL PROTECTED]
So, being a little too lazy today to investigate for
myself...., are
the values on the first set call from the service.xml or
the initial
values in the descriptor?
From the service.xml file.
I have a wish list item for Service MBeans.  I would like to declare
the
MBean interface in the service.xml file so that I don't
have to create
a
static getGeronimoMBeanInfo because I am very lazy.
You can use a separate xml descriptor, it needs to be in the same
package and with the same name as the class.
i.e.
org.foo.Bar.class
org.foo.Bar.xml
I think Gianni wrote an xdoclet plugin to generate these...
In the service.xml file you use the class name as a
descriptor, just as
if you wrote a getGeronimoMBeanInfo static method.
However....
--In JBoss I added the ability to include the "XMBean descriptor"
inline in the service.xml file.  It was sort of usable if the
service.xml file was generated by code, but IMNSHO totally human
unreadable.  After a month or two I found myself looking at one of
these service.xml files and wondering what on earth was going on.
To be sure, a generated XML descriptor file has no business being in 
the
service.xml file.  I don't think anyone is proposing that.

-- After dealing with lots of xdoclet xml descriptor generation for 
mbeans (again in JBoss), I'm not sure it's such a great idea.  At the
moment, I find looking at a getGeronimoMBeanInfo easier to decipher
what is in the mbean interface than looking at a descriptor
xml file or
looking at javadoc comments spread through the file.  I also find it
easier to write than the javadoc comments, and Intellij and the
compiler find the syntax problems for me.
I never looked at the xdoclet interface that gets generated, why would 
I
look at the generated XML file?  Also, what may be syntactically 
correct may
not be semantically correct as we would not be using a single source 
for
information; I've already been burned a couple times by not having a
semantically correct GeronimoMBeanInfo.  Using xdoclet, it would be 
both.
I've been burned many times using the jboss xmbean descriptors 
generated by xdoclet because there is no reasonable way to syntax check 
the rather complicated javadoc tags needed as input to xdoclet.  I have 
found maintaining these tags very difficult -- they tend to be 
write-only.  After this experience, I want to try something else.

I think in the long run we may be happier if we add more conveniences
to the GeronimoMBeanInfo setup like the
addAllOperationsDefinedIn(?name) that Hiram added that lets
you expose
an interface in one step.
The problem w/ that is that it only registers operators and I still 
have to
write code, code that, IMHO, should be auto generated.  What about 
something
like:

<mbean descriptor="org.apache.geronimo.security.Server"
       name="geronimo.security:type=SecurityRealm"
       interface="org.apache.geronimo.security.ServerMBean"/>
Where ServerMBean is generated by xdoclet or written by hand.  You get
something readable to look at, if you so desired.  There's no extra 
coding,
so there's no mistakes in generating the GeronimoMBeanInfo.
This looks more or less reasonable to me, although my impression is 
that it is a way to deploy a standard mbean as a geronimo mbean.  If 
so, we don't need the descriptor: we can write something in the service 
deployer that, for a standard mbean, generates GeronimoMBeanInfo from 
that interface.  This is basically what I was suggesting about adding 
more conveniences to GeronimoMBeanInfo setup.

So, maybe we agree on this?
thanks
david jencks

Regards,
Alan

----------------------------------------------------------------
      Visit our Internet site at http://www.reuters.com
Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit <http://www.reuters.com/messaging>
Any views expressed in this message are those of  the  individual 
sender,
except  where  the sender specifically states them to be the views of 
The
Reuters Group.