[prev in list] [next in list] [prev in thread] [next in thread] 

List:       soap-user
Subject:    Re: AW: Problem with Deployment
From:       tamminga () us ! ibm ! com
Date:       2000-06-29 18:05:40
[Download RAW message or body]


Hi,
I have a few comments and ideas about this.

>Gerhard wrote...
>Unfortunatly there are dozens of reasons why this could happen :-)
>or :-(
>e.g. don't use Xerces 1.1.1 but Xerces 1.0.3

>Have a look at the dissussion forum at
>http://www.alphaworks.ibm.com/tech/soap4j

>There somebody wrote an simple install guide (attatchment).

I like Gerhard's Xerces 1.1.1 theory a lot. If it were me that's the first
thing i'd check.

>Didn't test it but some steps could be done more
>easily:
>First I don't think the patching of XML.jar as described has to
>be done that way. I only edited the classpath in Tomcat's startup.bat so
>that the new xml.jar came before tomcat's classes.

Yes, this is exactly right. Older versions of xml4j.jar contained the whole
xml processor. When xml4j became Xerces, many of the com.ibm... classes
became org.apache... For compatiblity, xml4j provided a new version of
xml4j.jar which just has the com.ibm.xml.parser.* class implementations
that just delegate to their org.apache... counterparts. At the same time
(or shortly thereafter) xerces went to DOM level 2, which is required by
xml-soap. so xerces,jar must be ahead of the old xml4j.jar to get DOM level
2 (otherwise xml-soap gives you the No Such Method Error) and the new
xml4j.jar must be ahead of the old xml4j.jar (actually the old xml4j.jar
can be removed) to get the compatiblity version of the parser classes (
don't think this is required for xml-soap, but may be required for other
tools relying on xml4j). But it is not necessary to patch any jars, in my
experience.

The install guide also talks about pinging your JSP processor, but since
Dan is getting a serializer not found error, I reckon that his JSP
processor is working just fine.

>Second, deployment can be done by commandline. This uses the
>DescriptionDeployment.xml-files directly so you can't type anything
wrongly.
>The exact command can be found in only (!) one README file (think it was
>the address example).

Yes, and deploying from the command line (which I think is what Dan is
doing) supercedes the rest of the info in the install guide. BTW the
command line deployer tool is documented in the release notes.

>MfG
>Gerhard

>>Dan wrote...
>> When I try to deploy one of the sample applications using the
>> command line tool I get:
>>
>> Fault Code = SOAP-ENV:Client
>> Fault String = No Deserializer found to deserialize a
>> 'http://schemas.xmlsoap.org/soap/envelope:Parameter' using
>> encoding style 'null'
>>
You might try using the TCPTunnel tool (Documented in the Release notes) to
see the actual HTTP request that is being sent to the back end. This tool
is easy to use and very helpful. When I deploy the address book sample
through the tunnel I get the following:

---Begin HTTP Request---
POST /xml-soap/rpcrouter.jsp HTTP/1.0
Host: localhost:81
Content-Type: text/xml
Content-Length: 2511
SOAPAction: ""

<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/1999/XMLSchema/instance/"
xmlns:xsd="http://www.w3.org/1999/XMLSchema/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<ns1:deploy xmlns:ns1="urn:ibm-soap-service-management-service"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<descriptor xmlns:ns2="http://xml.apache.org/xml-soap"
xsi:type="ns2:DeploymentDescriptor">
    ...
</descriptor>
</ns1:deploy>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
----END HTTP Request------

Take note of the "
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"'
attribute on the <ns1:deploy> tag, and also take note of (for example) the
<descriptor> tag. The SOAP back end uses the tag name and the encoding
style as keys to find the class name of the Deserializer that knows how to
transform the given tag into an object.

Now perhaps we can understand Dan's error message better. It looks like the
back end thinks the encoding style is null, and the tag is
http://schemas.xmlsoap.org/soap/envelope:Parameter. At first I thought that
the HTTP request might be corrupt, but with clues from Gerhard and a bit
more thought I really like the buggy parser theory. Soap back end does
indeed have a built in deserializer for Parameter and it also uses a
namespace of  http://schemas.xmlsoap.org/soap/envelope. It seems plausible
that the parser might be garbling this valid information as it hands it to
the back end.

Anyway, I hope this gives Dan a few things to check and try.

Paul W. Tamminga

[prev in list] [next in list] [prev in thread] [next in thread]