inconsistency in xmbean.dtd?

[davidjencks]

I think perhaps the attribute persistPolicy should have the same choices as the mbean persistPolicy?

<!ATTLIST mbean persistPolicy
(Never | OnUpdate | NoMoreOftenThan | OnTimer) "Never"
...
<!ATTLIST attribute persistPolicy CDATA #IMPLIED
...

[davidjencks]

Also, how about making attribute's access and operation's impact into attributes with a choice list rather than elements?

[juha]

> I think perhaps the attribute persistPolicy should have
> the same choices as the mbean persistPolicy?

ATTLIST mbean persistPolicy (Never | OnUpdate | NoMoreOftenThan | OnTimer) "Never"

ATTLIST attribute persistPolicy CDATA #IMPLIED

Adding the attribute choices to attribute level tags will only work if DTD allows you to provide the choice list without providing a default value ("Never"). This is because there is no way for the parser to know whether the default value was intended by the doc creator to overwrite the mbean level policy or not (which the attribute level policy should do).

So for example, if you set "OnTimer" at MBean level and have a default value of "Never" at attribute level none of the attributes will ever be persisted as their policies overwrite the mbean level policy.

I don't know if there's an easy fix for this in DTD. If there is, go ahead and fix it. Otherwise it may be better to leave it as is and see if the XML Schema is able to deal with it better.

-- Juha

[juha]

oh and btw,

if you do change the DTD, please create a new DTD file 'JBossMX_XMBean_1_0.dtd' that matches the JBossMX version. I want to keep the XMBean.dtd that matches the definition given in the book.

[davidjencks]

I think the xml spec allows #IMPLIED with enumerated attribute types:

[52] AttlistDecl ::= '<!ATTLIST' S Name AttDef* S? '>'
[53] AttDef ::= S Name S AttType S DefaultDecl

[54] AttType ::= StringType | TokenizedType | EnumeratedType

[57] EnumeratedType ::= NotationType | Enumeration

[59] Enumeration ::= '(' S? Nmtoken (S? '|' S? Nmtoken)* S? ')' [VC: Enumeration]

[60] DefaultDecl ::= '#REQUIRED' | '#IMPLIED'
| (('#FIXED' S)? AttValue) [VC: Required Attribute]
[VC: Attribute Default Legal]
[WFC: No < in Attribute Values]
[VC: Fixed Attribute Default]



I will experiment with this further and if it seems to work (i.e. docs can be validated using say xerces with the modified dtd) add a modified renamed dtd.

I take it JBossMX is using a versioning scheme independent from jboss? Will this create less confusion than synchronizing versions (starting with JBossMX 3)?

[juha]

> I take it JBossMX is using a versioning scheme
> independent from jboss? Will this create less
> confusion than synchronizing versions (starting with
> JBossMX 3)?

yes, since we can do releases in between JBoss versions for the standalone JBossMX.

-- Juha

[juha]

David,

after giving this a bit more thought

We shouldn't have the MBean descriptors as attributes for the management interface elements. The names supported by the Model MBean implementation is not a fixed set so we might wound up with a long list of attributes where the descriptor value can only be defined by a single string field.

Instead I propose an addition of a element that can be nested in all of the elements (mbean, constructor, notification, operation and attribute). This allows for nested elements for specific descriptors (such as persistPolicy) and additional descriptors not declared by the DTD. Additional descriptors would not need that many changes in the parsing code (or actually, just replace the current parsing code with JAXB).

For example:

<mbean>

 <attribute name= .... >
 <descriptors>

 <!-- this is predefined descriptor with a fixed value set -->
 <persistence policy="Never"/>

 <!-- this is an impl. specific descriptor -->
 <descriptor name="LockMBean" value="true"/>

 <!-- some predefined descriptors would benefit from declaring their values
 as nested elements instead of single strings.
 -->
 <presentationString>
 <layout type="grid"/>
 <table>
 <td ...
 </table>
 </presentationString>

 </descriptors>
 </attribute>

 <notification type = ....>
 <descriptors>
 ...
 </descriptors>
 </notification>

</mbean>

and so forth.. we should move descriptors away from attributes and into more specific elements. What do you think?

-- Juha

[davidjencks]

I think this is a good idea.

Will it allow us to define e.g. persistence location/name for attributes separate from the whole mbean? Is this a good or bad thing?

[juha]

> Will it allow us to define e.g. persistence
> location/name for attributes separate from the whole
> mbean?

Yes, if the underlying model mbean implementation supports persistLocation and persistName at the attribute level.

-- Juha

[davidjencks]

Ok I have a modified dtd (attached) and an xdoclet template that generates dd's that match it (sample and output also attached). Before I start messing with the xmbean perhaps some review is in order...

Following the jboss model I think the dtd should be in src/resources/metadata/. I have spent quite a while looking in cvs for the original xmbean.dtd and haven't found it.

[juha]

> Ok I have a modified dtd (attached) and an xdoclet
> template that generates dd's that match it (sample
> and output also attached).

looks good...

notifications should allow the optional descriptions element as well.


> Following the jboss model I think the dtd should be
> in src/resources/metadata/.

only if the process of syncing dtds from cvs to website is made less invisible (i have no clue how it works now). I don't want to manually update these.

> I have spent quite a
> while looking in cvs for the original xmbean.dtd and
> haven't found it.

this is purely a documentation issue. A doco pointing to an URL on a website will always be the preferred way to locate a DTD.

-- Juha

[juha]

David,

with regards to changes to XMLMetaData:

what the XMLMetaData should do is pick the PI from the xml given to it, and then choose the parser implementation according to the DTD.

In code something similar to this:

 SAXBuilder builder = new SAXBuilder("org.apache.crimson.parser.XMLReaderImpl", validate);

 Document doc = builder.build(url);
 DocType type = doc.getDocType();

 String docURL = type.getSystemID();

 if (docURL == null)
 docURL = type.getPublicID();

 // known document definitions
 if (docURL.endsWith(MBEAN_LOADER_DTD_1_0))
 return parseMBeanLoader10(doc);
 else if (docURL == null)
 // defaults if no DTD specified
 return parseMBeanLoader10(doc);

There's bound to be several different schemas from which the MBean metadata can be created (for example the schemas pushed by DMTF, our evolving schema and the old ones we want to keep supporting) and trying to support all of that in one XMLMetaData is just too messy.

So here's a TODO for you, or anyone else who's interested (might even do it myself).

Also, wrt the current 1.0 DTD -- another addition I forgot to mention is an element that allows you to declare the stack of interceptors the XMBean then configures in front of itself when it is registered (again, can do this with the descriptors, and I'm starting to think it might turn to be useful to allow configuring separate interceptor stacks for operations and attributes ).

So in ModelBase preRegister, getDescriptor(blah blah) and config the interceptors based on the values found there.

That's another TODO for someone.

-- Juha

[davidjencks]

--supporting multiple dtds for xmbean. Are you really sure this is something we should be spending time on now? Also, there is the possibility of, rather than supporting lots of other xml formats with parsers, instead transforming them using e.g. xslt into our format and then deploying them. Personally I'd rather get our stuff working well before we try to be universal.

btw for main jboss deployment I am thinking about using this approach -- transform everything (such as ejb-jar.xml + jboss specific stuff) into mbean config, then deploy that as mbeans.

--interceptor list in xml -- this is a wonderful idea.

[juha]

> --supporting multiple dtds for xmbean. Are you
> really sure this is something we should be spending
> time on now?

I'm really only talking about the hooks for this in XMLMetaData (basically the code I snipped as is) so that when someone comes in with a CIM schema they can just plugin their own class that does the parsing to JMX metadata. And instead of breaking backwards compatibility as our own DTD changes, just provide a new subclass of the existing that is used when there's a schema match.

> Also, there is the possibility of,
> rather than supporting lots of other xml formats with
> parsers, instead transforming them using e.g. xslt
> into our format and then deploying them.

XSLT is sort of heavy. and really not any easier to write. Currently, both work equally well, but given that if JAXB etc. work as advertised then XSLT might not be worth the trouble (just generate the new parser with JAXB).

> Personally
> I'd rather get our stuff working well before we try
> to be universal.

Right... just saying give hooks to people who want to provide their own schema, and make sure we don't break existing ones everytime there is a change to the current top-of-the-line schema of our own.

I did something similar to an ApplicationLoaderMBean, it's not alot of work, I'll add it to XMLMetaData when I get around to those parts again.


-- Juha