could not find deserializer for type

[scharlau]

Hi all,

I'm trying to get a document literal ws working on 4.0.2-rc1. The app deploys ok, and I can grab the wsdl using Eclipse web service explorer, but get a 'could not find deserializer for type' error when I try to call a method. This app uses complex-types to serialize and deserialize the classes, and I'm not sure that I got them in the correct location, or if something else is going wrong here.

I'm using a SLSB to provide the service and use wscompile to generate the deployment descriptors. I've got the wscompile generated classes under META-INF/wsdl next to the wsdl file. I tried putting them with the other classes, but then the wsdl file doesn't deploy, so that seemed wrong too. Strange, but I couldn't find anything on packaging up one of these web service type of apps.

I suppose the other thing I should say is that I had it all working with RPC literal, but figured for interoperability (banging head against wall trying to retrieve soap objects with c#) the doc lit version might offer a better version.

TIA,

Bruce

[thomas.diesler]

The classes should go with the other classes in your EJB endpoint deployment. Below META-INF is definitely incorrect.

Have you followed the StepByStep tutorials on doc/lit?

There are also samples available at the bottom of the wiki that use doc/lit.

[scharlau]

Thomas,

thanks for pointing out the samples. Anyways, I'm slowly working out more on this problem. I switched to 4.0.2, and got a doc lit war version with a servlet working ok, and have also got a jar version with a simpler doc lit EJB version working ok. Therefore, I suspect that the problem lies somewhere amongst a classpath issue in my application.

The app builds ok, and deploys the WS ok, generating the wsdd and wsdl under the data directory. However, when I try to call the wsdl from a client, I get a StackOverflow error in the console, plus client reports no root in the wsdl document.

A check of the wsdl in the data directory shows that it is ok. Does this mean that it is rebuilt everytime it is called, or was it just poorly retrieved by the client? I'll try it again with a different client to see if I can get more feedback on the error message.

Bruce

[scharlau]

Just as a followup in case others need to work this out later. I figured that I should say what I found the problem to be. Too many ingredients getting in the way, as I suspected. The app has Jade agents, RDF, and other bits and pieces too. I just needed to sort out what was getting in the way of the web services and then ensure that the RDF construction happened clearly on the correct side of the service before putting the triples into strings as part of objects.

The problem was that the error messages were not coming through, even when jars were not on the classpath, as also turned out to be the case, or were outdated ones, as also was the case.

The interesting thing is that the whole thing worked rather well as an RPC-literal example, but fell to pieces as soon as I tried to put it into a doc-lit version. I guess the RPC is more forgiving, than the doc lit, and that it needs to be put together with more thought and attention than I was giving it.

In case anyone is wondering how JBoss works with all of these, then the answer is 'brilliantly'. It rocks!

cheers,

Bruce

[thomas.diesler]

Thanks, Bruce. Keep up the good work. You might be interested in looking at our new JBossWS stack that is targeted for jboss-5.0 and will once and for all cut the Axis umbilical cord.