Juha is in Majorca.
He said he wanted to convert the XMBean to XML schema,
but he had stopped working on it for now.
This is 1.2 I think?
He has a branch called juhasstuff, but it doesn't look
to contain any XMBean changes.
yeah I want to convert to XSD for 1.2. Nothing prevents you adding your own DTD's even to that version if you want to (meaning we don't need to restrict the xml metadata based builder to a single document schema -- and in fact we don't do that even today).
Default values (the spec 'default' field) should be part of the attribute interceptor, and the 'value' descriptor field initialized with 'default' at ModelMBeanXXXInfo creation.
My original question didn't get answered clearly;-) Can I change the 1.0 implementation or should I implement the 1.2 stuff?
With regards to the default values, I can think of a couple of ways to get them into the target object:
1. Rearrange the order of interceptor creation so that the attribute interceptor can set the target object values in its constructor
2. Introduce lifecycle events in the mbean interceptors like those in the ejb interceptors.
I think (2) is more compatible with the proposed stateless interceptors. Any comments?
I can't answer your first question.
For the second part, defaultValue is only for the
getAttribute() method where the descriptor has no value
I think what you are talking about is an initial value
which could potentially invoke the setter.
The setAttribute really needs to go through the
whole stack after it is constructed. You never know
what else might be in there looking for it,
No you can't change the 1.0 version, that just forces everyone to change their XML files for no good reason.
You can extend the builder implementation for your own additional tags if you want, and introduce it under another schema name.
Adrian is correct on the default field value for descriptors, it is set on the metadata on creation and then returned by the interceptor when needed.
I don't understand the case where you need default values beyond this behavior.
Lifecycle: do you mean method callbacks or actual events (notifications) sent by the interceptor? The shared interceptor is an MBean and implements the MBeanRegistration interface (I can't remember if it actually does, but it should). I don't think adding additional method callbacks beyond this is needed. Notifications from the registration callback methods we should do if they're required.
--default or initial values.
OK, I just looked at the book;-) and think I should be using "default" rather than "value". What I want to do is use the default descriptor for an attribute to set an initial value for the attribute, in the managed object itself (if it has a setter method). I don't know exactly how this fits in the philosophy of jmx, but it would be extremely handy. The reason is that the xml description for the mbean can then include its entire initial state. I plan to modify ServiceConfigurator so it can make an xmbean based on xml being right there in the *-service.xml file, rather than in a separate file referenced by a url. This will enable one-stop mbeanification of any object just by including the appropriate xml in a *-service.xml file. I plan to use this first to make ConnectionFactoryLoaders directly into mbeans, with the attribute values set directly from the xmbean xml (embedded in a dynamically created service-xml format document). This xml will be generated from the ra.xml from the resource adapter and configuration info for the attribute values.
It looks like I can get the (default) attribute values sent to the managed object when the interceptor stack instance is being set up, if I reorder the setup a bit. They will not go through the persistence interceptor, since that won't be in the stack yet. For my purposes at the moment that doesn't matter.
I don't think this usage conflicts with the description of "default" as the value "returned if the value field has not been set and the attribute as not been associated with an operation that would retrieve the value from the managed resource". If the attribute does have a getter, we could still use the default to set the initial value.
I think that when we make the ejb container interceptors into mbean interceptors we will need lifecycle events, just as the ejb interceptors have now. Sending the initial value to the managed object would certainly be more appropriate in an init or start method, but I can wait.
The xmbean dtd modification I would like to make is completely backward compatible, namely to allow and optional default-value descriptor element with the other descriptors. I think including a constructor name is a bit silly, but don't need to change it. So I would like to change the dtd in this minor way, and later work on getting the 1.2 dtd to be a schema and better structured.
> It looks like I can get the (default) attribute
> values sent to the managed object when the
> interceptor stack instance is being set up, if I
> reorder the setup a bit. They will not go through
> the persistence interceptor, since that won't be in
> the stack yet. For my purposes at the moment that
> doesn't matter.
Ok I see what you mean. You should really work this on the dev branch that reimplements the interceptors but it is in such a state that it's not really doable and I can't finish it for at least another 4 weeks due to trainings.
So go ahead, though be aware it may break and you might need to rework it later (or build good test cases for it so it will be easy to merge with the upcoming changes).
> I think that when we make the ejb container
> interceptors into mbean interceptors we will need
> lifecycle events, just as the ejb interceptors have
> now. Sending the initial value to the managed object
> would certainly be more appropriate in an init or
> start method, but I can wait.
yeah that will be in the dev branch.
> --xmbean dtd
> The xmbean dtd modification I would like to make is
> completely backward compatible, namely to allow and
> optional default-value descriptor element with the
> other descriptors. I think including a constructor
> name is a bit silly, but don't need to change it. So
> I would like to change the dtd in this minor way, and
> later work on getting the 1.2 dtd to be a schema and
> better structured.
adding new optional tags to the existing schema is ok
I've been working with cvs head. The attribute interceptor change is all in an override to insertLast, so merging should be easy, and it will need to be rewritten to use lifecycle events anyway.