jboss-dev-forums

[Jboss-dev-forums] [Design of JBoss's Web Services Implementation] - Re: Handling array types by JBossWS Tools

[<ani...@jb...>]

http://jira.jboss.com/jira/browse/JBWS-227

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878934#3878934

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878934

[Jboss-dev-forums] [Design of JBoss's Web Services Implementation] - Re: Handling array types by JBossWS Tools

[<ani...@jb...>]

Handling array types the way wscompile does has complicated the tools code to the extent that I fear I will have difficulty maintaining it for the vast gamut of requirements for J2EE 5. 

One reason I am apprehensive about the approach is that there is no intuitive order in which wscompile generates the namespaces ns2,ns3 etc. An example is the StandardTypes SEI in the testsuite and the wsdl that is generated by wscompile - "MarshallService.wsdl".  Tell me if you can figure out how wscompile generates the namespaces ns2,ns3 etc.



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882966#3882966

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882966

[Jboss-dev-forums] [Design of JBoss's Web Services Implementation] - Re: Handling array types by JBossWS Tools

[<tho...@jb...>]

The prefix assocciation (ns1, ns2, ...) with a namespace uri is not relevant for two schemas to be semantically equivalent. 

It is probable that wscompile puts array types in seperate schema files to associate them with different target namespaces and such avoids name collisions. Is is all about reuse of the defined type in a different schema.

Image you have two comlex java types that live in two different packages and both use the same array type. For that scenario it makes sense to define the array type in yet another schema.

Whether jbossws tools produces output that is equivalent to wscompile largely depends on the validation algorithm. Lexical equivalencs is not required neither the use of identical namespace prefixes.

anonymous wrote : 
  | When schema components are imported from multiple namespaces, each namespace
  | must be identified with a separate import element. The import elements themselves
  | must appear as the first children of the schema element. Furthermore, each namespace
  | must be associated with a prefix, using a standard namespace declaration, and that
  | prefix is used to qualify references to any schema components belonging to that
  | namespace. Finally, import elements optionally contain a schemaLocation attribute to
  | help locate resources associated with the namespaces.
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883049#3883049

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883049

[Jboss-dev-forums] [Design of JBoss's Web Services Implementation] - Re: Handling array types by JBossWS Tools

[<ale...@jb...>]

AFAICS in our testsuite, when I see a type in an XSD defined following this 'array' template, it's not necessarily bound to an array in Java.

For example.

testsuite/src/resources/webservice/marshalltest-doclit/META-INF/wsdl/MarshallDocLitService.wsdl


  |       <complexType name="LongArr">
  |         <sequence>
  |           <element name="longArr" type="long" minOccurs="0" maxOccurs="unbounded"/>
  |         </sequence>
  |       </complexType>
  | 

Isn't this TYPE bound to a class that wrapps the array?


  | package org.jboss.test.webservice.marshalltest.types;
  | 
  | public class LongArr
  | {
  |    private long[] longArr;
  | 
  |    public LongArr()
  |    {
  |    }
  | 
  |    public LongArr(long[] longArr)
  |    {
  |       this.longArr = longArr;
  |    }
  | ...
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888450#3888450

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888450

[Jboss-dev-forums] [Design of JBoss's Web Services Implementation] - Re: Handling array types by JBossWS Tools

[<jas...@jb...>]

Actually, that example also uses a wrapper element.


        
          
        


So the correct serialization would be:
<LongArr_1>
  1
  2
  3
</LongArr_1>

According to the JAXB spec, this is one of the 2 ways an array in Java can be represented in schema. The other is the way you mention. Also, according to the spec, the element wrapping style is not the default. In order, to use this style you are supposed to mark the field with an @XmlElementWrapper annotation. (See https://jaxb.dev.java.net/nonav/jaxb20-pr/api/javax/xml/bind/annotation/XmlElementWrapper.html)

Contrary to the JAXB methodology, WS-I Basic Profile 1.1 demonstrates serialization using element wrappers. I will have to research this further. So far I have not seen any mention in the public review of JAX-WS 2.0 as to how this is configured with the stack. I may need to take a look at the Sun EA release.

-Jason


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888829#3888829

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888829

[Jboss-dev-forums] [Design of JBoss's Web Services Implementation] - Re: Handling array types by JBossWS Tools

[<tho...@jb...>]

Yes, there maybe a bean that wraps the array. However we cannot force the public API to always use these wrapper types.

A good example is a DII client that uses an array as operation parameter. In that case there will be no wrapper bean.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888902#3888902

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888902

[Jboss-dev-forums] [Design of JBoss's Web Services Implementation] - Re: Handling array types by JBossWS Tools

[<ale...@jb...>]

If there are two ways to bind arrays, there must be one which is the default one. The other one should be specified with binding customizations, e.g. jaxrpc-mapping.
Can we agree on this? Let's create a testcase that would demonstrate this.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888908#3888908

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888908

[Jboss-dev-forums] [Design of JBoss's Web Services Implementation] - Re: Handling array types by JBossWS Tools

[<jas...@jb...>]

anonymous wrote : 
  | If there are two ways to bind arrays, there must be one which is the default one. 
  | 

JAXB2.0 spec says the default is non-wrapped for collections (includes arrays). Also it appears that JAXB can identify the wrapped style (when generating java classes from schema) by naming convention. The spec says the wrapper element should be named the same as the nested elements, and that name should match the property name.

I checked the jaxws ea, and it looks like they follow the jaxb specs defaults. Here is a document wrapped service taking 2 arrays:

[cpde]
<xs:complexType name="echoInts">
    <xs:sequence>
      <xs:element name="arg0" type="xs:int" form="qualified" maxOccurs="unbounded" minOccurs="0"/>
      <xs:element name="arg1" type="xs:string" form="qualified" maxOccurs="unbounded" minOccurs="0"/>
    </xs:sequence>
  </xs:complexType>


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888929#3888929

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888929

[Jboss-dev-forums] [Design of JBoss's Web Services Implementation] - Re: Handling array types by JBossWS Tools

[<tho...@jb...>]

This argument is IMO only relevant to wstools. The marshalling layer has a contract with the WS layer to generate/consume XML fragments that conform to the given schema + mapping information.

I see two cases:

1) The complex type that denotes the array is mapped (in jaxrpc-mapping) to an array of java objects or primitives

2) The complex type that denotes the array is mapped to a wrapper bean

Case (2) is no different to marshalling/unmarshalling any other bean

Case (1) needs to be supported and is covered by the marshall.rpclit test cases


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3889041#3889041

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3889041