-
1. Re: Kernel XML format
adrian.brock Mar 16, 2005 7:15 PM (in response to 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 -
2. Re: Kernel XML format
adrian.brock Mar 16, 2005 7:19 PM (in response to 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"/>
-
3. Re: Kernel XML format
starksm64 Mar 17, 2005 12:11 AM (in response to 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:
<!-- 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> ...
-
4. Re: Kernel XML format
starksm64 Mar 17, 2005 12:47 AM (in response to adrian.brock)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)>
-
5. Re: Kernel XML format
starksm64 Mar 17, 2005 1:17 AM (in response to adrian.brock)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>
-
6. Re: Kernel XML format
dimitris Mar 17, 2005 4:21 AM (in response to adrian.brock)Certainly change the 'bean' attribute in the bean element to 'class' :)
-
7. Re: Kernel XML format
juha Mar 17, 2005 8:51 AM (in response to 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.
-
8. Re: Kernel XML format
juha Mar 17, 2005 9:06 AM (in response to adrian.brock)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. -
9. Re: Kernel XML format
bill.burke Mar 17, 2005 9:47 AM (in response to adrian.brock)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. -
10. Re: Kernel XML format
adrian.brock Mar 17, 2005 12:12 PM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
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. -
11. Re: Kernel XML format
adrian.brock Mar 17, 2005 12:16 PM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
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. -
12. Re: Kernel XML format
adrian.brock Mar 17, 2005 12:19 PM (in response to adrian.brock)"juha@jboss.org" wrote:
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). -
13. Re: Kernel XML format
adrian.brock Mar 17, 2005 12:25 PM (in response to adrian.brock)"bill.burke@jboss.com" wrote:
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 -
14. Re: Kernel XML format
starksm64 Mar 17, 2005 12:40 PM (in response to adrian.brock)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.