-
15. Re: Kernel XML format
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.
Ok, so assign the associated task to me so I know its supported and I won't have a reason to ask again. -
16. Re: Kernel XML format
"scott.stark@jboss.org" wrote:
Ok, so assign the associated task to me so I know its supported and I won't have a reason to ask again.
I'll need to look at Alex's new Sunday implementation to complete this work,
since I need to have
property/CDATA -> StringValueMetaData
property/dependency -> DependencyValueMetaData
property/collection (etc.) -> AbstractCollectionValueMetaData (etc.)
You are asking for
property/ANY -> AbstractValueMetaData
and delegates the element parsing to this schema -> jbossxb/jaxb notion
The part I don't understand is how the available schemas/parsers are established?
Once I understand this, I can raise the task.
Off-topic:
Judging by the spring dtd I also need
property/null
to differentiate no value from an empty string. -
17. Re: Kernel XML format
You are asking for
property/ANY -> AbstractValueMetaData
and delegates the element parsing to this schema -> jbossxb/jaxb notion
This should NOT just be at the property level.
Since to support the "use case"
deployments we would need something like:
deployment/bean
deployment/ANY
where ANY maps to a "use case" configuration
and allows them to be mixed and match in the same config file. -
-
19. Re: Kernel XML format
You are asking for
property/ANY -> AbstractValueMetaData
and delegates the element parsing to this schema -> jbossxb/jaxb notion
Another issue that jumps out is how to reverse the process.
e.g. Given an MC metadata config how do we identify the marshalling
of these javabeans back into an xml file?
Perhaps I need an XMLAnyValueMetaData that extends AbstractValueMetaData
but also remembers the marshaller/unmarshaller/schema? -
20. Re: Kernel XML format
More on the ValueMetaData, I assume your wanting instead of:
<bean name="ComplexPropertyTests" bean="org.jboss.test.jmx.complexattrs.ComplexPropertyTests"> <property name="Bean1" xmlns:ns1="urn:schema:ns1:jbossxb"> ... </property> <property name="Bean2" xmlns:ns2="urn:schema:ns2:jbossxb"> ... </property> </bean>
somthing like this:<bean name="ComplexPropertyTests" bean="org.jboss.test.jmx.complexattrs.ComplexPropertyTests"> <property name="Bean1" ref="TheBean1" /> <property name="Bean2" ref="TheBean2" /> </bean> <bean name="TheBean1"> <property ... xmlns:ns1="urn:schema:ns1:jbossxb"> ... </property> </bean> <bean name="TheBean2"> <property ... xmlns:ns2="urn:schema:ns2:jbossxb"> ... </property> </bean>
This change does have ramifications on the behavior of the jbossxb object factories because the latter form is throwing away object relationships. -
21. Re: Kernel XML format
This change does have ramifications on the behavior of the jbossxb object factories because the latter form is throwing away object relationships.
I don't understand what you are getting at?
The only reason to name a bean is if you want it in the registry
such that it can be:
1) referenced on external dependencies
2) a shared instance injected across beans
3) invoked using detached invocations on the Bus.
Otherwise, the two approaches should be logically equivalent. -
22. Re: Kernel XML format
Scott and I had a conversation.
We are going to look at generating the ObjectModel from a schema
using JBossXB.
This will need some feedback from Alex. -
23. Re: Kernel XML format
"scott.stark@jboss.org" wrote:
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.
It depends on what API you looked at. For the latest API (sunday package), I would be interested to see a use-case that is not supported."scott.stark@jboss.org" wrote:
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?
The aim is to have as little binding customizations (ideally to not have at all) as possible. This is the responsibility of the default binding rules. The real (e.g. Adrian's) world is full of exceptions.
You could minimize customizations when you write your Java object model by keeping in mind the XML schema the Java model is going to be bound to. I am actually not suggesting this approach and am sure that that's not what you want.
Let's create a real testcase and I'll work on it.
You could create an XML and Java object model and I'll then take care of the binding. -
24. Re: Kernel XML format
"adrian@jboss.org" wrote:
Another issue that jumps out is how to reverse the process.
e.g. Given an MC metadata config how do we identify the marshalling
of these javabeans back into an xml file?
With marshalling metadata. -
25. Re: Kernel XML format
"adrian@jboss.org" wrote:
Scott and I had a conversation.
We are going to look at generating the ObjectModel from a schema
using JBossXB.
This will need some feedback from Alex.
So, it looks like the approach when an XML schema drives the Java object model development. I think, Anil is working on Java object model generation based on XML schema. -
26. Re: Kernel XML format
Ok, so what I would like to see is that Adrian, myself and others provide as freakishly complex as needed xml documents and the associated object model as content that goes into the xml binding testsuite. We need to evolve the associated schema and if necessary, external binding metadata to the point that the xml to java binding is being completely driven by configuration outside of the micro-container.
In terms of being completely ignorant of the java object model/schema interaction, yes its true that the previous jaxb like frameworks were so completely tied to single dtd/schemas there were not usable for the object models we need to deal with. I'm open to having to tweak our object model somewhat if needed to be completely schema driven. The key thing is that I'm not willing to be restricted to a jaxb compatibile approach if it requires an object model we are not willing to live with. Additional binding metadata through schema annotations or an external jbossxb is fine to move beyond the jaxb compatible model.
The following issue can aggregate the tasks needed to do this:
http://jira.jboss.com/jira/browse/JBXB-5
I'm working on an xsd schema for the current pojo server xml deployer object model as a starting point. I'll update the JBXB-5 environment with the testsuite resource location for the location of this when done, and any associated external schemas and document instances should be placed there as well. -
27. Re: Kernel XML format
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).
A early binding of the FQN to a classloader, while nice and would be really cool, was not what I was thinking primarily. Even with late binding it would save the developer's fingers.
Rather than having to repeat java.lang.String all over the place (actually this is a bad example, since it's always part of the JDK java.lang package I should never have to specify the package name by default, only if I decide to want to use acme.String from some other package), I'd like to just save myself from typing the same FQN in many locations.
If I mess up the "import" (or "alias" or whatever you call it) and it fails at bind time, then I have one location to correct my mistake, instead of 10.
If some or even all things can be bound at parse time, then that's even better. Some packages, such as java.* and some javax.* packages should be "imported" by default, and allow overwrite with a FQN where necessary (really the same if in java you import with * wildcard and then override type def with FQN). -
28. Re: Kernel XML format
Only thing is that the metadata becomes invalidatable...
Correct.
Now my next suggestion is to allow ANY content from all the way down from the root element...<deployment> <bean name="SimpleBean1" bean="org.jboss.test.kernel.xml.support.SimpleBeanImpl"> <property name="other"><dependency value="SimpleBean2"/></property> </bean> <bean name="SimpleBean2" bean="org.jboss.test.kernel.xml.support.SimpleBeanImpl"> <constructor> <parameter type="java.lang.String">Bean2</parameter> </constructor> </bean> </deployment>
Becomes...<deployment> <Import name = "org.jboss.test.kernel.xml.support.SimpleBeanImpl">SimpleBean</Import> <SimpleBean> <Other ref = "bean2"/> </SimpleBean> <SimpleBean name="bean2"> <Constructor type = "String">Bean2</Constructor> </SimpleBean> </deployment>
Wow.. that's almost readable... now if we could only get rid of those angled brackets....
So what's wrong with writing a custom parser/validator? :-) -
29. Re: Kernel XML format
That is what I am going to try prototyping in the jbossxb testcases. I think it will have to be under a different namespace in order for jbossxb to know what to do with it:
<deployment> <Import name = "org.jboss.test.kernel.xml.support.SimpleBeanImpl">SimpleBean</Import> <x:SimpleBean> <Other ref = "bean2"/> </x:SimpleBean> <x:SimpleBean name="bean2"> <Constructor type = "String">Bean2</Constructor> </x:SimpleBean> </deployment>
but this can actually make the document clearer.