I will have to look into Sun's implementation further. In reviewing the interop tests for Apache SOAP clients (http://www.apache.org/~rubys/ApacheClientInterop.html), I see that Apache SOAP works successfully with the server Sun supplies for interop testing. Further, while some implementations eschew line separation (e.g. ASP.NET, Sun), many others use it. Given this, it's hard to view the use of line separators in Apache SOAP as an interop issue. I do see it as a performance issue, as they make the payload heavier and have some non-zero CPU cost as well.
Scott Nichol ----- Original Message ----- From: "Pavel Ausianik" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 02, 2002 11:22 AM Subject: RE: Extra line appearing in Apache Response > Scott, > > Unfortunately your fix to RPCMessage does not solve compatibility problem I > have with a Sun's SOAP client lib. > There is only a single new line after <SOAP-ENV:Body> and every parameter > after, and somehow it becomes significant for Sun's Body SAX handler (it > may happen it depends on SAX parser it uses). To solve this problem I had > to remove all line separator usage inside Body.unmarshall method (after > enabling back line separator in StringUtils). Fortunately seems like somehow > other elements does not affected. > > There two other really light arguments to remove all newlines: > > 1. The compiled SOAP code will be few bytes less , since compiler will use > constant everywhere were possible > 1. The resulting SOAP message is 1-2% shorter, after all newlines removal. > > Best regards, > Pavel > > > -----Original Message----- > > From: Scott Nichol [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, October 02, 2002 4:14 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Extra line appearing in Apache Response > > > > > > Likewise, I am not clear on the distinction between significant and > > insignificant whitespace and how it is controlled/defined. > > What I found > > interesting about the originally reported problem is that the line > > separators were not themselves a problem, it was a pair of consecutive > > line separators that was the problem. The second line > > separator somehow > > becomes a text node. > > > > I am going to leave in the line separators for now, since many other > > SOAP implementations use them, but I will remove the code creating the > > consecutive line separators for the sake of interop. > > > > Scott Nichol > > > > ----- Original Message ----- > > From: <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Tuesday, October 01, 2002 11:07 PM > > Subject: RE: Extra line appearing in Apache Response > > > > > > > Then it should be fixed, IMHO. This is causing interop problem. > > > > > > XML spec talks about significant and insignificant white space. > > > I am not clear on this. What does SOAP spec mandate -- looked > > > like SUN's SOAP server implementation goes by a strict XML schema. > > > > > > Soumen Sarkar. > > > > > > -----Original Message----- > > > From: Scott Nichol [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, October 01, 2002 8:07 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: Extra line appearing in Apache Response > > > > > > > > > > In order to fix the problem for myself, I had to download Apache > > SOAP > > > > sources and edit class org.apache.soap.util.StringUtils, replacing > > > > > > > > public static final String lineSeparator = > > > > System.getProperty("line.separator", "\n"); > > > > > > > > with an easy > > > > > > > > public static final String lineSeparator = ""; > > > > > > > > Then I had to recomplie SOAP lib, and use custom buit jar. This > > solved > > > my > > > > problem completely. Now I wonder, what is the specific reason to > > > insert new > > > > lines? > > > > > > It is just for readability, which means it is only useful when you > > have > > > to debug. > > > > > > Scott Nichol > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
