1 2 Previous Next 22 Replies Latest reply on Aug 7, 2008 9:35 AM by Alexey Loubyansky

    Wildcards and JBossXb Builder

    Ales Justin Master

      Reading through Kabir's AOP work on jaxb-ing his metadata:

      "adrian@jboss.org" wrote:

      You should let the MC schema define the {urn:jboss:bean-deployer:2.0}bean
      and use it as a "wildcard".


      I'm jaxb-ing our PolicyMetaData, having this in AbstractBindingMetaData:
       @XmlTransient
       public void setValue(ValueMetaData value)
       {
       this.value = value;
       }
      
       @XmlAnyElement
       public void setValueObject(Object value)
       {
       if (value == null)
       setValue(null);
       else if (value instanceof ValueMetaData)
       setValue((ValueMetaData) value);
       else
       setValue(new AbstractValueMetaData(value));
       }
      
       @XmlValue
       public void setValueString(String value)
       {
       if (value == null)
       setValue(null);
       else
       {
       ValueMetaData valueMetaData = getValue();
       if (valueMetaData instanceof StringValueMetaData)
       {
       ((StringValueMetaData) valueMetaData).setValue(value);
       }
       else
       {
       StringValueMetaData stringValue = new StringValueMetaData(value);
       stringValue.setType(getType());
       setValue(stringValue);
       }
       }
       }
      


      and I'm getting this exception:

      Caused by: org.jboss.xb.binding.JBossXBRuntimeException: {urn:jboss:bean-deployer:2.0}value not found as a child of {urn:jboss:policy:1.0}binding
      


      I thought the @XmlAnyElement will handle this as a wildcard?

        • 1. Re: Wildcards and JBossXb Builder
          Adrian Brock Master

          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
            Ales Justin Master

             

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

               

              "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
                Alexey Loubyansky Master

                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
                  Ales Justin Master

                   

                  "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
                    Alexey Loubyansky Master

                    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
                      Ales Justin Master

                      OK, I see.
                      What's the workaround/fix then? :-)

                      • 8. Re: Wildcards and JBossXb Builder
                        Alexey Loubyansky Master

                        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 Master

                           

                          "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
                            Ales Justin Master

                             

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

                              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 Master

                                 

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

                                   

                                  "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
                                    Ales Justin Master

                                     

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

                                    1 2 Previous Next