General schema parsing

[adrian.brock]

When I discussed this with Scott (on the pojoserver thread)
we decided we wanted to go down the road of allowing ANY inside the metadata.

There is an xml test for this in the testsuite, but I don't see it getting tested?
http://cvs.sourceforge.net/viewcvs.py/jboss/jbosstest/src/resources/xml/pojoserver/test1-ejb-deployment.xml?rev=1.1&view=auto

What we are really looking for is the ability to provide some kind of registry or
self bootstrap of
schema public id -> SchemaBinding

e.g. If I do

<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="urn:jboss:xml-deployer xml-deployer_1_0.xsd"
 xmlns="urn:jboss:xml-deployer">

i.e. I can shove the xml at an unmarshaller and expect it to work out that the
urn:jboss:xml-deployer:deployment needs to go through
org.jboss.kernel.plugins.deployment.xml.PojoSchemaBinding

then when it hits

<bean name="EJBContainerConfig" class="org.jboss.ejb.Container">
 <property name="Config">
 <ejb:ejb-container xmlns="urn:jboss:testejb-ns1">

it knows it needs to go a different mapping
urn:jboss:testejb-ns1:ejbcontainer ->
org.jboss.ejb.metadata.EJBContainerSchemaBinding

Since the number of these schema bindings is indeterminate (users could
potentially write their own - certainly each JBoss module will)
and "hot deployable" I don't want to hardwire these other namespaces into the pojo schemabinding.

[adrian.brock]

Similarly, I actually want to simplify some of the urn:jboss:xml-deployer:bean
configs with "use case" configs. They still produce BeanMetaDatas but the
xml -> BeanMetaData is more hardwired (see the pojo server thread)

<beanfactory xmlns="urn:jboss:genericfactory" class="x.y.z">
etc.
rather than the longwinded
<bean class="org.jboss.bean.plugins.GenericBeanFactory">
<property name="Bean">x.y.z</property>
etc.

or even something more simple like:
<queue xmlns="urn:jbossmq:queue" name="testQueue"/>

[adrian.brock]

I suggested that these mappings be put in the xsd files themselves using
some kind of "processing instruction"???

But I think you rejected that idea!

So I guess the alternative would be to have some registry of schemas that
un/marshaller instances can use?

[starksm64]

The only factory binding info you can put into the xsd schema is that for the current namespace. You can't specify the bindings for the extension points for which you don't know the schema or even the namespace.

For a given hybrid document instance, all of the xsd to namespace mappings should be defined so I think the jbossxb layer should have all the info it needs to figure out the correct unmarshaller. In your example, the xsd for the urn:jboss:testejb-ns1 namespace should define this.

[adrian.brock]

all of the xsd to namespace mappings should be defined

Do you mean this processing already exists or that it should exist?

[starksm64]

An example of specifying binding info in the schema from the jaxb2.0 spec draft is:

<xs:complexType name="USAddress">
 <xs:annotation>
 <xs:appinfo>
 <jaxb:class name="MyAddress" />
 </xs:appinfo>
 </xs:annotation>
 <xs:sequence>...</xs:sequence>
 <xs:attribute name="country" type="xs:string"/>
</xs:complexType>

The xs:annotation/xs:appinfo/jabx:class is specifying what class to use. We should be able to define similar jbossxb statements.

[starksm64]

Each unqiue namespace should have a binding for its associated xsd either coming from annotations in the xsd, or indirectly as an external binding instructions document referenced by the xsd. I'm pretty sure this is allowed in jaxb, but certainly can be supported by jbossxb. So I may not want to hard-code the binding instructions in the xsd:

<xs:complexType name="USAddress">
 <xs:annotation>
 <xs:appinfo>
 <jbossxb:binding-uri location="META-INF/jbossxb-info.xml" />
 </xs:appinfo>
 </xs:annotation>
 <xs:sequence>...</xs:sequence>
 <xs:attribute name="country" type="xs:string"/>
</xs:complexType>

[aloubyansky]

When I discussed this with Scott (on the pojoserver thread)
we decided we wanted to go down the road of allowing ANY inside the metadata.

There is an xml test for this in the testsuite, but I don't see it getting tested?
http://cvs.sourceforge.net/viewcvs.py/jboss/jbosstest/src/resources/xml/pojoserver/test1-ejb-deployment.xml?rev=1.1&view=auto

Right, I haven't looked at it yet.

What we are really looking for is the ability to provide some kind of registry or
self bootstrap of
schema public id -> SchemaBinding

Yes, I know. There are just too many things to work on here. Before looking at "the ability to provide some kind of registry", I would like to have "good enough" binding working for at least one schema (this includes verious customizations). Once we have it, I think, some-kind-of-registry (or even runtime binding instead) should not be a big problem.
However, if this is a priority right now, let me know.

[aloubyansky]

I suggested that these mappings be put in the xsd files themselves using
some kind of "processing instruction"???

But I think you rejected that idea!

I have always being talking about bindings in XSD in the form of annotations. Processing instructions in XML are also an option. But XSD annotations are prefferable were possible.
Also, I agree with Scott about the current namespace binding in his reply to you.

[aloubyansky]

Commenting on Scott's examples of binding info in XSD.
This is my next step. I started to look into this this morning. First, I would like to address jaxb:class, jaxb:property, etc. Using actually jaxb namespace and as it is defined in the latest jaxb2.0 edr. And later (when needed), bindings in external file.

[adrian.brock]

Ok, the ANY/use case xml would be "a nice to have" to for the GenericBeanFactory.
Bill is already using it to deploy advice factories via the MC.

I'll get on with checking/fixing/completing your tests/assertions.

P.S. You didn't answer my question, do you want bug reports here or in JIRA?

[aloubyansky]

Sorry. Bug reports belong in jira.

[aloubyansky]

I'll probably need to patch xerces-2.6.2 to start using annotations.
http://issues.apache.org/jira/browse/XERCESJ-968

[adrian.brock]

Do you have a JIRA task for this work such that I can add dependencies upon?
e.g. http://jira.jboss.com/jira/browse/JBMICROCONT-33

[starksm64]

I have added another example to the existing head testsuite/xml tests that illustrates a complete deployment document that involves 3 namespaces/schemas for a prototype dynamic login configuration service. The deployment document is the src/resources/testObjFactory.xml which is a simple jboss-4.0.x style mbean service descriptor. The namespace/xsd/object mappings are:

ns#1: urn:jboss:mbean-service
xsd#1: mbean-service_1_0.xsd
objects#1: org.jboss.test.xml.mbeanserver.{Services,MBeanData}

ns#2: urn:jboss:login-config2
xsd#2: login-config2.xsd
objects#2: org.jboss.test.xml.mbeanserver.{PolicyConfig,AuthenticationInfo,AppConfigurationEntryHolder,ModuleOption}

ns#3: urn:jboss:user-roles
xsd#3: user-roles.xsd
objects#3: org.jboss.test.xml.mbeanserver.{Users,Users.User}

A number of these objects do not have java bean setters. The constructor is the only way to pass in the read-only data in this case. Many use collection classes.

I would like to iterate on the schemas/object model to a point where the object graph can be completely driven by the schema binding. I also want to create a pojo server version which excercies the dependcies.