-
1. Re: Wildcards and JBossXb Builder
adrian.brock Mar 3, 2008 3:00 PM (in response to alesj)Hard to say without the full stracktrace or a dump of the generated schema.
There was this error before:
http://jira.jboss.com/jira/browse/JBXB-120
so maybe this another bug in the same area?
The workaround for JBXB-120 was to list the java bean property names in the @XmlType. -
2. Re: Wildcards and JBossXb Builder
alesj Mar 3, 2008 3:24 PM (in response to alesj)"adrian@jboss.org" wrote:
Hard to say without the full stracktrace or a dump of the generated schema.
The code is in, just uncomment BindingJaxbTestCase.testBindingWithComplexValue to see the full problem. -
3. Re: Wildcards and JBossXb Builder
adrian.brock Mar 3, 2008 4:19 PM (in response to alesj)"alesj" wrote:
"adrian@jboss.org" wrote:
Hard to say without the full stracktrace or a dump of the generated schema.
The code is in, just uncomment BindingJaxbTestCase.testBindingWithComplexValue to see the full problem.
Can you ask Alex? Fixing the javabean parsing has already set me back nearly a day.
I don't currently have time to deal with something that isn't obvious and
where I have to collect all the information myself. :-) -
4. Re: Wildcards and JBossXb Builder
aloubyansky Mar 4, 2008 6:24 PM (in response to alesj)What happens here during wildcard resolution is that the schema for urn:jboss:bean-deployer:2.0 is found but it doesn't have value element as the root element.
The root elements are"log" wrote:
org.jboss.xb.binding.sunday.unmarshalling.ElementBinding@80cac9({urn:jboss:bean-deployer:2.0}beanfactory, type={urn:jboss:bean-deployer:2.0}beanfactoryType)
org.jboss.xb.binding.sunday.unmarshalling.ElementBinding@19d75ee({urn:jboss:bean-deployer:2.0}bean, type={urn:jboss:bean-deployer:2.0}beanType)
org.jboss.xb.binding.sunday.unmarshalling.ElementBinding@e1eea8({urn:jboss:bean-deployer:2.0}lazy, type={urn:jboss:bean-deployer:2.0}lazyType)
org.jboss.xb.binding.sunday.unmarshalling.ElementBinding@2db19d({urn:jboss:bean-deployer:2.0}deployment, type={urn:jboss:bean-deployer:2.0}deploymentType)
Also, I realized the XB doesn't behave according to the JAXB spec when XmlAnyElement.lax=false (which is the default)."javadoc" wrote:
f false, all the elements that match the property will be unmarshalled to DOM, and the property will only contain DOM elements.
http://java.sun.com/javaee/5/docs/api/javax/xml/bind/annotation/XmlAnyElement.html#lax() -
5. Re: Wildcards and JBossXb Builder
alesj Mar 4, 2008 7:23 PM (in response to alesj)"alex.loubyansky@jboss.com" wrote:
What happens here during wildcard resolution is that the schema for urn:jboss:bean-deployer:2.0 is found but it doesn't have value element as the root element.
Why does it have to be root element?
And how come that deployment and bean|beanFactory|lazy are all at the same level, considered as root elements? -
6. Re: Wildcards and JBossXb Builder
aloubyansky Mar 5, 2008 5:42 AM (in response to alesj)Root in this case means top-level. If it's not root then it's local and can not be referenced/reseolved from other schemas and even this same schema.
Probably, because they are annotated with XmlRootElement. -
7. Re: Wildcards and JBossXb Builder
alesj Mar 5, 2008 5:44 AM (in response to alesj)OK, I see.
What's the workaround/fix then? :-) -
8. Re: Wildcards and JBossXb Builder
aloubyansky Mar 5, 2008 6:06 AM (in response to alesj)So far, it's an XML/XSD issue (except for that lax=false issue). If you think the XML is valid then the schema has to be fixed by making value a root element.
-
9. Re: Wildcards and JBossXb Builder
adrian.brock Mar 5, 2008 6:52 AM (in response to alesj)"alesj" wrote:
OK, I see.
What's the workaround/fix then? :-)
The fix is for you to learn xsd, XSD 1.0.1 :-)
e.g.<policy xmlns="urn:jboss:policy:1.0"> <binding name="somename"> <value xmlns="urn:jboss:bean-deployer:2.0" class="java.lang.Integer">42</value> </binding> </policy>
There is no such element in the MC schema. The element is only defined
on the types where it is used, eg.<xsd:complexType name="entryType"> <xsd:annotation> <xsd:documentation> <![CDATA[ An entry in map. These are made of key/value pairs e.g.: <entry><key>default</key><value>http://localhost</value> ]]> </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="key" type="valueType" minOccurs="0"/> <!-- HERE --> <xsd:element name="value" type="valueType" minOccurs="0"/> </xsd:sequence> </xsd:complexType>
If you want it as an element that can be used in other schemas then you need
to add a top level element:<xsd:element name="value" type="valueType"> <xsd:annotation> <xsd:documentation> <![CDATA[ A value. ]]> </xsd:documentation> </xsd:annotation> </xsd:element>
and change the XB annotations (don't do this! it is just an example, it is wrong)@XmlRootElement(name="value") @XmlType(name="valueType") @JBossXmlNoElements public class AbstractValueMetaData extends JBossObject
In practice. The AbstractValueMetaData isn't really the valueType.
Instead that is a group defined here:@JBossXmlGroup ({ @JBossXmlChild(name="array", type=AbstractArrayMetaData.class), @JBossXmlChild(name="collection", type=AbstractCollectionMetaData.class), @JBossXmlChild(name="inject", type=AbstractDependencyValueMetaData.class), @JBossXmlChild(name="list", type=AbstractListMetaData.class), @JBossXmlChild(name="map", type=AbstractMapMetaData.class), @JBossXmlChild(name="null", type=AbstractValueMetaData.class), @JBossXmlChild(name="set", type=AbstractSetMetaData.class), @JBossXmlChild(name="this", type=ThisValueMetaData.class), @JBossXmlChild(name="value", type=StringValueMetaData.class), @JBossXmlChild(name="value-factory", type= AbstractValueFactoryMetaData.class) }) @JBossXmlGroupText(wrapper= StringValueMetaData.class, property="value") @JBossXmlGroupWildcard(wrapper= AbstractValueMetaData.class, property="value") public interface ValueMetaData extends JBossInterface, MetaDataVisitorNode
The group isn't what you want for the wildcard element. :-) -
10. Re: Wildcards and JBossXb Builder
alesj Mar 5, 2008 6:52 AM (in response to alesj)"alex.loubyansky@jboss.com" wrote:
So far, it's an XML/XSD issue (except for that lax=false issue). If you think the XML is valid then the schema has to be fixed by making value a root element.
This is already working if I use the old approach - with SchemaInitializer.
But I fail to get it working with JBossXB Builder.
See BindingTestCase vs. BindingJaxbTestCase. -
11. Re: Wildcards and JBossXb Builder
adrian.brock Mar 5, 2008 6:57 AM (in response to alesj)What I'd propose is what I discussed with Kabir here:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132601#4132601
See point (3).
i.e. we create an mc-commons.xsd and you xsd:redefine that into your namespace.
You can then use all the mc xsd types in your namespace and the user
doesn't have to write all those xmlns directives. ;-) -
12. Re: Wildcards and JBossXb Builder
adrian.brock Mar 5, 2008 6:59 AM (in response to alesj)"alesj" wrote:
"alex.loubyansky@jboss.com" wrote:
So far, it's an XML/XSD issue (except for that lax=false issue). If you think the XML is valid then the schema has to be fixed by making value a root element.
This is already working if I use the old approach - with SchemaInitializer.
But I fail to get it working with JBossXB Builder.
See BindingTestCase vs. BindingJaxbTestCase.
I shouldn't be working though. Its probably only working because
you've hacked it in the schema initializer. :-)
Problems:
1) the MC schema doesn't export a "value" element
2) the policy schema doesn't even define an xsd:any element :-) -
13. Re: Wildcards and JBossXb Builder
adrian.brock Mar 5, 2008 7:08 AM (in response to alesj)"adrian@jboss.org" wrote:
I(t) shouldn't be working though. Its probably only working because
you've hacked it in the schema initializer. :-)
Problems:
1) the MC schema doesn't export a "value" element
2) the policy schema doesn't even define an xsd:any element :-)
This is really a more generic problem. The best way to catch this in the long term
(e.g. making sure people define the schema properly when they change the
metadata/parsing) is to enable validation of the xml against the schema
in our xml parsing tests (and optionally on the BaseXmlDeployer/MicrocontainerTest).
See the SchemaResolverDeployer for how to do this. -
14. Re: Wildcards and JBossXb Builder
alesj Mar 5, 2008 7:10 AM (in response to alesj)"adrian@jboss.org" wrote:
The fix is for you to learn xsd, XSD 1.0.1 :-)
Looks like not that I'll only learn, I'll have to make a whole degree out of it.
I though JBossXB Builder was here to relieve the xsd pain, but it's turning to be the other way around ... :-)"adrian@jboss.org" wrote:
i.e. we create an mc-commons.xsd and you xsd:redefine that into your namespace.
You can then use all the mc xsd types in your namespace and the user
doesn't have to write all those xmlns directives. ;-)
And how does this affect jaxb usage?