Scott, I agree with you that this bug is a Sun's one, definitely not Apache SOAP, although could be compensated there
At the same time the replacing Crimson with xerces will give nothing - since, as you agreed, xerces will provide text too. Fortunately, it seems like Sun itself fixed the problem. The jars included into jwsdp 1.0.01 have slightly different package name com.sun.xml.messaging.saaj.soap ( the jar I have has package com.sun.xml.messaging.soap) and modified implementation, which does not throw exception for the TextNode under the Body. Sorry for taking so much of time on this, Best regards, Pavel > -----Original Message----- > From: Scott Nichol [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 03, 2002 4:23 PM > To: [EMAIL PROTECTED] > Subject: Re: Extra line appearing in Apache Response [SPAM] > > > This is correct behavior. The XML processor *must* pass this > information to the application. If the processor does validation, it > must also determine whether this is white space within > element content. > In either case, the application must decide what to do with it. > > Here are some relevant excerpts from XML 1.0 (Second Edition) at > http://www.w3.org/TR/2000/REC-xml-20001006. > > >>>> > 2.10 White Space Handling > > In editing XML documents, it is often convenient to use "white space" > (spaces, tabs, and blank lines) to set apart the markup for greater > readability. Such white space is typically not intended for > inclusion in > the delivered version of the document. On the other hand, > "significant" > white space that should be preserved in the delivered version > is common, > for example in poetry and source code. > An XML processor must always pass all characters in a > document that are > not markup through to the application. A validating XML processor must > also inform the application which of these characters constitute white > space appearing in element content. > > 3.2.1 Element Content > > [Definition: An element type has element content when elements of that > type must contain only child elements (no character data), optionally > separated by white space (characters matching the nonterminal S).] > > 2.3 Common Syntactic Constructs > > S (white space) consists of one or more space (#x20) characters, > carriage returns, line feeds, or tabs. > > <<<< > > The SOAP body element has element content (it can only have child > elements), but white space for separation is allowed. I am wondering > whether the original parsing errors you had with Sun's > toolkit were, in > fact, a bug in that toolkit. I seem to recall seeing crimson in the > stack dump, which implies to me you are using an older toolkit, since > the current one ships with xerces. Perhaps Sun has fixed this issue > (and maybe crimson was the underlying cause). > > Scott Nichol > > ----- Original Message ----- > From: "Pavel Ausianik" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, October 03, 2002 5:27 AM > Subject: RE: Extra line appearing in Apache Response > > > > Scott, > > > > I have parsed SOAP XML document produced by Apache SOAP toolkit with > Xerces > > samples DocumentTracer. All newlines appears as characters, not > ignorable > > white space (see below). > > > > The Sun's class caused incompatibility is > > com.sun.xml.messaging.soap.dom4j.BodyElementFactory.class . The code > on the > > server, which leads to the problem looks like > > > > msg = MessageFactory.createMessage (); > > SOAPPart soapPart = msg.getSOAPPart (); > > SOAPEnvelope envelope = soapPart.getEnvelope (); // The > problem > > appears here > > SOAPBody body = envelope.getBody (); > > > > The most describing text for exception looks like > > > > java.lang.Exception: Unable to create envelope from given source: > Error on > > line 3 of document : Text nodes can't be immediate children of SOAP > Body > > Nested exception: Text nodes can't be immediate children of > SOAP Body > > > > Best regards, > > Pavel > > > > > > > setDocumentLocator(locator=org.apache.xerces.parsers.AbstractS AXParser$L > ocat > > orProxy@5b7986) > > startDocument() > > startPrefixMapping(prefix="xsi",uri="xsi") > > > startPrefixMapping(prefix="xsd",uri="http://www.w3.org/2001/XM LSchema") > > > > > startPrefixMapping(prefix="SOAP-ENV",uri="http://schemas.xmlso ap.org/soa > p/en > > velope/") > > > > > startElement(uri="http://schemas.xmlsoap.org/soap/envelope/",l ocalName=" > Enve > > lope",qname="SOAP-ENV:Envelope",attributes={}) > > characters(text="\n") > > > > > startElement(uri="http://schemas.xmlsoap.org/soap/envelope/",l ocalName=" > Body > > ",qname="SOAP-ENV:Body",attributes={}) > > characters(text="\n") > > > > > startPrefixMapping(prefix="ns1",uri="urn:xxx-com:document:xxx: rfc:functi > ons" > > ) > > > > > startElement(uri="urn:xxx:com:document:xxx:rfc:functions",loca lName="CMW > _PIF > > > _QLOGON",qname="ns1:CMW_PIF_QLOGON",attributes={{uri="http://s > chemas.xml > soap > > > .org/soap/envelope/",localName="encodingStyle",qname="SOAP-ENV > :encodingS > tyle > > ",type="CDATA",value="http://schemas.xmlsoap.org/soap/encoding/"}}) > > characters(text="\n") > > > > > startPrefixMapping(prefix="ns2",uri="http://www.w3.org/2001/XM LSchema-in > stan > > ce") > > > > > startElement(uri="",localName="MODE",qname="MODE",attributes={ > {uri="http > ://w > > > ww.w3.org/2001/XMLSchema-instance",localName="type",qname="ns2 > :type",typ > e="C > > DATA",value="xsd:int"}}) > > characters(text="2") > > endElement(uri="",localName="MODE",qname="MODE") > > endPrefixMapping(prefix="ns2") > > characters(text="\n") > > > > > startPrefixMapping(prefix="ns3",uri="http://www.w3.org/2001/XM LSchema-in > stan > > ce") > > > > > startElement(uri="",localName="QNAME",qname="QNAME",attributes > ={{uri="ht > tp:/ > > > /www.w3.org/2001/XMLSchema-instance",localName="type",qname="n > s3:type",t > ype= > > "CDATA",value="xsd:string"}}) > > characters(text="CMW_PIF_PROTOCOL_QUEUE_IN") > > endElement(uri="",localName="QNAME",qname="QNAME") > > endPrefixMapping(prefix="ns3") > > characters(text="\n") > > > > > startPrefixMapping(prefix="ns4",uri="http://www.w3.org/2001/XM LSchema-in > stan > > ce") > > > > > startElement(uri="",localName="SITETYPE",qname="SITETYPE",attr > ibutes={{u > ri=" > > > http://www.w3.org/2001/XMLSchema-instance",localName="type",qn > ame="ns4:t > ype" > > ,type="CDATA",value="xsd:string"}}) > > characters(text="GWA_01") > > endElement(uri="",localName="SITETYPE",qname="SITETYPE") > > endPrefixMapping(prefix="ns4") > > characters(text="\n") > > > > > endElement(uri="urn:xxx-com:document:xxx:rfc:functions",localN ame="CMW_P > IF_Q > > LOGON",qname="ns1:CMW_PIF_QLOGON") > > endPrefixMapping(prefix="ns1") > > characters(text="\n") > > > > > endElement(uri="http://schemas.xmlsoap.org/soap/envelope/",loc alName="Bo > dy", > > qname="SOAP-ENV:Body") > > characters(text="\n") > > > > > endElement(uri="http://schemas.xmlsoap.org/soap/envelope/",loc alName="En > velo > > pe",qname="SOAP-ENV:Envelope") > > endPrefixMapping(prefix="SOAP-ENV") > > endPrefixMapping(prefix="xsd") > > endPrefixMapping(prefix="xsi") > > endDocument() > > > > > > > > > -----Original Message----- > > > From: Scott Nichol [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, October 02, 2002 8:10 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: Extra line appearing in Apache Response > > > > > > > > > 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 > > > > -- > > 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]>
