Kernel XML format

[adrian.brock]

Although it relatively simple to write your own xml->kernel metadata deployer

I'm interested in any suggestions to make the xml less verbose and more
intuitive.

This xml format will be used by the BeanDeployer
the basic POJO -> jboss deployer
similar to SARDeployer
that does MBean -> jboss deployer

You can find examples in jboss-head
kernel/src/resources/xml-test/org/jboss/test/kernel/xml/test

Speak now before we finalize the base format.

[adrian.brock]

Known features still not complete (or at least properly tested which
is the same thing in my book :-) are:

1) Specifying types on values, e.g. the elements of a collection
http://jira.jboss.com/jira/browse/JBMICROCONT-29

2) Beans as values
http://jira.jboss.com/jira/browse/JBMICROCONT-28

3) Annotation overrides
http://jira.jboss.com/jira/browse/JBMICROCONT-18

[adrian.brock]

As discussed on other threads, I also want to have "use case"
configurations that simplify the more long winded bean descriptions.
This will probably require some pluggable xml parsing using namespaces?

e.g. instead of

<bean name="MyClassLoader" bean="java.net.URLClassLoader">
 <constructor>
 <parameter>someURL</parameter>
 </constructor>
</bean>

you could have the equivalent:

<urlclassloader url="someURL"/>

[starksm64]

Does this support nested java beans, or is that the Beans as values item? Also, what about custom object factories based on namespaces? This is an example from head I'm working on for the legacy service descritpor:

<!-- Tell JBossXB about the namespace to factory mappings in this doc -->
<?jbossxb ns="urn:schema:ns1:jbossxb"
 factory="org.jboss.test.jmx.complexattrs.JavaBeanObjectModelFactory"?>
...

 <!-- Test the jbossxb attribute data type syntax -->
 <mbean code="org.jboss.test.jmx.complexattrs.ComplexAttrTests"
 name="test:name=ComplexAttrTests,case=#2">
 <attribute name="Bean1"
 attributeClass="org.jboss.test.jmx.complexattrs.JavaBean1"
 serialDataType="jbossxb"
 xmlns:ns1="urn:schema:ns1:jbossxb">
 <ns1:javabean1>
 <property name="bindAddress">127.0.0.1</property>
 <property name="someDate">Sun Jan 2 23:26:49 PST 2005</property>
 <property name="props">
 prop1=value1
 prop2=value2
 prop3=${prop3.systemProperty}
 </property>
 <property name="names">name1,name2,name3</property>
 <property name="someURL">http://www.jboss.org</property>
 </ns1:javabean1>
 </attribute>
...

[starksm64]

Also, why not just borrow from the spring property model:

<!--
 Bean definitions can have zero or more properties.
 Property elements correspond to JavaBean setter methods exposed
 by the bean classes. Spring supports primitives, references to other
 beans in the same or related factories, lists, maps and properties.
-->
<!ELEMENT property (description? , (bean | ref | idref | list | set | map | props | value | null))>

<!--
 The property name attribute is the name of the JavaBean property.
 This follows JavaBean conventions: a name of "age" would correspond
 to setAge()/optional getAge() methods.
-->
<!ATTLIST property name CDATA #REQUIRED>

<!--
 Defines a reference to another bean in this factory or an external
 factory (parent or included factory).
-->
<!ELEMENT ref EMPTY>

<!--
 References must specify a name of the target bean.
 The "bean" attribute can reference any name from any bean in the context,
 to be checked at runtime.
 Local references, using the "local" attribute, have to use bean ids;
 they can be checked by this DTD, thus should be preferred for references
 within the same bean factory XML file.
-->
<!ATTLIST ref bean CDATA #IMPLIED>

<!ATTLIST ref local IDREF #IMPLIED>

<!ATTLIST ref parent CDATA #IMPLIED>

<!--
 Defines a string property value, which must also be the id of another
 bean in this factory or an external factory (parent or included factory).
 While a regular 'value' element could instead be used for the same effect,
 using idref in this case allows validation of local bean ids by the xml
 parser, and name completion by helper tools.
-->
<!ELEMENT idref EMPTY>

<!--
 ID refs must specify a name of the target bean.
 The "bean" attribute can reference any name from any bean in the context,
 potentially to be checked at runtime by bean factory implementations.
 Local references, using the "local" attribute, have to use bean ids;
 they can be checked by this DTD, thus should be preferred for references
 within the same bean factory XML file.
-->
<!ATTLIST idref bean CDATA #IMPLIED>

<!ATTLIST idref local IDREF #IMPLIED>

<!--
 A list can contain multiple inner bean, ref, collection, or value elements.
 Java lists are untyped, pending generics support in Java 1.5,
 although references will be strongly typed.
 A list can also map to an array type. The necessary conversion
 is automatically performed by the BeanFactory.
-->
<!ELEMENT list ((bean | ref | idref | list | set | map | props | value | null)*)>

<!--
 A set can contain multiple inner bean, ref, collection, or value elements.
 Java sets are untyped, pending generics support in Java 1.5,
 although references will be strongly typed.
-->
<!ELEMENT set ((bean | ref | idref | list | set | map | props | value | null)*)>

<!--
 A Spring map is a mapping from a string key to object.
 Maps may be empty.
-->
<!ELEMENT map ((entry)*)>

<!--
 A map entry can be an inner bean, ref, collection, or value.
 The name of the property is given by the "key" attribute.
-->
<!ELEMENT entry ((bean | ref | idref | list | set | map | props | value | null))>

<!--
 Each map element must specify its key.
-->
<!ATTLIST entry key CDATA #REQUIRED>

<!--
 Props elements differ from map elements in that values must be strings.
 Props may be empty.
-->
<!ELEMENT props ((prop)*)>

<!--
 Element content is the string value of the property.
 Note that whitespace is trimmed off to avoid unwanted whitespace
 caused by typical XML formatting.
-->
<!ELEMENT prop (#PCDATA)>

<!--
 Each property element must specify its key.
-->
<!ATTLIST prop key CDATA #REQUIRED>

<!--
 Contains a string representation of a property value.
 The property may be a string, or may be converted to the
 required type using the JavaBeans PropertyEditor
 machinery. This makes it possible for application developers
 to write custom PropertyEditor implementations that can
 convert strings to objects.

 Note that this is recommended for simple objects only.
 Configure more complex objects by populating JavaBean
 properties with references to other beans.
-->
<!ELEMENT value (#PCDATA)>

<!--
 Denotes a Java null value. Necessary because an empty "value" tag
 will resolve to an empty String, which will not be resolved to a
 null value unless a special PropertyEditor does so.
-->
<!ELEMENT null (#PCDATA)>

[starksm64]

The schema for the property element should also support an xsd:any extension type so that one is not constrained to simple constructs. For example, I can use mulitple namespaces to introduce custom types that are marshalled with either jbossxb or jaxb:

 <bean name="ComplexPropertyTests"
 bean="org.jboss.test.jmx.complexattrs.ComplexPropertyTests">
 <property name="Bean1"
 xmlns:ns1="urn:schema:ns1:jbossxb">
 <ns1:javabean1>
 <property name="bindAddress">127.0.0.1</property>
 <property name="someDate">Sun Jan 2 23:26:49 PST 2005</property>
 <property name="props">
 prop1=value1
 prop2=value2
 prop3=${prop3.systemProperty}
 </property>
 <property name="names">name1,name2,name3</property>
 <property name="someURL">http://www.jboss.org</property>
 </ns1:javabean1>
 </property>
 <property name="Bean2"
 xmlns:ns2="urn:schema:ns2:jaxb">
 <custom>
 <person>
 <first-name>Java</first-name>
 <last-name>Duke</last-name>
 </person>
 </custom>
 </property>
 </bean>

[dimitris]

Certainly change the 'bean' attribute in the bean element to 'class' :)

[juha]

Not strictly a DTD issue but would be nice to able to "import" classes rather than be forced to use FQN all over the place... that would help a ton.

[juha]

Another bastardization of XML but since this was never designed for humans to write anyway....

As scott says, allow ANY types for things like < properties > and read in the element name as the property's name directly, so

<property name="bindAddress">127.0.0.1</property>
 <property name="someDate">Sun Jan 2 23:26:49 PST 2005</property>
 <property name="names">name1,name2,name3</property>
 <property name="someURL">http://www.jboss.org</property>

becomes....

<properties>
 <BindAddress value="127.0.0.1"/>
 <SomeDate value="Sun Jan 2 23:26:49 PST 2005"/>
 <Names value="name1, name2, name3"/>

... etc ..
</properties>

Reduces a lot of useless redundant words and typing. So similar (same?) to your URLLoader element shortcut.

[bill.burke]

I've used this pattern in AOP to model user metadata...

Only thing is that the metadata becomes invalidatable... Not so important with simple case, but list, map, etc... can be validated. Also, Adrian whats metadata for invoking on a constructor.

[adrian.brock]

Does this support nested java beans, or is that the Beans as values item? Also, what about custom object factories based on namespaces? This is an example from head I'm working on for the legacy service descritpor:

I answered this question before didn't I? In my critique of this approach.

I am constructing the metadata that will construct the bean when dependencies
are satisfied.

If the javabean has no dependencies (e.g. simple config object)
the object could be constructed at xml parse time and inserted into the
metadata as a plain ValueMetaData that just takes any Object reference.

[adrian.brock]

Also, why not just borrow from the spring property model:

I essentially have the same thing? Certainly the underlying metadata model
looks the same.

The differencies I see are:
1) I have not description
2) I have no special element for java.util.Properties
3) I use dependency instead of idref or ref
4) I use name instead of id

It is a trivial exercise to change the element/attribute names in the XML parsing,
the same goes for the bean->class attribute.

[adrian.brock]

Not strictly a DTD issue but would be nice to able to "import" classes rather than be forced to use FQN all over the place... that would help a ton.

I'll have to think about that one. It requires interaction with the classloader
which I definitly don't want to do in the xml parsing (the classloader may not
even exist at that point).

[adrian.brock]

Also, Adrian whats metadata for invoking on a constructor.

See the examples I posted from the tests.
There are four mechanisms:
1) Straight constructor invocation
2) Static factory
3) A factory instance constructed through IOC/Dependency injection
4) GenericBeanFactory (a specialised version of 3)

Actually, I missed one of the TODOs, which is specifying
the classloader to use for a bean's construction:
http://jira.jboss.com/jira/browse/JBMICROCONT-27

[starksm64]

The complexity possible in the nesting of bean properties is not evident from the current testcases, and it did not jump out at me that the java configuration of the jbossxb factory supports this. We should define a schema for the xml deployer's supported document syntax. The question to Alexey is the suggested document model going to be drivable from the schema or the schema + a jbossxb/jaxb metadata document?

Ultimately that is the preferred state of affairs as this let's us get past the current fact that the DTDs are at best approximations of the actual xml parsing done via hand-coded java.