#246 ServerCreator had hard coded model bean

[Paul W. Ward]

ServerCreator was not checking the system properties
for the required model mbean class.

[Paul W. Ward]

cvs diff -u

[Juha Lindfors]

Logged In: YES
user_id=175239

This is a slightly dangerous assumption, as the spec does
not mandate constructor <init>(Object, String) constructor
for model mbean implementations.

However, the patch does work if that constructor is
provided. Probably not the best long term solution though.
Leaving it up to David to decide whether to apply it or not.
The descriptor explicitly declares xmbean implementation as
far as I can tell so from that point of view it is working
correctly.

Also to notice that the use of system wide properties should
be kept at minimum as it is only a temporary solution to
configuring mbean servers. System wide configuration is not
ideal when more than one mbean server exists in the JVM.

-- Juha

[Paul W. Ward]

Logged In: YES
user_id=568636

Not sure what your comment about the constructor means.
The diff I submitted requires no constructor changes/additions.

The only thing I did was change from a hard coded model
mbean class name to using the system property that was
already created by the jmx project.

I agree that having system properties cross from the jmx
project to the server project is probably not the best idea, but
since I provided the same default that was being hard coded
in the first place, the most like failure from this is that the
server reverting to it's original implementation.

[Paul W. Ward]

Logged In: YES
user_id=568636

Are you sure that the descriptor allows you to specify the
xmbean implementation? If so, I'd definitely like to know how
since it would eliminate a couple problems I'm having with the
persistence manager I'm creating.

[Juha Lindfors]

Logged In: YES
user_id=175239

> Not sure what your comment about the constructor means.

I mean this line:

//now create the mbean
ObjectInstance instance =
server.createMBean(XMBEAN_CODE,
mbeanName,
loaderName,
new Object[] {resource,
xmbeanddUrl},
new String[]
{Object.class.getName(), URL.class.getName()});

Which assumes that a specific constructor exists for the
Model MBean implementation. The spec however only mandates
<init>() and <init>(ModelMBeanInfo) constructors.

> Are you sure that the descriptor allows you to specify the
xmbean implementation?

No, I mean the descriptor assumes that the *ModelMBean
implementation* equals to XMBean (which is why I think the
tag name also says xmbean though I took only an extremely
brief glance at it).

So therefore I think it is safe to say that the current
implementation explicitly mandates a specific Model MBean
implementation (XMBean). I don't mind if it allows others,
but if it does, it should somehow deal with the issue with
the constructors on other Model MBean implementations (and
therefore I'm leaving this up to David to decide). I think
it is also ok for now to say that any custom MMB
implementation must have the constructor that is currently
required for it to work.

[David Jencks]

Logged In: YES
user_id=60525

I put this in specifically to support use of the jboss
xmbean in a simple way in our existing *-service.xml files,
while fitting into the dependency management structure. It
definitely relies on the special constructor for the jboss
xmbean.

I think if you want to use a different model mbean you can
do so by specifying that model mbean class as the mbean
class and supplying the mbean info. You may have to do some
other work to be able to convert xml to an mbean info object.

Could you explain what you are trying to do?

thanks
david