You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@xml.apache.org by Pavel Ausianik <Pa...@epam.com> on 2002/10/03 16:06:02 UTC
RE: Extra line appearing in Apache Response [SPAM]
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:snicholnews@scottnichol.com]
> Sent: Thursday, October 03, 2002 4:23 PM
> To: soap-dev@xml.apache.org
> 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" <Pa...@epam.com>
> To: <so...@xml.apache.org>
> 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:snicholnews@scottnichol.com]
> > > Sent: Wednesday, October 02, 2002 8:10 PM
> > > To: soap-dev@xml.apache.org
> > > 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:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: Extra line appearing in Apache Response [SPAM]
Posted by Scott Nichol <sn...@scottnichol.com>.
> I agree with you that this bug is a Sun's one, definitely not Apache
> SOAP, although could be compensated there
It is tempting sometimes to make changes to maximize interoperability
across all implementations. In this case, I was hesitant because I
suspected it was a serious Sun bug, and because I found so many other
implementations that insert line separators and other white space.
> Sorry for taking so much of time on this,
Don't worry. Remember, I am a volunteer. It was my choice to spend the
time that I did researching this. For me, it's a great way to learn.
If I just sat down and read the XML spec top to bottom, I am sure I
would not have realized the significance of an element having "element
content", nor would I have noticed the exact definition of white space
(e.g. form feeds are *not* white space). It also gave me a chance to
torture myself with Sun's XML Pack ;-)
Scott Nichol
Re: Extra line appearing in Apache Response [SPAM]
Posted by Scott Nichol <sn...@scottnichol.com>.
> I agree with you that this bug is a Sun's one, definitely not Apache
> SOAP, although could be compensated there
It is tempting sometimes to make changes to maximize interoperability
across all implementations. In this case, I was hesitant because I
suspected it was a serious Sun bug, and because I found so many other
implementations that insert line separators and other white space.
> Sorry for taking so much of time on this,
Don't worry. Remember, I am a volunteer. It was my choice to spend the
time that I did researching this. For me, it's a great way to learn.
If I just sat down and read the XML spec top to bottom, I am sure I
would not have realized the significance of an element having "element
content", nor would I have noticed the exact definition of white space
(e.g. form feeds are *not* white space). It also gave me a chance to
torture myself with Sun's XML Pack ;-)
Scott Nichol
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>