1 2 Previous Next 16 Replies Latest reply on May 5, 2006 11:29 PM by anil.saldhana

    Handling of xml wildcards

      This discussion relates to http://jira.jboss.org/jira/browse/JBWS-434.

      Heiko wrote:


      ... it seems to be a fairly complex problem
      that requires changes at the marshalling and unmarshalling components.
      But we might aswell think about an intermediate solution to keep moving:

      a, We make it possible to deploy schemas and jaxrpc-mappings that include xml wildcards, but the current implementation simply skips processing of these elements. At least it shouldn't complain or throw exceptions. Which basically means, we silently don't support them at the time being.

      b, I do an implemention based on axis, which we probably may need for backporting reasons anyway. But this depends on the efforts and time it requires to get support for wildcards.

      AFAIK marshalling wildcards needs to be supported in order to be JAXRPC compliant, but Thomas may know more about this.
      If this is the case, then A is not an option anyway.


      Alexey wrote:

      I think we already have this. There is an option in the XercesXsMarshaller

      public void setIgnoreUnresolvedWildcard(boolean value)



      Heiko wrote:

      That doesn't seem to work with mapped elements that contain wildcard content, i.e.:

      <!-- Types and global elements -->
      <xs:complexType name="DeliveryType" mixed="true">
       <xs:sequence>
       <xs:any namespace="##any" processContents="lax"
       minOccurs="0" maxOccurs="unbounded" />
       </xs:sequence>
       <xs:attribute name="Mode" type="xs:anyURI" use="optional" />
      </xs:complexType>
      



      Adrain wrote:
      What is wrong with processContents="lax" or "skip"?


        • 1. Re: Handling of xml wildcards

          As far as i can tell, neither 'setIgnoreUnresolvedWildcard' nor 'processContents=skip/lax' seems to be working. Besides, it might happen that i don't have influence on the schema to manipulate this directive.

          Anyway, both suggestions lead to an intermediate fix. In the long run, I'd say, we do need full support for wildcards anyway. The question is, what does it take to implement it?

          The basic idea is that wildcards get mapped to SOAPElement's.
          It's explained here: http://java.sun.com/developer/technicalArticles/xml/jaxrpcpatterns/index4.html

          • 2. Re: Handling of xml wildcards
            thomas.diesler

            Heiko,

            does

            tdiesler@satellite /cygdrive/d/projects/jboss-head/webservice/test
            $ ant -Dtest=org.jboss.test.ws.jbws434.JBWS434TestCase one-test
            
            one-test:
             [junit] Running org.jboss.test.ws.jbws434.JBWS434TestCase
             [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 3.495 sec
             [junit] Test org.jboss.test.ws.jbws434.JBWS434TestCase FAILED


            cover what you need?

            Alex, I raised the priority on this issue to critical since there now seem to be many parties that depend on it.

            • 3. Re: Handling of xml wildcards

              Yes, it does. It's the test case i'am using for debugging.

              • 4. Re: Handling of xml wildcards
                aloubyansky

                I am working on this.

                • 5. Re: Handling of xml wildcards
                  aloubyansky

                  What is the contract for [un]marshalling any type in jaxrpc?

                  The arrays is of type SOAPElement[] and items are created like this

                  SOAPFactory factory = SOAPFactory.newInstance();

                  SOAPElement el1 = factory.createElement("name", "ns1", "http://somens");
                  el1.setValue("Kermmit");
                  SOAPElement el2 = factory.createElement("product", "ns1", "http://somens");
                  el2.setValue("Ferrari");

                  • 6. Re: Handling of xml wildcards

                    xsd:Any should be expressed as SOAPElements that are mapped to a property called '_any'. If the wildcard has maxOccurs>1 then it is mapped to an array of SOAPElements.
                    Take a look at the example:

                    public class ArrayOfAny {
                     protected SOAPElement[] _any;
                    
                     public ArrayOfAny() {
                     }
                    
                     public ArrayOfAny(SOAPElement[] _any) {
                     this._any = _any;
                     }
                    
                     public SOAPElement[] get_any() {
                     return _any;
                     }
                    
                     public void set_any(SOAPElement[] _any) {
                     this._any = _any;
                     }
                    }
                    
                    


                    The variable mapping will contain a xml-wildcard directive in this case:

                     <java-xml-type-mapping>
                     <java-type>org.jboss.test.ws.jbws434.ArrayOfAny</java-type>
                     <root-type-qname xmlns:typeNS="http://org.jboss.ws/jbws434/types">typeNS:ArrayOfAny</root-type-qname>
                     <qname-scope>complexType</qname-scope>
                     <variable-mapping>
                     <java-variable-name>_any</java-variable-name>
                     <xml-wildcard/>
                     </variable-mapping>
                     </java-xml-type-mapping>
                    


                    There's a pretty good explanation here:
                    http://java.sun.com/developer/technicalArticles/xml/jaxrpcpatterns/index4.html
                    xsd:anyAttribute is currently supported by JAX-RPC.

                    • 7. Re: Handling of xml wildcards

                      Handling xsd:anyType is simliar to xsd:any with the difference that there is no wrapper class.

                      • 8. Re: Handling of xml wildcards
                        aloubyansky

                        About estimation. I haven't read that all but from what I've learnt so far, I could target it only for the next quater.
                        These jaxrpc mapping rules should be expressed in JAXB binding customizations and if needed JBossXB ones if JAXB is not sufficient.

                        • 9. Re: Handling of xml wildcards
                          aloubyansky

                          It looks like it depends on

                          Support for plugable serializer/deserializer
                          http://jira.jboss.com/jira/browse/JBXB-40

                          There should be a special XML parser that would parse the content of any and produce SOAPElement's. And this parser should be plugged-in into the JAXB/JBossXB unmarshaller.
                          The same for marshalling.

                          • 10. Re: Handling of xml wildcards

                            Isn't that what the JAXB binding customizations are all about?
                            If i understand it right, you can plug custom converters for java types:
                            I.e:

                            <jxb:javaType name="javax.xml.soap.SOAPElement"
                             parseMethod="org.joss.xb.SOAPConverter.parseSOAPElement"
                             printMethod="org.joss.xb.SOAPConverter.printSOAPElement"/>
                            


                            Whereas parse and print denote deserialze and serialize?

                            • 11. Re: Handling of xml wildcards
                              aloubyansky

                              Right but AFAIK javaType is a valid customization only for simple types while SOAPElement is like a Node in DOM.

                              • 12. Re: Handling of xml wildcards
                                aloubyansky

                                For the testcase we have though we could try to use it since this testcase contains only simple values AFAICS. Would this limitation work for you, Heiko?

                                • 13. Re: Handling of xml wildcards

                                  I am sorry, but i can't follow you.
                                  Why can't we treat SOAPElements as simple types? What's the problem you see here?

                                  • 14. Re: Handling of xml wildcards

                                    Ah, ok. Stupid question. Now i get it...
                                    Alexey, please forget my previous post.

                                    1 2 Previous Next