Object that contain ArrayList

[Eva Villarroya]

Hello!

I have a method on a class that return a HashMap containing some ArrayLists. I have deployed this class as a webservice with Axis and Tomcat. I found that all it's ok, except that the returned HashMap doesn't contain ArrayList; it contains Object[]. Another method in this class return an ArrayList successfully, but it seems when the ArrayList is inside another object it deserializes it as Object[].

Is there some way to configure the WSDD or SoapBindingStub class that can avoid this conversion from ArrayList to Object[], and let deserialize an ArrayList correctly?

Thanks in advance,
Eva.

[naveen]

I also send ArrayList and it doesn't convert it into Object[]. Below is my WSDD file. Compare it with yours, it might be helpful

<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<globalConfiguration>
<parameter name="sendXsiTypes" value="true"/>
<parameter name="sendMultiRefs" value="true"/>
<parameter name="sendXMLDeclaration" value="true"/>
<requestFlow>
<handler type="java rg.apache.axis.handlers.JWSHandler"/>
</requestFlow>
</globalConfiguration>
<handler name="URLMapper" type="java rg.apache.axis.handlers.http.URLMapper"/>
<service name="Esqk" provider="java:RPC">
<requestFlow>
<handler type="java rg.apache.axis.handlers.SimpleAuthenticationHandler"/>
<handler type="java rg.apache.axis.handlers.SimpleAuthorizationHandler"/>
</requestFlow>
<parameter name="allowedRoles" value="acrole"/>
<parameter name="allowedMethods" value="*"/>
<parameter name="className" value="wcom.gend.iasa.ipcom.webservice.esqk.Esqk"/>
<beanMapping languageSpecificType="java:wcom.gend.iasa.ipcom.webservice.esqk.base.AddOrChangeESQK" qname="ns278:AddOrChangeESQK" xmlns:ns278="urn:AddOrChangeESQKService"/>
<beanMapping languageSpecificType="java:wcom.gend.iasa.ipcom.webservice.esqk.base.RemoveOrQueryESQK" qname="ns279:RemoveOrQueryESQK" xmlns:ns279="urn:RemoveOrQueryESQKService"/>
<beanMapping languageSpecificType="java:wcom.gend.iasa.ipcom.webservice.esqk.base.Request" qname="ns280:Request" xmlns:ns280="urn:RequestService"/>
<beanMapping languageSpecificType="java:wcom.gend.iasa.ipcom.webservice.esqk.base.Response" qname="ns281:Response" xmlns:ns281="urn:ResponseService"/>
<beanMapping languageSpecificType="java:wcom.gend.iasa.ipcom.webservice.esqk.base.ErrorParameter" qname="ns282:ErrorParameter" xmlns:ns282="urn:ErrorParameterService"/>
<beanMapping languageSpecificType="java:wcom.gend.iasa.ipcom.webservice.esqk.base.Error" qname="ns283:Error" xmlns:ns283="urn:ErrorService"/>
</service>
<transport name="http">
<requestFlow>
<handler type="URLMapper"/>
<handler type="java rg.apache.axis.handlers.http.HTTPAuthHandler"/>
</requestFlow>
</transport>
<transport name="local">
<responseFlow>
<handler type="java rg.apache.axis.transport.local.LocalResponder"/>
</responseFlow>
</transport>
</deployment>

[Nikita Rai]

In my program when I am sending an ArrayList via webservices they are getting resolved into Object array. Can you let me know the way in which ArrayList can be retained because as per the posts above It seems they are able to resolve ArrayList as ArrayList only. Do let me know the axis jar version to be used to retain the ArrayList when passed via Webservices. Thanks for the same.

[Ulf Dittmer]

Hello "Sun Solution"-

On your way in you may have missed that JavaRanch has a policy on display names, and yours does not comply with it - please adjust it accordingly, which you can do right here. Thanks for your prompt attention to this matter.

[Peer Reynders]

Originally posted by Nikita:
Do let me know the axis jar version to be used to retain the ArrayList when passed via Webservices.

That name still isn't compliant; better read the Official policy on registered names again - otherwise the person who has the answer may never reply.

Anyway, the simple solution is:

Just don't do it!

The reason why it worked for the previous posters may have nothing to do with jars and versions. To maintain the "Java-ness" of the data transferred beyond the basic Java to XML mapping as specified by the JAX-RPC specification Axis has to employ the infamous Section 5 SOAP Encoding - which can cause you grief in the long run.

It's better to stick with the more interoperable "literal XML Encoding". However XMLSchema knows nothing of ArrayLists. It actually doesn't know anything about arrays but thats where the JAX_RPC 1.1 Spec Type Mapping (see Chapter 4 and 5) helps out:
"The JAX-RPC specification supports a Java array with members of a supported JAXRPC Java type. The JAX-RPC specification requires support for Java array of type java.lang.Object."

When you define interfaces for Web services, only define interfaces that make sense in the world of the Basic Profile (XML, XMLSchema, SOAP, WSDL) - not Java! The easiest way to do that is to define the WSDL first and then use WSDL2Java - lock the Java2WSDL tool away! Otherwise you are throwing away the biggest feature that Web services have going for them - platform independence.

Now in J2EE Web services it is possible to bump an array up to an ArrayList by using a JAX-RPC Mapping Deployment Descriptor (java-wsdl-mapping;Web Services for J2EE, 7.3 JAX-RPC Mapping Deployment Descriptor) but I don't think Axis supports that.

Then again, how much work is:

import java.util.ArrayList;
import java.util.Arrays;
 
public class AsList {
    public static void main( String[] args ){
        Object[] objArray = {new Integer(12), new Integer(34), new Integer(56) };    
        [B]ArrayList myList = new ArrayList(Arrays.asList( objArray ));[/B]
        System.out.println( myList );
    }
}

or

import java.util.ArrayList;
 
public class AsList {
    public static void main( String[] args ){
        Object[] objArray = {new Integer(12), new Integer(34), new Integer(56) };    
        [B]ArrayList<Integer> myList = new ArrayList<Integer>(objArray.length);
        for(Object o: objArray) myList.add((Integer)o);[/B]
        System.out.println( myList );
    }
}

anyway?

[Nikita Rai]

Hi Peer,

Thanks a lot for your message. The reason as to why I have asked for the retainment of ArrayList when passed via Webservices is because we already have a class which we need to make as a Webservice. This class is already used by many other classes and the methods in these classes return ArrayList of Value objects.

Regards,
Nikita

[William Brogden]

This class is already used by many other classes and the methods in these classes return ArrayList of Value objects.

That situation would appear to call for a "wrapper" class that converts any ArrayList returned by your working class into an array. As Peer says, ArrayList is not something understood by .NET, Perl, or any other non-Java potential client of your web service.
The toArray method is really quite fast, I use it all the time.
Bill

[Peer Reynders]

[

Originally posted by Nikita Rai:
We already have a class which we need to make as a Webservice. This class is already used by many other classes and the methods in these classes return ArrayList of Value objects.

Your little problem may be merely a symptom indicating that it is be time to do some refactoring. Normally class level dependencies are way too fine-grained to expose via a Web service.

So unless that class is already some fa�ade that encapsulates a finer-grained object model, you should redefine your web interface to send all the data necessary to rebuild the entire object on the Web service client�s end in response to a single Web service call. A helper class would make the Web service call and build the object.

The class can be exposed as a web service if it has a sufficiently coarse grained interface. However the "client classes" that use the "server class" shouldn�t be using the "server class" directly � they should be using an interface implemented by the "server class" (even when they use a Web service � they aren�t using the class directly). Once you�ve got all the "client classes" using the "server interface" rather than the "server class" you can insert a Proxy that implements the "server interface" on the Web service client which serves the "client classes". The Proxy is "the Wrapper", as it would not only be responsible for making the Web service call but also the translating and mapping of all the parameters of the client request and of any information in the Web service response.
Ultimately, you don�t want your many "client classes" accessing the generated stubs anyway � only your Wrapper/Proxy should be dealing with the stubs.