users@jax-rpc.java.net

Re: deserialization error for value type

From: Alex Duncan <alex.duncan_at_ADI-LIMITED.COM>
Date: Wed, 17 Sep 2003 09:16:07 +1000

Hello,

I made a little progress with this issue. I took out the model parameter
when I was running wscompile, which I thought was only for writing "the
internal model to the given file" (JWSDP Tutorial). However, I had the
<modelfile> element in my config.xml which appears to cause the model file
to be reused. No wonder that when I was testing changes that very little
seemed to change. It turns out that the <additionalTypes> element was
necessary.

However, while "getA()" (refer to original post) no longer generates an
exception, and can return an instance of A that could be modified within
the implementation of the service interface with the modified field values
marshalled successfully, I still have a problem.

The problem is that whatever I do to the "b" field (an instance of "B") is
not marshalled correctly as a member of A. I can't even initialise values
in the constructor of B. Whatever the member initialisation statement sets
for the field is as though it were declared final. So, the value of "s"
remains "hello" even if the implementation of MyWebServiceImpl.getA()
happens to modify this value (verifiable in the debugger right up until the
return statement). If "s" is default initialised (null), but initialised
with a String object in getA(), null is still marshalled. Incidentally, I
can verify that an instance of B by itself can be marshalled correctly
through the remote interface with some very minor code changes.

I had thought that perhaps the "wsi" or "strict" features parameters for
wscompile might work. Alas, no. Did "searchschema" work? No, that seems
to be for aggressively finding types to generate from WSDL (whatever
"aggressively" means, I just want it to work as I expect from
specifications). I can't seem to find much more than one-line descriptions
for wscompile parameters, although admittedly these are usually adequate.

A reminder that I am using a dynamic proxy with rpc encoding, and I am
generating WSDL from an RMI Remote interface. The generated WSDL looks
good and reasonably straightforward (so I don't think a WSDL-driven
approach would fix my problem). I will post the WSDL if anyone thinks the
problem could be there (I'll try to keep this post short). My inclination
is to think that the problem might be in my client code (MyServices is an
endpoint mapping and MyBase is the urlPatternBase in the jaxrpc-ri.xml
file):

        MyWebService myWebService;

        String urlString = "
http://localhost:8080/MyServices/MyBase/MyEndpoints?WSDL";
        String nameSpaceUri = "http://myservice.org/wsdl";
        String serviceName = "MyWebService";
        String portName = "MyWebServicePort";

        URL myWsdlUrl = new URL(urlString);

        ServiceFactory serviceFactory = ServiceFactory.newInstance();

        Service service = serviceFactory.createService( myWsdlUrl,
                             new QName(nameSpaceUri, serviceName) );

        // I can use the TypeMappingRegistry object from
        // service.getTypeMappingRegistry() here if I need to???

        myWebService = (MyWebService) service.getPort(
                                       new QName(nameSpaceUri, portName),
                                       mywspackage.MyWebService.class
                                    );

       A a = myWebService.getA();

      System.out.println(a.b.s);

Do I need to add code to register a type mapping with the type mapping
registry before I use the proxy object or before calling getPort()? I
can't find any examples on this and the API docs are a little terse. I
don't need a "holder" for a return value do I (even if it is kind of an out
parameter)?

To reiterate another question from my previous post, do I need to use
doc/literal with wrapper classes (e.g, ChangeValueType) to solve this
problem? The JWSDP 1.2 Tutorial makes it look like this will at least
work, but I think I would choose to flatten all my structures to one value
type using only primitive types before choosing to go through those wrapper
classes all the time.


Regards,

Alex




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.
----------------------------------------------------------------------------------------------------------------------