POJO Schema parsing

[adrian.brock]

Let me know if you'd rather I raise JIRA tasks for these:

I've got some corrections to do to fix misconceptions and some "lost in translation"
usage of the metadata, but that is less important at the moment and my problem :-)

The main problems are:

1) If you don't specify a schema on the xml document you get lots of warnings
and a NULL object back. I would expect this to be a hard error if you pass in
an xml document that has no relevence to the schema binding.

2) Even though I've told it the schema with the schema binding (including the real local
location) this has no affect on the entity resolver:

4625 WARN [EntityResolver] Entity is not registered, publicId=null systemId=file:/home/ejort/jboss-head/workspace/kernel/src/resources/xml-test/org/jboss/test/kern
el/xml/test/pojo-deployer_1_0.xsd

It wants to load it from the system id (because there is no public id?) and it believes the
system id should be the same place as the xml file.

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

3) Bill added the ability to use streams in the parsing, I think because he wants
to pass in fragments. There is no corresponding api for the schema binding.

[aloubyansky]

I would like to see what you are doing. Could you post/send me the code? What kind of warnings?

[aloubyansky]

I just tried commenting out schema location in testGenericBeanFactory.xml

<!--
<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">
-->
<deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns="urn:jboss:xml-deployer">

It worked fine.

Warnings like this

 WARN [AttributesHandler] Attribute is not bound: element owner {urn:jboss:xml-deployer}deployment, attribute {http://www.w3.org/2001/XMLSchema-instance}schemaLocation

can be ignored. In fact, there is a property that doesn't include schema instance attributes into Attributes object. Setting it will remove these warnings.

I don't understand why NULL is returned. Passing SchemaBinding with handlers should do the job.

[aloubyansky]

2) Even though I've told it the schema with the schema binding (including the real local
location) this has no affect on the entity resolver:

4625 WARN [EntityResolver] Entity is not registered, publicId=null systemId=file:/home/ejort/jboss-head/workspace/kernel/src/resources/xml-test/org/jboss/test/kern
el/xml/test/pojo-deployer_1_0.xsd

This is logged by the

package org.jboss.util.xml;
public class JBossEntityResolver implements EntityResolver
{
 private static final Logger log = Logger.getLogger(EntityResolver.class);

From getLocalEntityName method. Since this schema is not registered there yet.

[adrian.brock]

I would like to see what you are doing. Could you post/send me the code? What kind of warnings?

I'll try to reproduce the problem in the testsuite. I was definitley getting a null object
back without the schema.

The issues with the warnings is not so much that they are appear (though it is
undue noise), more that when the schema has a real url (http://jboss.com/etc)
it will be doing network requests that might not work behind a firewall.

I'll start a new thread on schema usage (what Scott and I discussed before)
when I've looked a bit deeper into your current implementation - so I have
a more informed opinion :-)

[adrian.brock]

I've modified the SimpleCollection test to reproduce the Null problem.

[aloubyansky]

That's because of this change

<?xml version="1.0" encoding="UTF-8"?>
 -<deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 +<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">
 + xmlns="urn:jboss:xml-deployer"-->
 <bean name="SimpleBean1"
 class="org.jboss.test.xml.pojoserver.SimpleBeanImpl">
 <property name="aList">

Now the qualified name of the deployment element is QName("deployment"), not QName("urn:jboss:xml-deployer", "deployment") which is used in the schema binding. So, it is just not recognized.

BTW, currently, in the XSD all attributes belong to the default/empty namespace, not the urn:jboss:xml-deployer.

[adrian.brock]

My question was why does it return null rather than throwing an exception?

I know the reason is the namespace is missing/mismatched,
but a user won't :-)

JBossXB has a better chance at giving a reasonable error message than anything
I could do:

 Unmarshaller unmarshaller = UnmarshallerFactory.newInstance().newUnmarshaller();
 KernelDeployment deployment = (KernelDeployment) unmarshaller.unmarshal(url.toString(), schemaBinding);
 if (deployment == null)
 throw new DeploymentException("Unable to parse " + url + " it is not well formed.");

[aloubyansky]

Yes, maybe. I was thinking about this: throwing an exception when met an element/attribute that is not bound or just ignoring. Perhaps, there should be a property for this.

[adrian.brock]

It looks like the new parsing is going to cope with everything I throw at it
for the pojo parsing. Well done Alex.

The outstanding issues are:
1) Using schema annotations to define the parsing
2) The ANY parsing
3) Making the map definition less verbose.

Up-to-date progress here:
http://jira.jboss.com/jira/browse/JBMICROCONT-32

P.S. I still need to do a lot more testing to complete the parser, but I don't see
anything to do that is going to require a pattern that I haven't already
successfully used.

[adrian.brock]

I'd appreciate any insight on the Map/Entry parsing:
http://jira.jboss.com/jira/browse/JBMICROCONT-36

Is it possible for the parser to understand this or is this just something that
isn't guaranteed to work with xml?

<map>
 <key/><value/>
 <key/><value/>
 <key/><value/>
</map>

[adrian.brock]

Actually, it looks like I spoke too soon.
e.g. What is a good format for defining a map that has non-trivial
objects in the key as well as the value.

<map>
 <entry>
 <key><set><value>1</set></key>
 <value>collection><value>2</value></collection></value>
 </entry>
</map>

Perhaps this is such a stupid use case we shouldn't support it, and just
incorporate the key into the entry
i.e. only support trivial keys:

<map>
 <entry key="1" class="java.lang.Integer">
 <collection><value>2</value></collection>
 </entry>
</map>

I think this would also solves the parsing problem, mentioned above.

[starksm64]

I think incorporating the key into the entry as an attribute is too limiting. In terms of the difference between:

<map>
 <entry>
 <key><set><value>1</set></key>
 <value>collection><value>2</value></collection></value>
 </entry>
</map>

and:

<map>
 <key><set><value>1</set></key>
 <value>collection><value>2</value></collection></value>
</map>

I don't think its an issue of the parser not handling it, but rather having to introduce an uneccessary compilication in the handling of the parser stack state to effectively combine the key and value elements into a composite context at the object factory layer. Alexey could better speak to whether this is an actual complication in the current object factory though. However, since the entry element really does not translate to a single object as far as the java.util.Map api is concerned, the pair does have to be dealt with, and I don't see that its much easier to keep track of this by adding an entry element since the pair container can just as easily be created at the start of the key element as a containing entry element.

I browsed through the jaxb2.0 spec again, and they don't support map type of collections. Only arrays and list type of collections are supported so this is a construct that won't be supported other than by proprietary bindings.

[adrian.brock]

The issue is the verbosity, not just the parsing.

Perhaps I could support both types of map descriptions?

With the short form probably being used the most often?

<entry key="AKEY">AVALUE</entry>

Essentially, all I'm doing is creating a temporary "entry"

entry.key = new StringValueMetaData("AKEY");
entry.value = new StringValueMetaData("AVALUE");

which is then used at the end of element to do

mapMetadata.put(entry.key, entry.value)

I'm not sure how this would tranlate to schema annotations?
I'll wait to see what Alex says, before doing any more on this.

[starksm64]

For that usecase I would argue that there should be a properties mapping:

<properties>
 <entry key="key1">value1</entry>
 <entry key="key2">value2</entry>
</properties>

because this is a universal construct that I could define a reusable xsd fragment for the content model and annotation for the binding.