xml-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven J. McDowall" <sjmcdow...@uswest.net>
Subject RE: i18n (was: rpcrouter servlet committed)
Date Tue, 08 Aug 2000 13:43:35 GMT

Couple of points to the release (having only glanced at the code)

1) Wouter is right and that my version would allow for the charset to
be properly "used" (req.getReader()) . The current version goes back a
step due to the explicit check of the contentType to only text/xml.
If you want to test text/xml (and really, why bother since if it is NOT
xml the xplRead will throw up anyway) you will need to parse it on
multiple entries seperated by ";" and check to see if either one is
text/xml .. or assume the first is text/xml and do a substr checked.
So, do we really want to check for text/xml ? If so, how much effort
should we put into doing it "right"?

2) It IS proper to emit utf-8 all the time. That is the recommended
charset standard from w3c.

3) Since all HTTP headers MUST be emitted first, if anyone can think of
another way to figure out the reply size before it's done, I'm all ears! :-)
The only other option is to store the response to a file first, then read it
in back..but that's almost worst IMHO.

4) To be honest, I really don't like the structure of the current version
versus what I submitted, specifically having the "whole" thing dumped into
doPost.. I took some time and split the logic into what I thought were
pretty nice "sub-packages" to make the code easier to figure out and
enhancece .. I think we took a step backward here ...

5) Since the get/set attribute stuff you're using isn't in my version
of the Servlet manual (doh!) I can only assume we're using a later
SDK than 1.1? (or is it 2.1? whatever).. Have to get a new API spec :-)

6) Hmm.. I am not sure why you didn't think I handled scipts? The logic
was certainly in there to load BSF, etc. etc.

7) And yes... We need to better capture in try/catch logic more faults and
issue, whenever possible, SOAP Faults back to the client..

However, all that being said, we now have version 0.1 in CVS with the
headers! So, shouldn't be a problem cleaning it up a bit..


-----Original Message-----
From: Wouter Cloetens [mailto:wcloeten@raleigh.ibm.com]
Sent: Monday, August 07, 2000 4:29 PM
To: soap-dev@xml.apache.org
Subject: i18n (was: rpcrouter servlet committed)

On Tue, 8 Aug 2000 02:33:00 -0400, Sanjiva Weerawarana wrote:

>I have committed a servlet version of rpcrouter.jsp - see

>- used Steven McDowall's UTF8 stuff to better support I18N
>  (is it correct to always set the outgoing content type to UTF8??)

I've been working on i18n support over the weekend in my multipart mime
implementation. That turned out to be quite a job. The charset modifier
needs to be
picked up by the server as well as the client, and set by the client too.
This version of the
servlet only accepts client requests without a character set specified.
Getting a Reader
and a Writer from the HttpServlet{Request|Response} object breaks the
character set
too. Steven's version correctly uses an OutputStream instead of a Writer,
and writes the
content, encoded as UTF-8, to a byte array, but it won't be able to read

The multipart issue added considerably additional complexity to that. OTOH,
I did use
some of JavaMail's functionality to parse Content-Type headers and map Mime
character set names to Java's. I'm a bit busy this week, but I'll probably
port my patches
back to the base version and publish them over the weekend.

Also, the servlet still has the problem I mentioned earlier - the try block
catching SOAP
exceptions and returning valid SOAP error responses should be expanded to
returning the response. It's happened many, many times to me that erroneous
processing resulted in a Xerces exception on the client side as it tries to
parse an HTML
response. The check for the text/xml content type should probably be in the
client code
too, that would fix responses from a server that can't even correctly
execute the servlet.

>I haven't put in Steven's content-length code in there yet. Is the
>only way to buffer the results and then count and send? Seems
>expensive .. however, maybe that's the only way.

It does more than count the bytes... It's the only way to get the response
encoded as

bfn, Wouter
My opinions are irrelevant. They will be assimilated by my employer.

View raw message