We are currently looking at migrating from WL 8.1 to WL 10.3, and have an issue with some of our web services (JAX-RPC) with regards to returning String arrays.
We have a web service method that returns a response object. This response object has many properties that includes a property that is a String array. So the code looks something like this (this is a simplified version):
<em>public class OurService
@WebResult(name = "result")
public ResponseObject lookup(String someParam)
// build the object and its properties here...
This is what the response object looks like:
<em>public class ResponseObject
private String someProperty;
public String getSomeProperty()
public void setSomeProperty(String </em><em>someProperty</em><em>)
So the issue is this. In WL 8.1, the web service generator would recognise the fact that the response object had a property that was a String array and would declare as such in the WSDL file, for example:
<em><strong> <xsd:element xmlns:tp="java:language_builtins.lang" type="<font color="#ff0000">tp:ArrayOfString</font>" name="someProperty" minOccurs="1" nillable="true" maxOccurs="1">
As a result, when the service is called, the property is returned in the SOAP response like this:
<em><strong> <xs:element maxOccurs="unbounded" minOccurs="0" name="InstepCodes" nillable="true" type="xs:string">
As a result the property is returned in the SOAP response like this:
</strong>The difference here is that WL 10.3 does not return the array of strings as a complex array type, just as a set of repeated elements.
We need to return the array as we do for WL 8 in WL 10.3, because we have external clients that are parsing the response and looking for the XML in this format. We are not currently in a position to ask them to change.
Is this a limitation of the JAX-RPC spec, or WL's implementation of it?
If the service was to return a String array directly from a service method, then it is declared in the WSDL file.
However, if a service returns an object that within itself has a property that is an array, it does not recognise it like it did with WL 8.1.
would a feasible workaround be to take the WSDL that 8.1 generated, start with that and run WSDLC in 10.3 to generate the Java Interfaces corresponding to the WSDL that you want. Then port the service to fit the generated interface ?
This is if the existing clients must recieve the sameXML messages, and if there is no way to affect JWSC in 10.3 to generate WSDL to match the 8.1 WSDL given the existing Java Service implementation..
AFAIK the WebService version story in WLS from 8.1 is like this:
In 8.1 there were 2 separate BEA WebService stacks:
1. the 'WebLogic Server' stack
2. the 'WebLogic Workshop' stack
(I note that I never did ask which 8.1 version you are using).
By release 9 (when I joined the WebService stack development team), the 'WebLogic' stack was completely re-written and has nothing in common with the 8.1 stack. Also, BEA wisely decided that it made sense to have only 1 WebService stack, and that stack would be the WebLogic Server stack.
Release 10 and 10.3 are based on the release 9 stack.
It's not quite the answer you're looking for but the 8.1 stack and the 9-10 stack are completely different and may exhibit very different behaviors (I think the 8.1 stack may not be JAX-RPC 1.1 compliant, whereas the 9-10 stack is).
WRT to the mapping of Java Arrays to XML, I notice that the JAX-RPC 1.1 spec, section 5.3.4 lists 4 different ways in which they allow a Java Arrays to be mapped to XML/WSDL types (including the JavaBean approach).
I'm a little puzzled. You say that 10.3 generates ONLY an unbounded element to represent the String, with no complexType wrapper ? If that's true, it seems to violate the JAX-RPC spec (above mentioned section 5.3.4)..
As stated in my first post, the service method returns an reponse object and its this that contains the array property. The service method itself does not return an array type. This seems to be the root of the problem, i.e. the declaration of array types is not being propagated down through the object graph the service method returns. Below is the code for the service and the response object.
Out of curiousity, I spent a little time this evening writing a Start from Java service that has a method that passes a JavaBean containing only a single String property.
jwsc compiled this fine and created a WSDL with a plain complex type with a single unbounded xs:string element representing the JavaBean (that is not the soapenc array version that is also allowed by the JAX-RPC spec).
Then I ran clientgen on the resulting wsdl, with the JaxRPCWrappedArrayStyle="true" option set, this causes clientgen to create the JavaBean wrapper for the unbounded xs:string element of the complexType "DocLitWrapBasicStruct":
so the test client uses the JavaBean as an argument in the generated proxy method (not the bare String):
DocLitWrapBasicStruct in = new DocLitWrapBasicStruct();
DocLitWrapBasicStruct result = port.echoDocLitWrapBasicStruct(in);
The message over the wire looks good (the style is document literal wrapped so there's the operation wrapper element 'echoDocLitWrapBasicStruct' outer element containing the element representing the JavaBean:
May thanks for looking into this, much appreciated.
To be honest the statement "Do you mean that you want JWSC to produce an element that's one of the 'soapenc' Array types ?" was more out of hope than anything else (i.e. I dont suppose there is a magic switch anywhere!).
But as your test harness seems to give the expected result then its a matter of going back and trying it at our end to see what happens. I will post my findings back here.
Haven't tried it for 1 dimensional String in RPC-Encoded though.
But the fact remains, that yes, there is no switch to control the generation of these, though the runtime should accept and (un)marshal all the various array types.
If your clients must have soapenc Arrays on the wire, I still think using WSDLC on a WSDL that defines soapenc Arrays is the only possible avenue.. Let us know how it goes !