You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@ws.apache.org by "Singleton, Owen" <ow...@csg.ch> on 2001/01/17 10:26:19 UTC

RE: Slightly different content type error with new soap-nightly.j ar

Wouter/Dug,

I'm using JavaMail 1.2 from Sun downloaded from Sun's website last week.  

I've downloaded the latest, latest soap.jar and the new Mime sample code and am no longer getting the server side "java.io.IOException: 
Message is empty!" error but the "Missing content type" has reappeared.

I've got a variety of JDK versions available so I'll try to see if the error occurs on an earlier version.  I should be really working against JDK 1.1.8 (not 1.3.0) as that's where our production machines are at.

Thanks for posting the nightly source - saves me from figuring out how to get CVS working through the firewall.

Owen
-----Original Message-----
From: wcloeten@raleigh.ibm.com [mailto:wcloeten@raleigh.ibm.com]
Sent: mardi 16 janvier 2001 23:55
To: Owen Singleton; soap-user@xml.apache.org
Subject: Re: Slighlty different content type error with new
soap-nightly.jar


AH! Gravity's pulling on my penny here.

On Tue, 16 Jan 2001 16:23:53 +0100, Singleton, Owen wrote:
[...]
java.io.IOException: Message is empty!
>at org.apache.soap.server.http.RPCRouterServlet.doPost(RPCRouterServlet.java:337)
[...]

Right, that's a bug. Faults do not get generated properly. Shinta
reported it too. Dug and I just fixed it and are testing it before we
commit. There should be a fixed version up later today.

Something hit me, reading through your posts though:

>-------------------------------------------------------------------------------
>Request Message
>------------------------------------------------------------------------------
>
>POST /soap/servlet/rpcrouter HTTP/1.0 
>Host: localhost:8010 
>Content-Type: multipart/related; ; type="text/xml"; start="3708984.979661619847.apache-soap.osinglet.luxdev" 

OK, notice the: boundary="...." missing, which is causing your
problem...

>Content-Length: 73622 
>SOAPAction: ""  
>
>------=_Part_0_6631688.979661619693 
HA! There we go! Your boundary string has an "=" sign in it! That may
be what's throwing off my parsing code and screwing up the Content-Type
header.

This is what a unique boundary value, generated by JavaMail, looks like
on my system:
"201553.979685070526.JavaMail.wcloeten@roadkill.greenock.uk.ibm.com".

This comment is copied from the JavaMail source:
// Unique string is <hashcode>.<currentTime>.JavaMail.<suffix>
where <suffix> is the userid@hostname of the local system, and
<hashcode> is a hash code for some random new object. You can tell that
I've followed JavaMail's example when I wrote code to generate random
unique Content-ID strings.

Needless to say, I am stupefied by the format your boundary string.
Could you tell me precisely where you got your version of JavaMail? Do
you have it as part of the J2EE or something?

With a bit of luck, all I need to do is change some of my own parsing
code, but I'd really like to know the full story...

bfn, Wouter
--
http://www.workspot.net/~zombie/soap/
My opinions are irrelevant. They will be assimilated by my employer.


---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org

This message is for the named person's use only.  It may contain 
confidential, proprietary or legally privileged information.  No 
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender.  You must not, directly or indirectly, use, disclose, distribute, 
print, or copy any part of this message if you are not the intended 
recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve
the right to monitor all e-mail communications through its networks.  Any
views expressed in this message are those of the individual sender, except
where the message states otherwise and the sender is authorised to state 
them to be the views of any such entity.