-
1. Re: POJO Schema parsing
I would like to see what you are doing. Could you post/send me the code? What kind of warnings?
-
2. Re: POJO Schema parsing
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 thisWARN [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. -
3. Re: POJO Schema parsing
"adrian@jboss.org" wrote:
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 thepackage 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. -
4. Re: POJO Schema parsing
"alex.loubyansky@jboss.com" wrote:
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 :-) -
-
6. Re: POJO Schema parsing
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. -
7. Re: POJO Schema parsing
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."); -
8. Re: POJO Schema parsing
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.
-
9. Re: POJO Schema parsing
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. -
10. Re: POJO Schema parsing
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>
-
11. Re: POJO Schema parsing
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. -
12. Re: POJO Schema parsing
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. -
13. Re: POJO Schema parsing
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 domapMetadata.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. -
14. Re: POJO Schema parsing
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.