hi Alex,
what kind of client are you using ?
AMlan
Alex Duncan wrote:
> I am using JAX-RPC 1.1 EA (in JWSDP 1.2) to return what I hope is a JAX-RPC
> supported value type (or "application class"). It is a class that looks
> like the following (cut to the bone to show what is going on):
>
> package mywspackage;
> class A {
> public int i = 0;
> public B b = new B();
>
> public A() {}
> }
>
> According to the JAX-RPC 1.1 specification (and 1.0 for that matter), value
> type A can be constructed from JAX-RPC supported types, including other
> value types. Thus, according to the spec:
>
> package mywspackage;
> class B {
> public java.lang.String s = "hello";
>
> public B() {}
> }
>
> would be allowed as a value type that can be returned, and hence should be
> allowed as a member of A without A losing its status as a value type.
>
> The service handler interface used as input to wscompile looks like the
> following:
>
> package mywspackage;
> public interface MyWebService extends java.rmi.Remote
> {
> public A getA() throws java.rmi.RemoteException;
> }
>
> and wscompile does not complain. Neither does wsdeploy. The
> implementation class looks like:
>
> package mywspackage;
> import java.rmi.*;
> public class MyWebServiceImpl implements MyWebService {
> private a = new A();
>
> public A getA() { return a; }
> }
>
> However, client code, using an instance of a dynamic proxy (myWebService)
> constructed from a service using the URL for the WSDL and the line:
>
> A a = myWebServiceImpl.getA();
>
> will fail. I know that if class A does not contain an instance of B that
> getA() will succeed. In addition, I have tried adding the get and set
> methods for these fields without success.
>
> The exception is a "deserialization error" of type
> java.lang.NullPointerException occurring at:
>
> at
> com.sun.xml.rpc.encoding.SOAPDeserializationContext.deserializeMultiRefObjects(SOAPDeserializationContext.java:83)
> at com.sun.xml.rpc.client.StreamingSender.
> _send(StreamingSender.java:173)
> at
> com.sun.xml.rpc.client.dii.CallInvokerImpl.doInvoke(CallInvokerImpl.java:64)
> at com.sun.xml.rpc.client.dii.BasicCall.invoke(BasicCall.java:346)
> at
> com.sun.xml.rpc.client.dii.CallInvocationHandler.doCall(CallInvocationHandler.java:102)
> at
> com.sun.xml.rpc.client.dii.CallInvocationHandler.invoke(CallInvocationHandler.java:74)
> at $Proxy5.getA(Unknown Source)
> ...
>
> where the "deserializeMultiRefObjects" is rather telling, to an extent, and
> at least makes it look like what I am trying to do might be feasible.
>
> A post I read related to serialising a vector implies that adding an
> <additionalTypes> element to the config.xml might help because B is not
> referenced in the MyWebService interface. I tried the following:
>
> <typeMappingRegistry>
> <additionalTypes>
> <class name="mywspackage.B"/>
> </additionalTypes>
> </typeMappingRegistry>
>
> to no avail. I am not sure that I have used this element correctly, but it
> sort of made sense.
>
> Is there anything wrong with what I am trying to do? Does anyone think I
> would have more luck from another toolkit (Axis, Glue etc)? Does JWSDP 1.1
> work, given that I'll probably have to use it since the new version of
> JAX-RPC is still in Early Access and can't be redistributed anyway?
>
> The advanced example in the JWSDP 1.2 Tutorial appears to marshal a value
> type that has another value type as a member. However, "doc/literal" looks
> a bit harder and it looks as though I have to start with hand-crafted WSDL
> or try to implement lots of wrapper classes (which was not recommended).
> Do I have to use doc/literal???
>
>
>
>
>
> DISCLAIMER:-----------------------------------------------------------------------------------------------
> This Email may contain confidential and/or privileged information and is intended
> solely for the addressee(s) named. If you have received this information in error, or
> are advised that you have been posted this Email by accident, please notify the
> sender by return Email, do not redistribute it, delete the Email and keep no copies.
> ----------------------------------------------------------------------------------------------------------------------
--
Thanks - Amlan.
----------------------------------------------------------------------
"Saving Childrens Lives"
http://www.unicefusa.org/
Amlan Sengupta Sun Microsystems Inc,
External Phone : (408)404-8592 4150 Network Circle,MS SCA14-303,
Fax No : (408)404-8592 Santa Clara, CA 95054.
----------------------------------------------------------------------