1 2 3 Previous Next 42 Replies Latest reply on Mar 23, 2005 5:28 AM by Alexey Loubyansky

    Kernel XML format

    Adrian Brock Master

      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.

        • 1. Re: Kernel XML format
          Adrian Brock Master

          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 Master

            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
              Scott Stark Master

              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
                Scott Stark Master

                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
                  Scott Stark Master

                  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 Andreadis Master

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

                    • 7. Re: Kernel XML format
                      Juha Lindfors Master

                      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 Lindfors Master

                        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 Master

                          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 Master

                             

                            "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 Master

                               

                              "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 Master

                                 

                                "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 Master

                                   

                                  "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
                                    Scott Stark Master

                                    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.

                                    1 2 3 Previous Next