Hi,
I've noticed something that appears to be a bug in WSDL2Java. If the class
used to generate the service contains a method that returns a Map (or takes
a Map as a parameter) then the signature of the corresponding stub
classes/interfaces use 'HashMap' instead of 'Map'.
For example:
public class MyService
{
public Map foo(Map m)
{
return m;
}
}
would result in an generated interface [for the client]:
public interface MyService extends java.rmi.Remote
{
public HashMap foo(HashMap m) throws java.rmi.RemoteException;
}
The same thing happens to stubs generated for complex types.
I know one should try to avoid the use of Map's and other collection classes
for interoperability considerations, but there are times when one cannot
easily avoid doing so -- such as when creating a minimalist web service
wrapper around a legacy component. Despite the fact that there are
workarounds to this behavior of WSDL2Java, I thought it might be worth
mentioning.
Curious too, about any opinions out there -- especially from those who
believe that there are important reasons for it to work like this.
(Comments appreciated.)
PS:
In my case I'd built a 'service client' & web service using Sun's JAX-RPC
RI, which I've now ported to Axis -- which I've found far superior in so
many ways. My 'service client was abstracted from the underlying JAX-RPC
implementation (despite the fact that I was using generated stubs) because I
was using a 'Service factory' object that was the only class that knew about
the stubs being used.
My client code would have remained untouched were it not for the unexpected
changes to the method signatures.
