You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@synapse.apache.org by Jeff Davis <jd...@idalica.com> on 2008/03/27 03:37:36 UTC

Interesting problem introduced by CDATA section

I'm attempting to access a SOAP web service that, unfortunately, uses a
CDATA section within the body of the XML (this wasn't my choosing, :-). The
abbreviated XML looks like:

<env:Envelope xmlns:env="http://www.xxx.com/hrit/envelope"
    xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
    xmlns:datetime="http://exslt.org/dates-and-times">
    <env:Sender>
        <env:id>test</env:id>
    </env:Sender>

    <env:Packet>
        <env:PacketInfo packetType="data">
            <env:packetId>1</env:packetId>
        </env:PacketInfo>
        <env:payload><![CDATA[
<Candidate xmlns="http://ns.hr-xml.org/2004-08-02" >
<test>
    <info>this is a test</info>
</test>]]></env:payload>
    </env:Packet>
</env:Envelope>

The issue I encounter is that, when this is sent out by Synapse, it appears
as (not showing the soap wrapper):

<env:Envelope xmlns:hrxml="http://ns.hr-xml.org/2004-08-02" xmlns:datetime="
http://exslt.org/dates-and-times">
    <env:Sender>
        <env:id>test</env:id>
    </env:Sender>

    <env:Packet>
        <env:PacketInfo packetType="data">
            <env:packetId>1</env:packetId>
        </env:PacketInfo>
        <env:payload>
            &lt;Candidate xmlns="http://ns.hr-xml.org/2004-08-02" xmlns:oa="
http://www.openapplications.org/oagis" xmlns:ds="
http://www.w3.org/2000/09/xmldsig#">
            &lt;test>
            &lt;info>this is a test&lt;/info>
            &lt;/test></env:payload>
    </env:Packet>
</env:Envelope>

Notice the CDATA section has disappeared, and the unwanted &lt; appear in
lieu of the < within that. Researching the issue a bit, I discovered this is
the expected behavior from Saxon (which I believe is the XSTL being used by
Synapse). I can reproduce this if I just use a blank stylesheet. Now, if I
apply this stylesheet and run it through Saxon manually, it works great:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="
2.0"  xmlns:env="http://www.xxx.com/hrit/envelope">
    <xsl:output use-character-maps="xml"
cdata-section-elements="env:payload"/>
    <xsl:character-map name="xml">
        <xsl:output-character character="&lt;" string="&lt;" />
        <xsl:output-character character="&gt;" string="&gt;" />
        <xsl:output-character character="&#xD;" string="&#xD;" />
        <xsl:output-character character="&#47;" string="&#47;" />
        <xsl:output-character character="&#xE0F1;" string="&lt;![CDATA["/>
        <xsl:output-character character="&#xE0F2;" string="]]>"/>
    </xsl:character-map>

        <xsl:template match="/'">
                   <xsl:copy-of select="*" />
        </xsl:template>

</xsl:stylesheet>

Unfortunately, when I plugin this stylesheet into the Synapse <in> route, it
has no apparent affect (I twiddled with it to make sure it was, in fact,
being used, and it was).

This is leaving me with a real quandary -- any suggestions?

jeff

Re: Interesting problem introduced by CDATA section

Posted by Ruwan Linton <ru...@gmail.com>.

Hi Axis2 folks,

We (synapse) have a requirement on getting the CDATA events to be reported
and serialized when the message is serialized to the transport. I think
woodstox supports the property "
http://java.sun.com/xml/stream/properties/report-cdata-event" to turn on
reporting coalescing. Is there any configuration point in axis2 where we can
activate this?

Thanks,
Ruwan

On Fri, Mar 28, 2008 at 6:55 AM, Upul Godage <up...@gmail.com> wrote:

> I tried "http://java.sun.com/xml/stream/properties/report-cdata-event"
> first, but it didn't have any effect in this instance, but I remember it
> worked earlier when creating a direct XMLInputFactory instance for use
> sometime back.
>
> Upul
>
>
> On Fri, Mar 28, 2008 at 3:13 AM, Andreas Veithen <
> andreas.veithen@skynet.be>
> wrote:
>
> > Hi all,
> >
> > I'm pretty sure that coalescing is turned of by default. I think what
> > is really needed is to activate the following property:
> >
> > "http://java.sun.com/xml/stream/properties/report-cdata-event"
> >
> > As the URI implies, this property was introduced by Sun's
> > implementation, but it seems to be supported by Woodstox as well.
> >
> > Finally, I don't think that changes to AXIOM are required. Looking at
> > the StAXUtils code, it appears that you can get a reference to the
> > XMLInputFactory by calling StAXUtils.getXMLInputFactory().
> >
> > It should be quite easy to test if this approach works. If it does we
> > need to check if Axis has support for setting properties on the
> > XMLInputFactory in its configuration file. Otherwise I suggest to add
> > support to Synapse for that.
> >
> > Andreas
> >
> > On 27 Mar 2008, at 20:17, Upul Godage wrote:
> > > In AXIOM StAXUtils class when creating XMLInputFactory objects in
> > > getXMLInputFactory() methods, (which are used by different
> > > createXMLStreamReader() methods,) it can be instructed to preserve
> > > CDATA as
> > > CDATA by the following statement.
> > > xmlInputFactory.setProperty(XMLInputFactory.IS_COALESCING,
> > > Boolean.FALSE);
> > > But AXIOM code has to be changed for that.
> > >
> > > Upul
> > >
> > > On Thu, Mar 27, 2008 at 9:00 PM, Jeff Davis <jd...@idalica.com>
> > > wrote:
> > >
> > >> I suppose one horrible hack I could employ would be to use a Ruby
> > >> script
> > >> or
> > >> Java class to post it as a regular HTTP post and then simply not
> > >> specify a
> > >> send element so that it doesn't get posted from Synapse?
> > >>
> > >> jeff
> > >>
> > >> On Thu, Mar 27, 2008 at 9:25 AM, Jeff Davis <jd...@idalica.com>
> > >> wrote:
> > >>
> > >>> I played around with a jRuby script that adds the CDATA segment
> > >>> back,
> > >> but
> > >>> unfortunately, when the XML is sent out, it again resorts to the
> > >>> other
> > >>> behavior (this is probably an obvious thing to you guys,but I'm
> > >>> not as
> > >>> familiar with the inner workings of Synapse). It sounds like I
> > >>> might be
> > >> out
> > >>> of luck here, and as someone pointed earlier, it's not an issue with
> > >>> Synapse, per se, but an erroneously design web service.
> > >>>
> > >>> I take it there is no way to send back a "raw" request, whereby no
> > >>> XML
> > >>> processing is done (basically posts a string, as-is).
> > >>>
> > >>> jeff
> > >>>
> > >>>
> > >>> On Thu, Mar 27, 2008 at 8:51 AM, Paul Fremantle <pz...@gmail.com>
> > >> wrote:
> > >>>
> > >>>> Is there a way we can create a mediator that reconverts back to a
> > >>>> CDATA? I've played around a bit with Axiom, but it seems a little
> > >>>> tricky to force CDATA.
> > >>>>
> > >>>> Paul
> > >>>>
> > >>>> ---------- Forwarded message ----------
> > >>>> From: Paul Fremantle <pz...@gmail.com>
> > >>>> Date: Thu, Mar 27, 2008 at 2:19 PM
> > >>>> Subject: Re: Interesting problem introduced by CDATA section
> > >>>> To: user@synapse.apache.org
> > >>>>
> > >>>>
> > >>>> Jeff
> > >>>>
> > >>>> The annoying answer is that the service is wrong - its an XML error
> > >> to
> > >>>> differentiate between those two XMLs.
> > >>>> However, we'll see if there is a way to sort this out.
> > >>>>
> > >>>> Paul
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Thu, Mar 27, 2008 at 4:28 AM, Jeff Davis <jd...@idalica.com>
> > >> wrote:
> > >>>>> Well, the problem is that the web service receiving the request
> > >>>> validates
> > >>>>> it, and they have it setup on their side so that if the CDATA
> > >> isnt'
> > >>>> present,
> > >>>>> the service call fails because of validation errors. I have to
> > >> have
> > >>>> that
> > >>>>> present or it won't work (it's a partner's service).
> > >>>>>
> > >>>>> jeff
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Wed, Mar 26, 2008 at 10:05 PM, Upul Godage <upulg.dev@gmail.com
> > >>>
> > >>>> wrote:
> > >>>>>
> > >>>>>> Content wise there is no difference between CDATA sections and
> > >> the
> > >>>>>> resultant
> > >>>>>> escaped text data.  < cannot be in parsed character data so it
> > >> is
> > >>>>>> converted
> > >>>>>> to &lt; so it is not mixed up with element starting elements. I
> > >>>> think when
> > >>>>>> reading from the parser, default parser does not make a
> > >> difference
> > >>>> between
> > >>>>>> the CDATA sections and the normal text sections and the Synapse
> > >>>> sees them
> > >>>>>> as
> > >>>>>> just normal text. So the significance of CDATA markers are
> > >> dropped
> > >>>> when it
> > >>>>>> is parsed. Only the serialized form changes but the "content
> > >>>> remains
> > >>>>>> exactly
> > >>>>>> the same."
> > >>>>>>
> > >>>>>> Do you face a problem when not having it in the extact CDATA
> > >> form?
> > >>>>>>
> > >>>>>> Upul
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On Thu, Mar 27, 2008 at 8:07 AM, Jeff Davis <jd...@idalica.com>
> > >>>> wrote:
> > >>>>>>
> > >>>>>>> I'm attempting to access a SOAP web service that,
> > >> unfortunately,
> > >>>> uses a
> > >>>>>>> CDATA section within the body of the XML (this wasn't my
> > >>>> choosing, :-).
> > >>>>>>> The
> > >>>>>>> abbreviated XML looks like:
> > >>>>>>>
> > >>>>>>> <env:Envelope xmlns:env="http://www.xxx.com/hrit/envelope"
> > >>>>>>>   xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
> > >>>>>>>   xmlns:datetime="http://exslt.org/dates-and-times">
> > >>>>>>>   <env:Sender>
> > >>>>>>>       <env:id>test</env:id>
> > >>>>>>>   </env:Sender>
> > >>>>>>>
> > >>>>>>>   <env:Packet>
> > >>>>>>>       <env:PacketInfo packetType="data">
> > >>>>>>>           <env:packetId>1</env:packetId>
> > >>>>>>>       </env:PacketInfo>
> > >>>>>>>       <env:payload><![CDATA[
> > >>>>>>> <Candidate xmlns="http://ns.hr-xml.org/2004-08-02" >
> > >>>>>>> <test>
> > >>>>>>>   <info>this is a test</info>
> > >>>>>>> </test>]]></env:payload>
> > >>>>>>>   </env:Packet>
> > >>>>>>> </env:Envelope>
> > >>>>>>>
> > >>>>>>> The issue I encounter is that, when this is sent out by
> > >> Synapse,
> > >>>> it
> > >>>>>>> appears
> > >>>>>>> as (not showing the soap wrapper):
> > >>>>>>>
> > >>>>>>> <env:Envelope xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
> > >>>>>>> xmlns:datetime="
> > >>>>>>> http://exslt.org/dates-and-times">
> > >>>>>>>   <env:Sender>
> > >>>>>>>       <env:id>test</env:id>
> > >>>>>>>   </env:Sender>
> > >>>>>>>
> > >>>>>>>   <env:Packet>
> > >>>>>>>       <env:PacketInfo packetType="data">
> > >>>>>>>           <env:packetId>1</env:packetId>
> > >>>>>>>       </env:PacketInfo>
> > >>>>>>>       <env:payload>
> > >>>>>>>           &lt;Candidate xmlns="
> > >> http://ns.hr-xml.org/2004-08-02"
> > >>>>>>> xmlns:oa="
> > >>>>>>> http://www.openapplications.org/oagis" xmlns:ds="
> > >>>>>>> http://www.w3.org/2000/09/xmldsig#">
> > >>>>>>>           &lt;test>
> > >>>>>>>           &lt;info>this is a test&lt;/info>
> > >>>>>>>           &lt;/test></env:payload>
> > >>>>>>>   </env:Packet>
> > >>>>>>> </env:Envelope>
> > >>>>>>>
> > >>>>>>> Notice the CDATA section has disappeared, and the unwanted
> > >> &lt;
> > >>>> appear
> > >>>>>> in
> > >>>>>>> lieu of the < within that. Researching the issue a bit, I
> > >>>> discovered
> > >>>>>> this
> > >>>>>>> is
> > >>>>>>> the expected behavior from Saxon (which I believe is the XSTL
> > >>>> being used
> > >>>>>>> by
> > >>>>>>> Synapse). I can reproduce this if I just use a blank
> > >> stylesheet.
> > >>>> Now, if
> > >>>>>> I
> > >>>>>>> apply this stylesheet and run it through Saxon manually, it
> > >>>> works great:
> > >>>>>>>
> > >>>>>>> <xsl:stylesheet xmlns:xsl="
> > >> http://www.w3.org/1999/XSL/Transform"
> > >>>>>> version="
> > >>>>>>> 2.0"  xmlns:env="http://www.xxx.com/hrit/envelope">
> > >>>>>>>   <xsl:output use-character-maps="xml"
> > >>>>>>> cdata-section-elements="env:payload"/>
> > >>>>>>>   <xsl:character-map name="xml">
> > >>>>>>>       <xsl:output-character character="&lt;" string="&lt;" />
> > >>>>>>>       <xsl:output-character character="&gt;" string="&gt;" />
> > >>>>>>>       <xsl:output-character character="&#xD;" string="&#xD;"
> > >> />
> > >>>>>>>       <xsl:output-character character="&#47;" string="&#47;"
> > >> />
> > >>>>>>>       <xsl:output-character character="&#xE0F1;"
> > >>>>>> string="&lt;![CDATA["/>
> > >>>>>>>       <xsl:output-character character="&#xE0F2;"
> > >> string="]]>"/>
> > >>>>>>>   </xsl:character-map>
> > >>>>>>>
> > >>>>>>>       <xsl:template match="/'">
> > >>>>>>>                  <xsl:copy-of select="*" />
> > >>>>>>>       </xsl:template>
> > >>>>>>>
> > >>>>>>> </xsl:stylesheet>
> > >>>>>>>
> > >>>>>>> Unfortunately, when I plugin this stylesheet into the Synapse
> > >>>> <in>
> > >>>>>> route,
> > >>>>>>> it
> > >>>>>>> has no apparent affect (I twiddled with it to make sure it
> > >> was,
> > >>>> in fact,
> > >>>>>>> being used, and it was).
> > >>>>>>>
> > >>>>>>> This is leaving me with a real quandary -- any suggestions?
> > >>>>>>>
> > >>>>>>> jeff
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Jeff Davis
> > >>>>> Senior Architect
> > >>>>> Idalica Corporation
> > >>>>> MSN: jeffdavis_ca@hotmail.com
> > >>>>> Skype: jeffdavis_ca
> > >>>>> Phone: 719-287-8656
> > >>>>> Enabling Business Through Open Source Technologies
> > >>>>> www.idalica.com
> > >>>>>
> > >>>>> IMPORTANT: This electronic message is for exclusive use by the
> > >>>> person(s) to
> > >>>>> whom it is addressed, and may contain information that is
> > >>>> confidential or
> > >>>>> privileged and exempt from disclosure under applicable law. If you
> > >>>> are not
> > >>>>> an intended recipient, please be aware that any disclosure,
> > >>>> dissemination,
> > >>>>> distribution or copying of this communication, or the use of its
> > >>>> contents,
> > >>>>> is prohibited. If you have received this message in error, please
> > >>>>> immediately notify the sender of your inadvertent receipt and
> > >> delete
> > >>>> this
> > >>>>> message from all data storage systems.
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Paul Fremantle
> > >>>> Co-Founder and VP of Technical Sales, WSO2
> > >>>> Apache Synapse PMC Chair
> > >>>> OASIS WS-RX TC Co-chair
> > >>>>
> > >>>> blog: http://pzf.fremantle.org
> > >>>> paul@wso2.com
> > >>>>
> > >>>> "Oxygenating the Web Service Platform", www.wso2.com
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Paul Fremantle
> > >>>> Co-Founder and VP of Technical Sales, WSO2
> > >>>> Apache Synapse PMC Chair
> > >>>> OASIS WS-RX TC Co-chair
> > >>>>
> > >>>> blog: http://pzf.fremantle.org
> > >>>> paul@wso2.com
> > >>>>
> > >>>> "Oxygenating the Web Service Platform", www.wso2.com
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Jeff Davis
> > >>> Senior Architect
> > >>> Idalica Corporation
> > >>> MSN: jeffdavis_ca@hotmail.com
> > >>> Skype: jeffdavis_ca
> > >>> Phone: 719-287-8656
> > >>> Enabling Business Through Open Source Technologies
> > >>> www.idalica.com
> > >>>
> > >>> IMPORTANT: This electronic message is for exclusive use by the
> > >>> person(s)
> > >>> to whom it is addressed, and may contain information that is
> > >> confidential or
> > >>> privileged and exempt from disclosure under applicable law. If you
> > >>> are
> > >> not
> > >>> an intended recipient, please be aware that any disclosure,
> > >> dissemination,
> > >>> distribution or copying of this communication, or the use of its
> > >> contents,
> > >>> is prohibited. If you have received this message in error, please
> > >>> immediately notify the sender of your inadvertent receipt and delete
> > >> this
> > >>> message from all data storage systems.
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Jeff Davis
> > >> Senior Architect
> > >> Idalica Corporation
> > >> MSN: jeffdavis_ca@hotmail.com
> > >> Skype: jeffdavis_ca
> > >> Phone: 719-287-8656
> > >> Enabling Business Through Open Source Technologies
> > >> www.idalica.com
> > >>
> > >> IMPORTANT: This electronic message is for exclusive use by the
> > >> person(s)
> > >> to
> > >> whom it is addressed, and may contain information that is
> > >> confidential or
> > >> privileged and exempt from disclosure under applicable law. If you
> > >> are not
> > >> an intended recipient, please be aware that any disclosure,
> > >> dissemination,
> > >> distribution or copying of this communication, or the use of its
> > >> contents,
> > >> is prohibited. If you have received this message in error, please
> > >> immediately notify the sender of your inadvertent receipt and
> > >> delete this
> > >> message from all data storage systems.
> > >>
> >
> >
>



-- 
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"

Re: Interesting problem introduced by CDATA section

Posted by Ruwan Linton <ru...@gmail.com>.

Hi Axis2 folks,

We (synapse) have a requirement on getting the CDATA events to be reported
and serialized when the message is serialized to the transport. I think
woodstox supports the property "
http://java.sun.com/xml/stream/properties/report-cdata-event" to turn on
reporting coalescing. Is there any configuration point in axis2 where we can
activate this?

Thanks,
Ruwan

On Fri, Mar 28, 2008 at 6:55 AM, Upul Godage <up...@gmail.com> wrote:

> I tried "http://java.sun.com/xml/stream/properties/report-cdata-event"
> first, but it didn't have any effect in this instance, but I remember it
> worked earlier when creating a direct XMLInputFactory instance for use
> sometime back.
>
> Upul
>
>
> On Fri, Mar 28, 2008 at 3:13 AM, Andreas Veithen <
> andreas.veithen@skynet.be>
> wrote:
>
> > Hi all,
> >
> > I'm pretty sure that coalescing is turned of by default. I think what
> > is really needed is to activate the following property:
> >
> > "http://java.sun.com/xml/stream/properties/report-cdata-event"
> >
> > As the URI implies, this property was introduced by Sun's
> > implementation, but it seems to be supported by Woodstox as well.
> >
> > Finally, I don't think that changes to AXIOM are required. Looking at
> > the StAXUtils code, it appears that you can get a reference to the
> > XMLInputFactory by calling StAXUtils.getXMLInputFactory().
> >
> > It should be quite easy to test if this approach works. If it does we
> > need to check if Axis has support for setting properties on the
> > XMLInputFactory in its configuration file. Otherwise I suggest to add
> > support to Synapse for that.
> >
> > Andreas
> >
> > On 27 Mar 2008, at 20:17, Upul Godage wrote:
> > > In AXIOM StAXUtils class when creating XMLInputFactory objects in
> > > getXMLInputFactory() methods, (which are used by different
> > > createXMLStreamReader() methods,) it can be instructed to preserve
> > > CDATA as
> > > CDATA by the following statement.
> > > xmlInputFactory.setProperty(XMLInputFactory.IS_COALESCING,
> > > Boolean.FALSE);
> > > But AXIOM code has to be changed for that.
> > >
> > > Upul
> > >
> > > On Thu, Mar 27, 2008 at 9:00 PM, Jeff Davis <jd...@idalica.com>
> > > wrote:
> > >
> > >> I suppose one horrible hack I could employ would be to use a Ruby
> > >> script
> > >> or
> > >> Java class to post it as a regular HTTP post and then simply not
> > >> specify a
> > >> send element so that it doesn't get posted from Synapse?
> > >>
> > >> jeff
> > >>
> > >> On Thu, Mar 27, 2008 at 9:25 AM, Jeff Davis <jd...@idalica.com>
> > >> wrote:
> > >>
> > >>> I played around with a jRuby script that adds the CDATA segment
> > >>> back,
> > >> but
> > >>> unfortunately, when the XML is sent out, it again resorts to the
> > >>> other
> > >>> behavior (this is probably an obvious thing to you guys,but I'm
> > >>> not as
> > >>> familiar with the inner workings of Synapse). It sounds like I
> > >>> might be
> > >> out
> > >>> of luck here, and as someone pointed earlier, it's not an issue with
> > >>> Synapse, per se, but an erroneously design web service.
> > >>>
> > >>> I take it there is no way to send back a "raw" request, whereby no
> > >>> XML
> > >>> processing is done (basically posts a string, as-is).
> > >>>
> > >>> jeff
> > >>>
> > >>>
> > >>> On Thu, Mar 27, 2008 at 8:51 AM, Paul Fremantle <pz...@gmail.com>
> > >> wrote:
> > >>>
> > >>>> Is there a way we can create a mediator that reconverts back to a
> > >>>> CDATA? I've played around a bit with Axiom, but it seems a little
> > >>>> tricky to force CDATA.
> > >>>>
> > >>>> Paul
> > >>>>
> > >>>> ---------- Forwarded message ----------
> > >>>> From: Paul Fremantle <pz...@gmail.com>
> > >>>> Date: Thu, Mar 27, 2008 at 2:19 PM
> > >>>> Subject: Re: Interesting problem introduced by CDATA section
> > >>>> To: user@synapse.apache.org
> > >>>>
> > >>>>
> > >>>> Jeff
> > >>>>
> > >>>> The annoying answer is that the service is wrong - its an XML error
> > >> to
> > >>>> differentiate between those two XMLs.
> > >>>> However, we'll see if there is a way to sort this out.
> > >>>>
> > >>>> Paul
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Thu, Mar 27, 2008 at 4:28 AM, Jeff Davis <jd...@idalica.com>
> > >> wrote:
> > >>>>> Well, the problem is that the web service receiving the request
> > >>>> validates
> > >>>>> it, and they have it setup on their side so that if the CDATA
> > >> isnt'
> > >>>> present,
> > >>>>> the service call fails because of validation errors. I have to
> > >> have
> > >>>> that
> > >>>>> present or it won't work (it's a partner's service).
> > >>>>>
> > >>>>> jeff
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Wed, Mar 26, 2008 at 10:05 PM, Upul Godage <upulg.dev@gmail.com
> > >>>
> > >>>> wrote:
> > >>>>>
> > >>>>>> Content wise there is no difference between CDATA sections and
> > >> the
> > >>>>>> resultant
> > >>>>>> escaped text data.  < cannot be in parsed character data so it
> > >> is
> > >>>>>> converted
> > >>>>>> to &lt; so it is not mixed up with element starting elements. I
> > >>>> think when
> > >>>>>> reading from the parser, default parser does not make a
> > >> difference
> > >>>> between
> > >>>>>> the CDATA sections and the normal text sections and the Synapse
> > >>>> sees them
> > >>>>>> as
> > >>>>>> just normal text. So the significance of CDATA markers are
> > >> dropped
> > >>>> when it
> > >>>>>> is parsed. Only the serialized form changes but the "content
> > >>>> remains
> > >>>>>> exactly
> > >>>>>> the same."
> > >>>>>>
> > >>>>>> Do you face a problem when not having it in the extact CDATA
> > >> form?
> > >>>>>>
> > >>>>>> Upul
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On Thu, Mar 27, 2008 at 8:07 AM, Jeff Davis <jd...@idalica.com>
> > >>>> wrote:
> > >>>>>>
> > >>>>>>> I'm attempting to access a SOAP web service that,
> > >> unfortunately,
> > >>>> uses a
> > >>>>>>> CDATA section within the body of the XML (this wasn't my
> > >>>> choosing, :-).
> > >>>>>>> The
> > >>>>>>> abbreviated XML looks like:
> > >>>>>>>
> > >>>>>>> <env:Envelope xmlns:env="http://www.xxx.com/hrit/envelope"
> > >>>>>>>   xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
> > >>>>>>>   xmlns:datetime="http://exslt.org/dates-and-times">
> > >>>>>>>   <env:Sender>
> > >>>>>>>       <env:id>test</env:id>
> > >>>>>>>   </env:Sender>
> > >>>>>>>
> > >>>>>>>   <env:Packet>
> > >>>>>>>       <env:PacketInfo packetType="data">
> > >>>>>>>           <env:packetId>1</env:packetId>
> > >>>>>>>       </env:PacketInfo>
> > >>>>>>>       <env:payload><![CDATA[
> > >>>>>>> <Candidate xmlns="http://ns.hr-xml.org/2004-08-02" >
> > >>>>>>> <test>
> > >>>>>>>   <info>this is a test</info>
> > >>>>>>> </test>]]></env:payload>
> > >>>>>>>   </env:Packet>
> > >>>>>>> </env:Envelope>
> > >>>>>>>
> > >>>>>>> The issue I encounter is that, when this is sent out by
> > >> Synapse,
> > >>>> it
> > >>>>>>> appears
> > >>>>>>> as (not showing the soap wrapper):
> > >>>>>>>
> > >>>>>>> <env:Envelope xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
> > >>>>>>> xmlns:datetime="
> > >>>>>>> http://exslt.org/dates-and-times">
> > >>>>>>>   <env:Sender>
> > >>>>>>>       <env:id>test</env:id>
> > >>>>>>>   </env:Sender>
> > >>>>>>>
> > >>>>>>>   <env:Packet>
> > >>>>>>>       <env:PacketInfo packetType="data">
> > >>>>>>>           <env:packetId>1</env:packetId>
> > >>>>>>>       </env:PacketInfo>
> > >>>>>>>       <env:payload>
> > >>>>>>>           &lt;Candidate xmlns="
> > >> http://ns.hr-xml.org/2004-08-02"
> > >>>>>>> xmlns:oa="
> > >>>>>>> http://www.openapplications.org/oagis" xmlns:ds="
> > >>>>>>> http://www.w3.org/2000/09/xmldsig#">
> > >>>>>>>           &lt;test>
> > >>>>>>>           &lt;info>this is a test&lt;/info>
> > >>>>>>>           &lt;/test></env:payload>
> > >>>>>>>   </env:Packet>
> > >>>>>>> </env:Envelope>
> > >>>>>>>
> > >>>>>>> Notice the CDATA section has disappeared, and the unwanted
> > >> &lt;
> > >>>> appear
> > >>>>>> in
> > >>>>>>> lieu of the < within that. Researching the issue a bit, I
> > >>>> discovered
> > >>>>>> this
> > >>>>>>> is
> > >>>>>>> the expected behavior from Saxon (which I believe is the XSTL
> > >>>> being used
> > >>>>>>> by
> > >>>>>>> Synapse). I can reproduce this if I just use a blank
> > >> stylesheet.
> > >>>> Now, if
> > >>>>>> I
> > >>>>>>> apply this stylesheet and run it through Saxon manually, it
> > >>>> works great:
> > >>>>>>>
> > >>>>>>> <xsl:stylesheet xmlns:xsl="
> > >> http://www.w3.org/1999/XSL/Transform"
> > >>>>>> version="
> > >>>>>>> 2.0"  xmlns:env="http://www.xxx.com/hrit/envelope">
> > >>>>>>>   <xsl:output use-character-maps="xml"
> > >>>>>>> cdata-section-elements="env:payload"/>
> > >>>>>>>   <xsl:character-map name="xml">
> > >>>>>>>       <xsl:output-character character="&lt;" string="&lt;" />
> > >>>>>>>       <xsl:output-character character="&gt;" string="&gt;" />
> > >>>>>>>       <xsl:output-character character="&#xD;" string="&#xD;"
> > >> />
> > >>>>>>>       <xsl:output-character character="&#47;" string="&#47;"
> > >> />
> > >>>>>>>       <xsl:output-character character="&#xE0F1;"
> > >>>>>> string="&lt;![CDATA["/>
> > >>>>>>>       <xsl:output-character character="&#xE0F2;"
> > >> string="]]>"/>
> > >>>>>>>   </xsl:character-map>
> > >>>>>>>
> > >>>>>>>       <xsl:template match="/'">
> > >>>>>>>                  <xsl:copy-of select="*" />
> > >>>>>>>       </xsl:template>
> > >>>>>>>
> > >>>>>>> </xsl:stylesheet>
> > >>>>>>>
> > >>>>>>> Unfortunately, when I plugin this stylesheet into the Synapse
> > >>>> <in>
> > >>>>>> route,
> > >>>>>>> it
> > >>>>>>> has no apparent affect (I twiddled with it to make sure it
> > >> was,
> > >>>> in fact,
> > >>>>>>> being used, and it was).
> > >>>>>>>
> > >>>>>>> This is leaving me with a real quandary -- any suggestions?
> > >>>>>>>
> > >>>>>>> jeff
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Jeff Davis
> > >>>>> Senior Architect
> > >>>>> Idalica Corporation
> > >>>>> MSN: jeffdavis_ca@hotmail.com
> > >>>>> Skype: jeffdavis_ca
> > >>>>> Phone: 719-287-8656
> > >>>>> Enabling Business Through Open Source Technologies
> > >>>>> www.idalica.com
> > >>>>>
> > >>>>> IMPORTANT: This electronic message is for exclusive use by the
> > >>>> person(s) to
> > >>>>> whom it is addressed, and may contain information that is
> > >>>> confidential or
> > >>>>> privileged and exempt from disclosure under applicable law. If you
> > >>>> are not
> > >>>>> an intended recipient, please be aware that any disclosure,
> > >>>> dissemination,
> > >>>>> distribution or copying of this communication, or the use of its
> > >>>> contents,
> > >>>>> is prohibited. If you have received this message in error, please
> > >>>>> immediately notify the sender of your inadvertent receipt and
> > >> delete
> > >>>> this
> > >>>>> message from all data storage systems.
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Paul Fremantle
> > >>>> Co-Founder and VP of Technical Sales, WSO2
> > >>>> Apache Synapse PMC Chair
> > >>>> OASIS WS-RX TC Co-chair
> > >>>>
> > >>>> blog: http://pzf.fremantle.org
> > >>>> paul@wso2.com
> > >>>>
> > >>>> "Oxygenating the Web Service Platform", www.wso2.com
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Paul Fremantle
> > >>>> Co-Founder and VP of Technical Sales, WSO2
> > >>>> Apache Synapse PMC Chair
> > >>>> OASIS WS-RX TC Co-chair
> > >>>>
> > >>>> blog: http://pzf.fremantle.org
> > >>>> paul@wso2.com
> > >>>>
> > >>>> "Oxygenating the Web Service Platform", www.wso2.com
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Jeff Davis
> > >>> Senior Architect
> > >>> Idalica Corporation
> > >>> MSN: jeffdavis_ca@hotmail.com
> > >>> Skype: jeffdavis_ca
> > >>> Phone: 719-287-8656
> > >>> Enabling Business Through Open Source Technologies
> > >>> www.idalica.com
> > >>>
> > >>> IMPORTANT: This electronic message is for exclusive use by the
> > >>> person(s)
> > >>> to whom it is addressed, and may contain information that is
> > >> confidential or
> > >>> privileged and exempt from disclosure under applicable law. If you
> > >>> are
> > >> not
> > >>> an intended recipient, please be aware that any disclosure,
> > >> dissemination,
> > >>> distribution or copying of this communication, or the use of its
> > >> contents,
> > >>> is prohibited. If you have received this message in error, please
> > >>> immediately notify the sender of your inadvertent receipt and delete
> > >> this
> > >>> message from all data storage systems.
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Jeff Davis
> > >> Senior Architect
> > >> Idalica Corporation
> > >> MSN: jeffdavis_ca@hotmail.com
> > >> Skype: jeffdavis_ca
> > >> Phone: 719-287-8656
> > >> Enabling Business Through Open Source Technologies
> > >> www.idalica.com
> > >>
> > >> IMPORTANT: This electronic message is for exclusive use by the
> > >> person(s)
> > >> to
> > >> whom it is addressed, and may contain information that is
> > >> confidential or
> > >> privileged and exempt from disclosure under applicable law. If you
> > >> are not
> > >> an intended recipient, please be aware that any disclosure,
> > >> dissemination,
> > >> distribution or copying of this communication, or the use of its
> > >> contents,
> > >> is prohibited. If you have received this message in error, please
> > >> immediately notify the sender of your inadvertent receipt and
> > >> delete this
> > >> message from all data storage systems.
> > >>
> >
> >
>



-- 
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"

Re: Interesting problem introduced by CDATA section

Posted by Upul Godage <up...@gmail.com>.

I tried "http://java.sun.com/xml/stream/properties/report-cdata-event"
first, but it didn't have any effect in this instance, but I remember it
worked earlier when creating a direct XMLInputFactory instance for use
sometime back.

Upul


On Fri, Mar 28, 2008 at 3:13 AM, Andreas Veithen <an...@skynet.be>
wrote:

> Hi all,
>
> I'm pretty sure that coalescing is turned of by default. I think what
> is really needed is to activate the following property:
>
> "http://java.sun.com/xml/stream/properties/report-cdata-event"
>
> As the URI implies, this property was introduced by Sun's
> implementation, but it seems to be supported by Woodstox as well.
>
> Finally, I don't think that changes to AXIOM are required. Looking at
> the StAXUtils code, it appears that you can get a reference to the
> XMLInputFactory by calling StAXUtils.getXMLInputFactory().
>
> It should be quite easy to test if this approach works. If it does we
> need to check if Axis has support for setting properties on the
> XMLInputFactory in its configuration file. Otherwise I suggest to add
> support to Synapse for that.
>
> Andreas
>
> On 27 Mar 2008, at 20:17, Upul Godage wrote:
> > In AXIOM StAXUtils class when creating XMLInputFactory objects in
> > getXMLInputFactory() methods, (which are used by different
> > createXMLStreamReader() methods,) it can be instructed to preserve
> > CDATA as
> > CDATA by the following statement.
> > xmlInputFactory.setProperty(XMLInputFactory.IS_COALESCING,
> > Boolean.FALSE);
> > But AXIOM code has to be changed for that.
> >
> > Upul
> >
> > On Thu, Mar 27, 2008 at 9:00 PM, Jeff Davis <jd...@idalica.com>
> > wrote:
> >
> >> I suppose one horrible hack I could employ would be to use a Ruby
> >> script
> >> or
> >> Java class to post it as a regular HTTP post and then simply not
> >> specify a
> >> send element so that it doesn't get posted from Synapse?
> >>
> >> jeff
> >>
> >> On Thu, Mar 27, 2008 at 9:25 AM, Jeff Davis <jd...@idalica.com>
> >> wrote:
> >>
> >>> I played around with a jRuby script that adds the CDATA segment
> >>> back,
> >> but
> >>> unfortunately, when the XML is sent out, it again resorts to the
> >>> other
> >>> behavior (this is probably an obvious thing to you guys,but I'm
> >>> not as
> >>> familiar with the inner workings of Synapse). It sounds like I
> >>> might be
> >> out
> >>> of luck here, and as someone pointed earlier, it's not an issue with
> >>> Synapse, per se, but an erroneously design web service.
> >>>
> >>> I take it there is no way to send back a "raw" request, whereby no
> >>> XML
> >>> processing is done (basically posts a string, as-is).
> >>>
> >>> jeff
> >>>
> >>>
> >>> On Thu, Mar 27, 2008 at 8:51 AM, Paul Fremantle <pz...@gmail.com>
> >> wrote:
> >>>
> >>>> Is there a way we can create a mediator that reconverts back to a
> >>>> CDATA? I've played around a bit with Axiom, but it seems a little
> >>>> tricky to force CDATA.
> >>>>
> >>>> Paul
> >>>>
> >>>> ---------- Forwarded message ----------
> >>>> From: Paul Fremantle <pz...@gmail.com>
> >>>> Date: Thu, Mar 27, 2008 at 2:19 PM
> >>>> Subject: Re: Interesting problem introduced by CDATA section
> >>>> To: user@synapse.apache.org
> >>>>
> >>>>
> >>>> Jeff
> >>>>
> >>>> The annoying answer is that the service is wrong - its an XML error
> >> to
> >>>> differentiate between those two XMLs.
> >>>> However, we'll see if there is a way to sort this out.
> >>>>
> >>>> Paul
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Mar 27, 2008 at 4:28 AM, Jeff Davis <jd...@idalica.com>
> >> wrote:
> >>>>> Well, the problem is that the web service receiving the request
> >>>> validates
> >>>>> it, and they have it setup on their side so that if the CDATA
> >> isnt'
> >>>> present,
> >>>>> the service call fails because of validation errors. I have to
> >> have
> >>>> that
> >>>>> present or it won't work (it's a partner's service).
> >>>>>
> >>>>> jeff
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, Mar 26, 2008 at 10:05 PM, Upul Godage <upulg.dev@gmail.com
> >>>
> >>>> wrote:
> >>>>>
> >>>>>> Content wise there is no difference between CDATA sections and
> >> the
> >>>>>> resultant
> >>>>>> escaped text data.  < cannot be in parsed character data so it
> >> is
> >>>>>> converted
> >>>>>> to &lt; so it is not mixed up with element starting elements. I
> >>>> think when
> >>>>>> reading from the parser, default parser does not make a
> >> difference
> >>>> between
> >>>>>> the CDATA sections and the normal text sections and the Synapse
> >>>> sees them
> >>>>>> as
> >>>>>> just normal text. So the significance of CDATA markers are
> >> dropped
> >>>> when it
> >>>>>> is parsed. Only the serialized form changes but the "content
> >>>> remains
> >>>>>> exactly
> >>>>>> the same."
> >>>>>>
> >>>>>> Do you face a problem when not having it in the extact CDATA
> >> form?
> >>>>>>
> >>>>>> Upul
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Mar 27, 2008 at 8:07 AM, Jeff Davis <jd...@idalica.com>
> >>>> wrote:
> >>>>>>
> >>>>>>> I'm attempting to access a SOAP web service that,
> >> unfortunately,
> >>>> uses a
> >>>>>>> CDATA section within the body of the XML (this wasn't my
> >>>> choosing, :-).
> >>>>>>> The
> >>>>>>> abbreviated XML looks like:
> >>>>>>>
> >>>>>>> <env:Envelope xmlns:env="http://www.xxx.com/hrit/envelope"
> >>>>>>>   xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
> >>>>>>>   xmlns:datetime="http://exslt.org/dates-and-times">
> >>>>>>>   <env:Sender>
> >>>>>>>       <env:id>test</env:id>
> >>>>>>>   </env:Sender>
> >>>>>>>
> >>>>>>>   <env:Packet>
> >>>>>>>       <env:PacketInfo packetType="data">
> >>>>>>>           <env:packetId>1</env:packetId>
> >>>>>>>       </env:PacketInfo>
> >>>>>>>       <env:payload><![CDATA[
> >>>>>>> <Candidate xmlns="http://ns.hr-xml.org/2004-08-02" >
> >>>>>>> <test>
> >>>>>>>   <info>this is a test</info>
> >>>>>>> </test>]]></env:payload>
> >>>>>>>   </env:Packet>
> >>>>>>> </env:Envelope>
> >>>>>>>
> >>>>>>> The issue I encounter is that, when this is sent out by
> >> Synapse,
> >>>> it
> >>>>>>> appears
> >>>>>>> as (not showing the soap wrapper):
> >>>>>>>
> >>>>>>> <env:Envelope xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
> >>>>>>> xmlns:datetime="
> >>>>>>> http://exslt.org/dates-and-times">
> >>>>>>>   <env:Sender>
> >>>>>>>       <env:id>test</env:id>
> >>>>>>>   </env:Sender>
> >>>>>>>
> >>>>>>>   <env:Packet>
> >>>>>>>       <env:PacketInfo packetType="data">
> >>>>>>>           <env:packetId>1</env:packetId>
> >>>>>>>       </env:PacketInfo>
> >>>>>>>       <env:payload>
> >>>>>>>           &lt;Candidate xmlns="
> >> http://ns.hr-xml.org/2004-08-02"
> >>>>>>> xmlns:oa="
> >>>>>>> http://www.openapplications.org/oagis" xmlns:ds="
> >>>>>>> http://www.w3.org/2000/09/xmldsig#">
> >>>>>>>           &lt;test>
> >>>>>>>           &lt;info>this is a test&lt;/info>
> >>>>>>>           &lt;/test></env:payload>
> >>>>>>>   </env:Packet>
> >>>>>>> </env:Envelope>
> >>>>>>>
> >>>>>>> Notice the CDATA section has disappeared, and the unwanted
> >> &lt;
> >>>> appear
> >>>>>> in
> >>>>>>> lieu of the < within that. Researching the issue a bit, I
> >>>> discovered
> >>>>>> this
> >>>>>>> is
> >>>>>>> the expected behavior from Saxon (which I believe is the XSTL
> >>>> being used
> >>>>>>> by
> >>>>>>> Synapse). I can reproduce this if I just use a blank
> >> stylesheet.
> >>>> Now, if
> >>>>>> I
> >>>>>>> apply this stylesheet and run it through Saxon manually, it
> >>>> works great:
> >>>>>>>
> >>>>>>> <xsl:stylesheet xmlns:xsl="
> >> http://www.w3.org/1999/XSL/Transform"
> >>>>>> version="
> >>>>>>> 2.0"  xmlns:env="http://www.xxx.com/hrit/envelope">
> >>>>>>>   <xsl:output use-character-maps="xml"
> >>>>>>> cdata-section-elements="env:payload"/>
> >>>>>>>   <xsl:character-map name="xml">
> >>>>>>>       <xsl:output-character character="&lt;" string="&lt;" />
> >>>>>>>       <xsl:output-character character="&gt;" string="&gt;" />
> >>>>>>>       <xsl:output-character character="&#xD;" string="&#xD;"
> >> />
> >>>>>>>       <xsl:output-character character="&#47;" string="&#47;"
> >> />
> >>>>>>>       <xsl:output-character character="&#xE0F1;"
> >>>>>> string="&lt;![CDATA["/>
> >>>>>>>       <xsl:output-character character="&#xE0F2;"
> >> string="]]>"/>
> >>>>>>>   </xsl:character-map>
> >>>>>>>
> >>>>>>>       <xsl:template match="/'">
> >>>>>>>                  <xsl:copy-of select="*" />
> >>>>>>>       </xsl:template>
> >>>>>>>
> >>>>>>> </xsl:stylesheet>
> >>>>>>>
> >>>>>>> Unfortunately, when I plugin this stylesheet into the Synapse
> >>>> <in>
> >>>>>> route,
> >>>>>>> it
> >>>>>>> has no apparent affect (I twiddled with it to make sure it
> >> was,
> >>>> in fact,
> >>>>>>> being used, and it was).
> >>>>>>>
> >>>>>>> This is leaving me with a real quandary -- any suggestions?
> >>>>>>>
> >>>>>>> jeff
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Jeff Davis
> >>>>> Senior Architect
> >>>>> Idalica Corporation
> >>>>> MSN: jeffdavis_ca@hotmail.com
> >>>>> Skype: jeffdavis_ca
> >>>>> Phone: 719-287-8656
> >>>>> Enabling Business Through Open Source Technologies
> >>>>> www.idalica.com
> >>>>>
> >>>>> IMPORTANT: This electronic message is for exclusive use by the
> >>>> person(s) to
> >>>>> whom it is addressed, and may contain information that is
> >>>> confidential or
> >>>>> privileged and exempt from disclosure under applicable law. If you
> >>>> are not
> >>>>> an intended recipient, please be aware that any disclosure,
> >>>> dissemination,
> >>>>> distribution or copying of this communication, or the use of its
> >>>> contents,
> >>>>> is prohibited. If you have received this message in error, please
> >>>>> immediately notify the sender of your inadvertent receipt and
> >> delete
> >>>> this
> >>>>> message from all data storage systems.
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Paul Fremantle
> >>>> Co-Founder and VP of Technical Sales, WSO2
> >>>> Apache Synapse PMC Chair
> >>>> OASIS WS-RX TC Co-chair
> >>>>
> >>>> blog: http://pzf.fremantle.org
> >>>> paul@wso2.com
> >>>>
> >>>> "Oxygenating the Web Service Platform", www.wso2.com
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Paul Fremantle
> >>>> Co-Founder and VP of Technical Sales, WSO2
> >>>> Apache Synapse PMC Chair
> >>>> OASIS WS-RX TC Co-chair
> >>>>
> >>>> blog: http://pzf.fremantle.org
> >>>> paul@wso2.com
> >>>>
> >>>> "Oxygenating the Web Service Platform", www.wso2.com
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Jeff Davis
> >>> Senior Architect
> >>> Idalica Corporation
> >>> MSN: jeffdavis_ca@hotmail.com
> >>> Skype: jeffdavis_ca
> >>> Phone: 719-287-8656
> >>> Enabling Business Through Open Source Technologies
> >>> www.idalica.com
> >>>
> >>> IMPORTANT: This electronic message is for exclusive use by the
> >>> person(s)
> >>> to whom it is addressed, and may contain information that is
> >> confidential or
> >>> privileged and exempt from disclosure under applicable law. If you
> >>> are
> >> not
> >>> an intended recipient, please be aware that any disclosure,
> >> dissemination,
> >>> distribution or copying of this communication, or the use of its
> >> contents,
> >>> is prohibited. If you have received this message in error, please
> >>> immediately notify the sender of your inadvertent receipt and delete
> >> this
> >>> message from all data storage systems.
> >>>
> >>
> >>
> >>
> >> --
> >> Jeff Davis
> >> Senior Architect
> >> Idalica Corporation
> >> MSN: jeffdavis_ca@hotmail.com
> >> Skype: jeffdavis_ca
> >> Phone: 719-287-8656
> >> Enabling Business Through Open Source Technologies
> >> www.idalica.com
> >>
> >> IMPORTANT: This electronic message is for exclusive use by the
> >> person(s)
> >> to
> >> whom it is addressed, and may contain information that is
> >> confidential or
> >> privileged and exempt from disclosure under applicable law. If you
> >> are not
> >> an intended recipient, please be aware that any disclosure,
> >> dissemination,
> >> distribution or copying of this communication, or the use of its
> >> contents,
> >> is prohibited. If you have received this message in error, please
> >> immediately notify the sender of your inadvertent receipt and
> >> delete this
> >> message from all data storage systems.
> >>
>
>

Re: Interesting problem introduced by CDATA section

Posted by Jeff Davis <jd...@idalica.com>.

FYI, for now I just used a groovy script to to post using HTTPClient. While
obviously not ideal, it does the trick.

Thanks everyone for taking time to look into this -- you guys are great
(know wonder Synapse is such a great product!).

jeff

On Thu, Mar 27, 2008 at 3:43 PM, Andreas Veithen <an...@skynet.be>
wrote:

> Hi all,
>
> I'm pretty sure that coalescing is turned of by default. I think what
> is really needed is to activate the following property:
>
> "http://java.sun.com/xml/stream/properties/report-cdata-event"
>
> As the URI implies, this property was introduced by Sun's
> implementation, but it seems to be supported by Woodstox as well.
>
> Finally, I don't think that changes to AXIOM are required. Looking at
> the StAXUtils code, it appears that you can get a reference to the
> XMLInputFactory by calling StAXUtils.getXMLInputFactory().
>
> It should be quite easy to test if this approach works. If it does we
> need to check if Axis has support for setting properties on the
> XMLInputFactory in its configuration file. Otherwise I suggest to add
> support to Synapse for that.
>
> Andreas
>
> On 27 Mar 2008, at 20:17, Upul Godage wrote:
> > In AXIOM StAXUtils class when creating XMLInputFactory objects in
> > getXMLInputFactory() methods, (which are used by different
> > createXMLStreamReader() methods,) it can be instructed to preserve
> > CDATA as
> > CDATA by the following statement.
> > xmlInputFactory.setProperty(XMLInputFactory.IS_COALESCING,
> > Boolean.FALSE);
> > But AXIOM code has to be changed for that.
> >
> > Upul
> >
> > On Thu, Mar 27, 2008 at 9:00 PM, Jeff Davis <jd...@idalica.com>
> > wrote:
> >
> >> I suppose one horrible hack I could employ would be to use a Ruby
> >> script
> >> or
> >> Java class to post it as a regular HTTP post and then simply not
> >> specify a
> >> send element so that it doesn't get posted from Synapse?
> >>
> >> jeff
> >>
> >> On Thu, Mar 27, 2008 at 9:25 AM, Jeff Davis <jd...@idalica.com>
> >> wrote:
> >>
> >>> I played around with a jRuby script that adds the CDATA segment
> >>> back,
> >> but
> >>> unfortunately, when the XML is sent out, it again resorts to the
> >>> other
> >>> behavior (this is probably an obvious thing to you guys,but I'm
> >>> not as
> >>> familiar with the inner workings of Synapse). It sounds like I
> >>> might be
> >> out
> >>> of luck here, and as someone pointed earlier, it's not an issue with
> >>> Synapse, per se, but an erroneously design web service.
> >>>
> >>> I take it there is no way to send back a "raw" request, whereby no
> >>> XML
> >>> processing is done (basically posts a string, as-is).
> >>>
> >>> jeff
> >>>
> >>>
> >>> On Thu, Mar 27, 2008 at 8:51 AM, Paul Fremantle <pz...@gmail.com>
> >> wrote:
> >>>
> >>>> Is there a way we can create a mediator that reconverts back to a
> >>>> CDATA? I've played around a bit with Axiom, but it seems a little
> >>>> tricky to force CDATA.
> >>>>
> >>>> Paul
> >>>>
> >>>> ---------- Forwarded message ----------
> >>>> From: Paul Fremantle <pz...@gmail.com>
> >>>> Date: Thu, Mar 27, 2008 at 2:19 PM
> >>>> Subject: Re: Interesting problem introduced by CDATA section
> >>>> To: user@synapse.apache.org
> >>>>
> >>>>
> >>>> Jeff
> >>>>
> >>>> The annoying answer is that the service is wrong - its an XML error
> >> to
> >>>> differentiate between those two XMLs.
> >>>> However, we'll see if there is a way to sort this out.
> >>>>
> >>>> Paul
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Mar 27, 2008 at 4:28 AM, Jeff Davis <jd...@idalica.com>
> >> wrote:
> >>>>> Well, the problem is that the web service receiving the request
> >>>> validates
> >>>>> it, and they have it setup on their side so that if the CDATA
> >> isnt'
> >>>> present,
> >>>>> the service call fails because of validation errors. I have to
> >> have
> >>>> that
> >>>>> present or it won't work (it's a partner's service).
> >>>>>
> >>>>> jeff
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, Mar 26, 2008 at 10:05 PM, Upul Godage <upulg.dev@gmail.com
> >>>
> >>>> wrote:
> >>>>>
> >>>>>> Content wise there is no difference between CDATA sections and
> >> the
> >>>>>> resultant
> >>>>>> escaped text data.  < cannot be in parsed character data so it
> >> is
> >>>>>> converted
> >>>>>> to &lt; so it is not mixed up with element starting elements. I
> >>>> think when
> >>>>>> reading from the parser, default parser does not make a
> >> difference
> >>>> between
> >>>>>> the CDATA sections and the normal text sections and the Synapse
> >>>> sees them
> >>>>>> as
> >>>>>> just normal text. So the significance of CDATA markers are
> >> dropped
> >>>> when it
> >>>>>> is parsed. Only the serialized form changes but the "content
> >>>> remains
> >>>>>> exactly
> >>>>>> the same."
> >>>>>>
> >>>>>> Do you face a problem when not having it in the extact CDATA
> >> form?
> >>>>>>
> >>>>>> Upul
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Mar 27, 2008 at 8:07 AM, Jeff Davis <jd...@idalica.com>
> >>>> wrote:
> >>>>>>
> >>>>>>> I'm attempting to access a SOAP web service that,
> >> unfortunately,
> >>>> uses a
> >>>>>>> CDATA section within the body of the XML (this wasn't my
> >>>> choosing, :-).
> >>>>>>> The
> >>>>>>> abbreviated XML looks like:
> >>>>>>>
> >>>>>>> <env:Envelope xmlns:env="http://www.xxx.com/hrit/envelope"
> >>>>>>>   xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
> >>>>>>>   xmlns:datetime="http://exslt.org/dates-and-times">
> >>>>>>>   <env:Sender>
> >>>>>>>       <env:id>test</env:id>
> >>>>>>>   </env:Sender>
> >>>>>>>
> >>>>>>>   <env:Packet>
> >>>>>>>       <env:PacketInfo packetType="data">
> >>>>>>>           <env:packetId>1</env:packetId>
> >>>>>>>       </env:PacketInfo>
> >>>>>>>       <env:payload><![CDATA[
> >>>>>>> <Candidate xmlns="http://ns.hr-xml.org/2004-08-02" >
> >>>>>>> <test>
> >>>>>>>   <info>this is a test</info>
> >>>>>>> </test>]]></env:payload>
> >>>>>>>   </env:Packet>
> >>>>>>> </env:Envelope>
> >>>>>>>
> >>>>>>> The issue I encounter is that, when this is sent out by
> >> Synapse,
> >>>> it
> >>>>>>> appears
> >>>>>>> as (not showing the soap wrapper):
> >>>>>>>
> >>>>>>> <env:Envelope xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
> >>>>>>> xmlns:datetime="
> >>>>>>> http://exslt.org/dates-and-times">
> >>>>>>>   <env:Sender>
> >>>>>>>       <env:id>test</env:id>
> >>>>>>>   </env:Sender>
> >>>>>>>
> >>>>>>>   <env:Packet>
> >>>>>>>       <env:PacketInfo packetType="data">
> >>>>>>>           <env:packetId>1</env:packetId>
> >>>>>>>       </env:PacketInfo>
> >>>>>>>       <env:payload>
> >>>>>>>           &lt;Candidate xmlns="
> >> http://ns.hr-xml.org/2004-08-02"
> >>>>>>> xmlns:oa="
> >>>>>>> http://www.openapplications.org/oagis" xmlns:ds="
> >>>>>>> http://www.w3.org/2000/09/xmldsig#">
> >>>>>>>           &lt;test>
> >>>>>>>           &lt;info>this is a test&lt;/info>
> >>>>>>>           &lt;/test></env:payload>
> >>>>>>>   </env:Packet>
> >>>>>>> </env:Envelope>
> >>>>>>>
> >>>>>>> Notice the CDATA section has disappeared, and the unwanted
> >> &lt;
> >>>> appear
> >>>>>> in
> >>>>>>> lieu of the < within that. Researching the issue a bit, I
> >>>> discovered
> >>>>>> this
> >>>>>>> is
> >>>>>>> the expected behavior from Saxon (which I believe is the XSTL
> >>>> being used
> >>>>>>> by
> >>>>>>> Synapse). I can reproduce this if I just use a blank
> >> stylesheet.
> >>>> Now, if
> >>>>>> I
> >>>>>>> apply this stylesheet and run it through Saxon manually, it
> >>>> works great:
> >>>>>>>
> >>>>>>> <xsl:stylesheet xmlns:xsl="
> >> http://www.w3.org/1999/XSL/Transform"
> >>>>>> version="
> >>>>>>> 2.0"  xmlns:env="http://www.xxx.com/hrit/envelope">
> >>>>>>>   <xsl:output use-character-maps="xml"
> >>>>>>> cdata-section-elements="env:payload"/>
> >>>>>>>   <xsl:character-map name="xml">
> >>>>>>>       <xsl:output-character character="&lt;" string="&lt;" />
> >>>>>>>       <xsl:output-character character="&gt;" string="&gt;" />
> >>>>>>>       <xsl:output-character character="&#xD;" string="&#xD;"
> >> />
> >>>>>>>       <xsl:output-character character="&#47;" string="&#47;"
> >> />
> >>>>>>>       <xsl:output-character character="&#xE0F1;"
> >>>>>> string="&lt;![CDATA["/>
> >>>>>>>       <xsl:output-character character="&#xE0F2;"
> >> string="]]>"/>
> >>>>>>>   </xsl:character-map>
> >>>>>>>
> >>>>>>>       <xsl:template match="/'">
> >>>>>>>                  <xsl:copy-of select="*" />
> >>>>>>>       </xsl:template>
> >>>>>>>
> >>>>>>> </xsl:stylesheet>
> >>>>>>>
> >>>>>>> Unfortunately, when I plugin this stylesheet into the Synapse
> >>>> <in>
> >>>>>> route,
> >>>>>>> it
> >>>>>>> has no apparent affect (I twiddled with it to make sure it
> >> was,
> >>>> in fact,
> >>>>>>> being used, and it was).
> >>>>>>>
> >>>>>>> This is leaving me with a real quandary -- any suggestions?
> >>>>>>>
> >>>>>>> jeff
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Jeff Davis
> >>>>> Senior Architect
> >>>>> Idalica Corporation
> >>>>> MSN: jeffdavis_ca@hotmail.com
> >>>>> Skype: jeffdavis_ca
> >>>>> Phone: 719-287-8656
> >>>>> Enabling Business Through Open Source Technologies
> >>>>> www.idalica.com
> >>>>>
> >>>>> IMPORTANT: This electronic message is for exclusive use by the
> >>>> person(s) to
> >>>>> whom it is addressed, and may contain information that is
> >>>> confidential or
> >>>>> privileged and exempt from disclosure under applicable law. If you
> >>>> are not
> >>>>> an intended recipient, please be aware that any disclosure,
> >>>> dissemination,
> >>>>> distribution or copying of this communication, or the use of its
> >>>> contents,
> >>>>> is prohibited. If you have received this message in error, please
> >>>>> immediately notify the sender of your inadvertent receipt and
> >> delete
> >>>> this
> >>>>> message from all data storage systems.
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Paul Fremantle
> >>>> Co-Founder and VP of Technical Sales, WSO2
> >>>> Apache Synapse PMC Chair
> >>>> OASIS WS-RX TC Co-chair
> >>>>
> >>>> blog: http://pzf.fremantle.org
> >>>> paul@wso2.com
> >>>>
> >>>> "Oxygenating the Web Service Platform", www.wso2.com
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Paul Fremantle
> >>>> Co-Founder and VP of Technical Sales, WSO2
> >>>> Apache Synapse PMC Chair
> >>>> OASIS WS-RX TC Co-chair
> >>>>
> >>>> blog: http://pzf.fremantle.org
> >>>> paul@wso2.com
> >>>>
> >>>> "Oxygenating the Web Service Platform", www.wso2.com
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Jeff Davis
> >>> Senior Architect
> >>> Idalica Corporation
> >>> MSN: jeffdavis_ca@hotmail.com
> >>> Skype: jeffdavis_ca
> >>> Phone: 719-287-8656
> >>> Enabling Business Through Open Source Technologies
> >>> www.idalica.com
> >>>
> >>> IMPORTANT: This electronic message is for exclusive use by the
> >>> person(s)
> >>> to whom it is addressed, and may contain information that is
> >> confidential or
> >>> privileged and exempt from disclosure under applicable law. If you
> >>> are
> >> not
> >>> an intended recipient, please be aware that any disclosure,
> >> dissemination,
> >>> distribution or copying of this communication, or the use of its
> >> contents,
> >>> is prohibited. If you have received this message in error, please
> >>> immediately notify the sender of your inadvertent receipt and delete
> >> this
> >>> message from all data storage systems.
> >>>
> >>
> >>
> >>
> >> --
> >> Jeff Davis
> >> Senior Architect
> >> Idalica Corporation
> >> MSN: jeffdavis_ca@hotmail.com
> >> Skype: jeffdavis_ca
> >> Phone: 719-287-8656
> >> Enabling Business Through Open Source Technologies
> >> www.idalica.com
> >>
> >> IMPORTANT: This electronic message is for exclusive use by the
> >> person(s)
> >> to
> >> whom it is addressed, and may contain information that is
> >> confidential or
> >> privileged and exempt from disclosure under applicable law. If you
> >> are not
> >> an intended recipient, please be aware that any disclosure,
> >> dissemination,
> >> distribution or copying of this communication, or the use of its
> >> contents,
> >> is prohibited. If you have received this message in error, please
> >> immediately notify the sender of your inadvertent receipt and
> >> delete this
> >> message from all data storage systems.
> >>
>
>


-- 
Jeff Davis
Senior Architect
Idalica Corporation
MSN: jeffdavis_ca@hotmail.com
Skype: jeffdavis_ca
Phone: 719-287-8656
Enabling Business Through Open Source Technologies
www.idalica.com

IMPORTANT: This electronic message is for exclusive use by the person(s) to
whom it is addressed, and may contain information that is confidential or
privileged and exempt from disclosure under applicable law. If you are not
an intended recipient, please be aware that any disclosure, dissemination,
distribution or copying of this communication, or the use of its contents,
is prohibited. If you have received this message in error, please
immediately notify the sender of your inadvertent receipt and delete this
message from all data storage systems.

Re: Interesting problem introduced by CDATA section

Posted by Andreas Veithen <an...@skynet.be>.

Hi all,

I'm pretty sure that coalescing is turned of by default. I think what  
is really needed is to activate the following property:

"http://java.sun.com/xml/stream/properties/report-cdata-event"

As the URI implies, this property was introduced by Sun's  
implementation, but it seems to be supported by Woodstox as well.

Finally, I don't think that changes to AXIOM are required. Looking at  
the StAXUtils code, it appears that you can get a reference to the  
XMLInputFactory by calling StAXUtils.getXMLInputFactory().

It should be quite easy to test if this approach works. If it does we  
need to check if Axis has support for setting properties on the  
XMLInputFactory in its configuration file. Otherwise I suggest to add  
support to Synapse for that.

Andreas

On 27 Mar 2008, at 20:17, Upul Godage wrote:
> In AXIOM StAXUtils class when creating XMLInputFactory objects in
> getXMLInputFactory() methods, (which are used by different
> createXMLStreamReader() methods,) it can be instructed to preserve  
> CDATA as
> CDATA by the following statement.
> xmlInputFactory.setProperty(XMLInputFactory.IS_COALESCING,  
> Boolean.FALSE);
> But AXIOM code has to be changed for that.
>
> Upul
>
> On Thu, Mar 27, 2008 at 9:00 PM, Jeff Davis <jd...@idalica.com>  
> wrote:
>
>> I suppose one horrible hack I could employ would be to use a Ruby  
>> script
>> or
>> Java class to post it as a regular HTTP post and then simply not  
>> specify a
>> send element so that it doesn't get posted from Synapse?
>>
>> jeff
>>
>> On Thu, Mar 27, 2008 at 9:25 AM, Jeff Davis <jd...@idalica.com>  
>> wrote:
>>
>>> I played around with a jRuby script that adds the CDATA segment  
>>> back,
>> but
>>> unfortunately, when the XML is sent out, it again resorts to the  
>>> other
>>> behavior (this is probably an obvious thing to you guys,but I'm  
>>> not as
>>> familiar with the inner workings of Synapse). It sounds like I  
>>> might be
>> out
>>> of luck here, and as someone pointed earlier, it's not an issue with
>>> Synapse, per se, but an erroneously design web service.
>>>
>>> I take it there is no way to send back a "raw" request, whereby no  
>>> XML
>>> processing is done (basically posts a string, as-is).
>>>
>>> jeff
>>>
>>>
>>> On Thu, Mar 27, 2008 at 8:51 AM, Paul Fremantle <pz...@gmail.com>
>> wrote:
>>>
>>>> Is there a way we can create a mediator that reconverts back to a
>>>> CDATA? I've played around a bit with Axiom, but it seems a little
>>>> tricky to force CDATA.
>>>>
>>>> Paul
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Paul Fremantle <pz...@gmail.com>
>>>> Date: Thu, Mar 27, 2008 at 2:19 PM
>>>> Subject: Re: Interesting problem introduced by CDATA section
>>>> To: user@synapse.apache.org
>>>>
>>>>
>>>> Jeff
>>>>
>>>> The annoying answer is that the service is wrong - its an XML error
>> to
>>>> differentiate between those two XMLs.
>>>> However, we'll see if there is a way to sort this out.
>>>>
>>>> Paul
>>>>
>>>>
>>>>
>>>> On Thu, Mar 27, 2008 at 4:28 AM, Jeff Davis <jd...@idalica.com>
>> wrote:
>>>>> Well, the problem is that the web service receiving the request
>>>> validates
>>>>> it, and they have it setup on their side so that if the CDATA
>> isnt'
>>>> present,
>>>>> the service call fails because of validation errors. I have to
>> have
>>>> that
>>>>> present or it won't work (it's a partner's service).
>>>>>
>>>>> jeff
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 26, 2008 at 10:05 PM, Upul Godage <upulg.dev@gmail.com
>>>
>>>> wrote:
>>>>>
>>>>>> Content wise there is no difference between CDATA sections and
>> the
>>>>>> resultant
>>>>>> escaped text data.  < cannot be in parsed character data so it
>> is
>>>>>> converted
>>>>>> to &lt; so it is not mixed up with element starting elements. I
>>>> think when
>>>>>> reading from the parser, default parser does not make a
>> difference
>>>> between
>>>>>> the CDATA sections and the normal text sections and the Synapse
>>>> sees them
>>>>>> as
>>>>>> just normal text. So the significance of CDATA markers are
>> dropped
>>>> when it
>>>>>> is parsed. Only the serialized form changes but the "content
>>>> remains
>>>>>> exactly
>>>>>> the same."
>>>>>>
>>>>>> Do you face a problem when not having it in the extact CDATA
>> form?
>>>>>>
>>>>>> Upul
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 27, 2008 at 8:07 AM, Jeff Davis <jd...@idalica.com>
>>>> wrote:
>>>>>>
>>>>>>> I'm attempting to access a SOAP web service that,
>> unfortunately,
>>>> uses a
>>>>>>> CDATA section within the body of the XML (this wasn't my
>>>> choosing, :-).
>>>>>>> The
>>>>>>> abbreviated XML looks like:
>>>>>>>
>>>>>>> <env:Envelope xmlns:env="http://www.xxx.com/hrit/envelope"
>>>>>>>   xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
>>>>>>>   xmlns:datetime="http://exslt.org/dates-and-times">
>>>>>>>   <env:Sender>
>>>>>>>       <env:id>test</env:id>
>>>>>>>   </env:Sender>
>>>>>>>
>>>>>>>   <env:Packet>
>>>>>>>       <env:PacketInfo packetType="data">
>>>>>>>           <env:packetId>1</env:packetId>
>>>>>>>       </env:PacketInfo>
>>>>>>>       <env:payload><![CDATA[
>>>>>>> <Candidate xmlns="http://ns.hr-xml.org/2004-08-02" >
>>>>>>> <test>
>>>>>>>   <info>this is a test</info>
>>>>>>> </test>]]></env:payload>
>>>>>>>   </env:Packet>
>>>>>>> </env:Envelope>
>>>>>>>
>>>>>>> The issue I encounter is that, when this is sent out by
>> Synapse,
>>>> it
>>>>>>> appears
>>>>>>> as (not showing the soap wrapper):
>>>>>>>
>>>>>>> <env:Envelope xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
>>>>>>> xmlns:datetime="
>>>>>>> http://exslt.org/dates-and-times">
>>>>>>>   <env:Sender>
>>>>>>>       <env:id>test</env:id>
>>>>>>>   </env:Sender>
>>>>>>>
>>>>>>>   <env:Packet>
>>>>>>>       <env:PacketInfo packetType="data">
>>>>>>>           <env:packetId>1</env:packetId>
>>>>>>>       </env:PacketInfo>
>>>>>>>       <env:payload>
>>>>>>>           &lt;Candidate xmlns="
>> http://ns.hr-xml.org/2004-08-02"
>>>>>>> xmlns:oa="
>>>>>>> http://www.openapplications.org/oagis" xmlns:ds="
>>>>>>> http://www.w3.org/2000/09/xmldsig#">
>>>>>>>           &lt;test>
>>>>>>>           &lt;info>this is a test&lt;/info>
>>>>>>>           &lt;/test></env:payload>
>>>>>>>   </env:Packet>
>>>>>>> </env:Envelope>
>>>>>>>
>>>>>>> Notice the CDATA section has disappeared, and the unwanted
>> &lt;
>>>> appear
>>>>>> in
>>>>>>> lieu of the < within that. Researching the issue a bit, I
>>>> discovered
>>>>>> this
>>>>>>> is
>>>>>>> the expected behavior from Saxon (which I believe is the XSTL
>>>> being used
>>>>>>> by
>>>>>>> Synapse). I can reproduce this if I just use a blank
>> stylesheet.
>>>> Now, if
>>>>>> I
>>>>>>> apply this stylesheet and run it through Saxon manually, it
>>>> works great:
>>>>>>>
>>>>>>> <xsl:stylesheet xmlns:xsl="
>> http://www.w3.org/1999/XSL/Transform"
>>>>>> version="
>>>>>>> 2.0"  xmlns:env="http://www.xxx.com/hrit/envelope">
>>>>>>>   <xsl:output use-character-maps="xml"
>>>>>>> cdata-section-elements="env:payload"/>
>>>>>>>   <xsl:character-map name="xml">
>>>>>>>       <xsl:output-character character="&lt;" string="&lt;" />
>>>>>>>       <xsl:output-character character="&gt;" string="&gt;" />
>>>>>>>       <xsl:output-character character="&#xD;" string="&#xD;"
>> />
>>>>>>>       <xsl:output-character character="&#47;" string="&#47;"
>> />
>>>>>>>       <xsl:output-character character="&#xE0F1;"
>>>>>> string="&lt;![CDATA["/>
>>>>>>>       <xsl:output-character character="&#xE0F2;"
>> string="]]>"/>
>>>>>>>   </xsl:character-map>
>>>>>>>
>>>>>>>       <xsl:template match="/'">
>>>>>>>                  <xsl:copy-of select="*" />
>>>>>>>       </xsl:template>
>>>>>>>
>>>>>>> </xsl:stylesheet>
>>>>>>>
>>>>>>> Unfortunately, when I plugin this stylesheet into the Synapse
>>>> <in>
>>>>>> route,
>>>>>>> it
>>>>>>> has no apparent affect (I twiddled with it to make sure it
>> was,
>>>> in fact,
>>>>>>> being used, and it was).
>>>>>>>
>>>>>>> This is leaving me with a real quandary -- any suggestions?
>>>>>>>
>>>>>>> jeff
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jeff Davis
>>>>> Senior Architect
>>>>> Idalica Corporation
>>>>> MSN: jeffdavis_ca@hotmail.com
>>>>> Skype: jeffdavis_ca
>>>>> Phone: 719-287-8656
>>>>> Enabling Business Through Open Source Technologies
>>>>> www.idalica.com
>>>>>
>>>>> IMPORTANT: This electronic message is for exclusive use by the
>>>> person(s) to
>>>>> whom it is addressed, and may contain information that is
>>>> confidential or
>>>>> privileged and exempt from disclosure under applicable law. If you
>>>> are not
>>>>> an intended recipient, please be aware that any disclosure,
>>>> dissemination,
>>>>> distribution or copying of this communication, or the use of its
>>>> contents,
>>>>> is prohibited. If you have received this message in error, please
>>>>> immediately notify the sender of your inadvertent receipt and
>> delete
>>>> this
>>>>> message from all data storage systems.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Paul Fremantle
>>>> Co-Founder and VP of Technical Sales, WSO2
>>>> Apache Synapse PMC Chair
>>>> OASIS WS-RX TC Co-chair
>>>>
>>>> blog: http://pzf.fremantle.org
>>>> paul@wso2.com
>>>>
>>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>>
>>>>
>>>>
>>>> --
>>>> Paul Fremantle
>>>> Co-Founder and VP of Technical Sales, WSO2
>>>> Apache Synapse PMC Chair
>>>> OASIS WS-RX TC Co-chair
>>>>
>>>> blog: http://pzf.fremantle.org
>>>> paul@wso2.com
>>>>
>>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>>
>>>
>>>
>>>
>>> --
>>> Jeff Davis
>>> Senior Architect
>>> Idalica Corporation
>>> MSN: jeffdavis_ca@hotmail.com
>>> Skype: jeffdavis_ca
>>> Phone: 719-287-8656
>>> Enabling Business Through Open Source Technologies
>>> www.idalica.com
>>>
>>> IMPORTANT: This electronic message is for exclusive use by the  
>>> person(s)
>>> to whom it is addressed, and may contain information that is
>> confidential or
>>> privileged and exempt from disclosure under applicable law. If you  
>>> are
>> not
>>> an intended recipient, please be aware that any disclosure,
>> dissemination,
>>> distribution or copying of this communication, or the use of its
>> contents,
>>> is prohibited. If you have received this message in error, please
>>> immediately notify the sender of your inadvertent receipt and delete
>> this
>>> message from all data storage systems.
>>>
>>
>>
>>
>> --
>> Jeff Davis
>> Senior Architect
>> Idalica Corporation
>> MSN: jeffdavis_ca@hotmail.com
>> Skype: jeffdavis_ca
>> Phone: 719-287-8656
>> Enabling Business Through Open Source Technologies
>> www.idalica.com
>>
>> IMPORTANT: This electronic message is for exclusive use by the  
>> person(s)
>> to
>> whom it is addressed, and may contain information that is  
>> confidential or
>> privileged and exempt from disclosure under applicable law. If you  
>> are not
>> an intended recipient, please be aware that any disclosure,  
>> dissemination,
>> distribution or copying of this communication, or the use of its  
>> contents,
>> is prohibited. If you have received this message in error, please
>> immediately notify the sender of your inadvertent receipt and  
>> delete this
>> message from all data storage systems.
>>

Re: Interesting problem introduced by CDATA section

Posted by Upul Godage <up...@gmail.com>.

In AXIOM StAXUtils class when creating XMLInputFactory objects in
getXMLInputFactory() methods, (which are used by different
createXMLStreamReader() methods,) it can be instructed to preserve CDATA as
CDATA by the following statement.
xmlInputFactory.setProperty(XMLInputFactory.IS_COALESCING, Boolean.FALSE);
But AXIOM code has to be changed for that.

Upul

On Thu, Mar 27, 2008 at 9:00 PM, Jeff Davis <jd...@idalica.com> wrote:

> I suppose one horrible hack I could employ would be to use a Ruby script
> or
> Java class to post it as a regular HTTP post and then simply not specify a
> send element so that it doesn't get posted from Synapse?
>
> jeff
>
> On Thu, Mar 27, 2008 at 9:25 AM, Jeff Davis <jd...@idalica.com> wrote:
>
> > I played around with a jRuby script that adds the CDATA segment back,
> but
> > unfortunately, when the XML is sent out, it again resorts to the other
> > behavior (this is probably an obvious thing to you guys,but I'm not as
> > familiar with the inner workings of Synapse). It sounds like I might be
> out
> > of luck here, and as someone pointed earlier, it's not an issue with
> > Synapse, per se, but an erroneously design web service.
> >
> > I take it there is no way to send back a "raw" request, whereby no XML
> > processing is done (basically posts a string, as-is).
> >
> > jeff
> >
> >
> > On Thu, Mar 27, 2008 at 8:51 AM, Paul Fremantle <pz...@gmail.com>
> wrote:
> >
> > > Is there a way we can create a mediator that reconverts back to a
> > > CDATA? I've played around a bit with Axiom, but it seems a little
> > > tricky to force CDATA.
> > >
> > > Paul
> > >
> > > ---------- Forwarded message ----------
> > > From: Paul Fremantle <pz...@gmail.com>
> > > Date: Thu, Mar 27, 2008 at 2:19 PM
> > > Subject: Re: Interesting problem introduced by CDATA section
> > > To: user@synapse.apache.org
> > >
> > >
> > > Jeff
> > >
> > >  The annoying answer is that the service is wrong - its an XML error
> to
> > >  differentiate between those two XMLs.
> > >  However, we'll see if there is a way to sort this out.
> > >
> > >  Paul
> > >
> > >
> > >
> > >  On Thu, Mar 27, 2008 at 4:28 AM, Jeff Davis <jd...@idalica.com>
> wrote:
> > >  > Well, the problem is that the web service receiving the request
> > > validates
> > >  >  it, and they have it setup on their side so that if the CDATA
> isnt'
> > > present,
> > >  >  the service call fails because of validation errors. I have to
> have
> > > that
> > >  >  present or it won't work (it's a partner's service).
> > >  >
> > >  >  jeff
> > >  >
> > >  >
> > >  >
> > >  >  On Wed, Mar 26, 2008 at 10:05 PM, Upul Godage <upulg.dev@gmail.com
> >
> > > wrote:
> > >  >
> > >  >  > Content wise there is no difference between CDATA sections and
> the
> > >  >  > resultant
> > >  >  > escaped text data.  < cannot be in parsed character data so it
> is
> > >  >  > converted
> > >  >  > to &lt; so it is not mixed up with element starting elements. I
> > > think when
> > >  >  > reading from the parser, default parser does not make a
> difference
> > > between
> > >  >  > the CDATA sections and the normal text sections and the Synapse
> > > sees them
> > >  >  > as
> > >  >  > just normal text. So the significance of CDATA markers are
> dropped
> > > when it
> > >  >  > is parsed. Only the serialized form changes but the "content
> > > remains
> > >  >  > exactly
> > >  >  > the same."
> > >  >  >
> > >  >  > Do you face a problem when not having it in the extact CDATA
> form?
> > >  >  >
> > >  >  > Upul
> > >  >  >
> > >  >  >
> > >  >  >
> > >  >  > On Thu, Mar 27, 2008 at 8:07 AM, Jeff Davis <jd...@idalica.com>
> > > wrote:
> > >  >  >
> > >  >  > > I'm attempting to access a SOAP web service that,
> unfortunately,
> > > uses a
> > >  >  > > CDATA section within the body of the XML (this wasn't my
> > > choosing, :-).
> > >  >  > > The
> > >  >  > > abbreviated XML looks like:
> > >  >  > >
> > >  >  > > <env:Envelope xmlns:env="http://www.xxx.com/hrit/envelope"
> > >  >  > >    xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
> > >  >  > >    xmlns:datetime="http://exslt.org/dates-and-times">
> > >  >  > >    <env:Sender>
> > >  >  > >        <env:id>test</env:id>
> > >  >  > >    </env:Sender>
> > >  >  > >
> > >  >  > >    <env:Packet>
> > >  >  > >        <env:PacketInfo packetType="data">
> > >  >  > >            <env:packetId>1</env:packetId>
> > >  >  > >        </env:PacketInfo>
> > >  >  > >        <env:payload><![CDATA[
> > >  >  > > <Candidate xmlns="http://ns.hr-xml.org/2004-08-02" >
> > >  >  > > <test>
> > >  >  > >    <info>this is a test</info>
> > >  >  > > </test>]]></env:payload>
> > >  >  > >    </env:Packet>
> > >  >  > > </env:Envelope>
> > >  >  > >
> > >  >  > > The issue I encounter is that, when this is sent out by
> Synapse,
> > > it
> > >  >  > > appears
> > >  >  > > as (not showing the soap wrapper):
> > >  >  > >
> > >  >  > > <env:Envelope xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
> > >  >  > > xmlns:datetime="
> > >  >  > > http://exslt.org/dates-and-times">
> > >  >  > >    <env:Sender>
> > >  >  > >        <env:id>test</env:id>
> > >  >  > >    </env:Sender>
> > >  >  > >
> > >  >  > >    <env:Packet>
> > >  >  > >        <env:PacketInfo packetType="data">
> > >  >  > >            <env:packetId>1</env:packetId>
> > >  >  > >        </env:PacketInfo>
> > >  >  > >        <env:payload>
> > >  >  > >            &lt;Candidate xmlns="
> http://ns.hr-xml.org/2004-08-02"
> > >  >  > > xmlns:oa="
> > >  >  > > http://www.openapplications.org/oagis" xmlns:ds="
> > >  >  > > http://www.w3.org/2000/09/xmldsig#">
> > >  >  > >            &lt;test>
> > >  >  > >            &lt;info>this is a test&lt;/info>
> > >  >  > >            &lt;/test></env:payload>
> > >  >  > >    </env:Packet>
> > >  >  > > </env:Envelope>
> > >  >  > >
> > >  >  > > Notice the CDATA section has disappeared, and the unwanted
> &lt;
> > > appear
> > >  >  > in
> > >  >  > > lieu of the < within that. Researching the issue a bit, I
> > > discovered
> > >  >  > this
> > >  >  > > is
> > >  >  > > the expected behavior from Saxon (which I believe is the XSTL
> > > being used
> > >  >  > > by
> > >  >  > > Synapse). I can reproduce this if I just use a blank
> stylesheet.
> > > Now, if
> > >  >  > I
> > >  >  > > apply this stylesheet and run it through Saxon manually, it
> > > works great:
> > >  >  > >
> > >  >  > > <xsl:stylesheet xmlns:xsl="
> http://www.w3.org/1999/XSL/Transform"
> > >  >  > version="
> > >  >  > > 2.0"  xmlns:env="http://www.xxx.com/hrit/envelope">
> > >  >  > >    <xsl:output use-character-maps="xml"
> > >  >  > > cdata-section-elements="env:payload"/>
> > >  >  > >    <xsl:character-map name="xml">
> > >  >  > >        <xsl:output-character character="&lt;" string="&lt;" />
> > >  >  > >        <xsl:output-character character="&gt;" string="&gt;" />
> > >  >  > >        <xsl:output-character character="&#xD;" string="&#xD;"
> />
> > >  >  > >        <xsl:output-character character="&#47;" string="&#47;"
> />
> > >  >  > >        <xsl:output-character character="&#xE0F1;"
> > >  >  > string="&lt;![CDATA["/>
> > >  >  > >        <xsl:output-character character="&#xE0F2;"
> string="]]>"/>
> > >  >  > >    </xsl:character-map>
> > >  >  > >
> > >  >  > >        <xsl:template match="/'">
> > >  >  > >                   <xsl:copy-of select="*" />
> > >  >  > >        </xsl:template>
> > >  >  > >
> > >  >  > > </xsl:stylesheet>
> > >  >  > >
> > >  >  > > Unfortunately, when I plugin this stylesheet into the Synapse
> > > <in>
> > >  >  > route,
> > >  >  > > it
> > >  >  > > has no apparent affect (I twiddled with it to make sure it
> was,
> > > in fact,
> > >  >  > > being used, and it was).
> > >  >  > >
> > >  >  > > This is leaving me with a real quandary -- any suggestions?
> > >  >  > >
> > >  >  > > jeff
> > >  >  > >
> > >  >  >
> > >  >
> > >  >
> > >  >
> > >  >  --
> > >  >  Jeff Davis
> > >  >  Senior Architect
> > >  >  Idalica Corporation
> > >  >  MSN: jeffdavis_ca@hotmail.com
> > >  >  Skype: jeffdavis_ca
> > >  >  Phone: 719-287-8656
> > >  >  Enabling Business Through Open Source Technologies
> > >  >  www.idalica.com
> > >  >
> > >  >  IMPORTANT: This electronic message is for exclusive use by the
> > > person(s) to
> > >  >  whom it is addressed, and may contain information that is
> > > confidential or
> > >  >  privileged and exempt from disclosure under applicable law. If you
> > > are not
> > >  >  an intended recipient, please be aware that any disclosure,
> > > dissemination,
> > >  >  distribution or copying of this communication, or the use of its
> > > contents,
> > >  >  is prohibited. If you have received this message in error, please
> > >  >  immediately notify the sender of your inadvertent receipt and
> delete
> > > this
> > >  >  message from all data storage systems.
> > >  >
> > >
> > >
> > >
> > >  --
> > >  Paul Fremantle
> > >  Co-Founder and VP of Technical Sales, WSO2
> > >  Apache Synapse PMC Chair
> > >  OASIS WS-RX TC Co-chair
> > >
> > >  blog: http://pzf.fremantle.org
> > >  paul@wso2.com
> > >
> > >  "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > >
> > >
> > > --
> > > Paul Fremantle
> > > Co-Founder and VP of Technical Sales, WSO2
> > > Apache Synapse PMC Chair
> > > OASIS WS-RX TC Co-chair
> > >
> > > blog: http://pzf.fremantle.org
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> >
> >
> >
> > --
> > Jeff Davis
> > Senior Architect
> > Idalica Corporation
> > MSN: jeffdavis_ca@hotmail.com
> > Skype: jeffdavis_ca
> > Phone: 719-287-8656
> > Enabling Business Through Open Source Technologies
> > www.idalica.com
> >
> > IMPORTANT: This electronic message is for exclusive use by the person(s)
> > to whom it is addressed, and may contain information that is
> confidential or
> > privileged and exempt from disclosure under applicable law. If you are
> not
> > an intended recipient, please be aware that any disclosure,
> dissemination,
> > distribution or copying of this communication, or the use of its
> contents,
> > is prohibited. If you have received this message in error, please
> > immediately notify the sender of your inadvertent receipt and delete
> this
> > message from all data storage systems.
> >
>
>
>
> --
> Jeff Davis
> Senior Architect
> Idalica Corporation
> MSN: jeffdavis_ca@hotmail.com
> Skype: jeffdavis_ca
> Phone: 719-287-8656
> Enabling Business Through Open Source Technologies
> www.idalica.com
>
> IMPORTANT: This electronic message is for exclusive use by the person(s)
> to
> whom it is addressed, and may contain information that is confidential or
> privileged and exempt from disclosure under applicable law. If you are not
> an intended recipient, please be aware that any disclosure, dissemination,
> distribution or copying of this communication, or the use of its contents,
> is prohibited. If you have received this message in error, please
> immediately notify the sender of your inadvertent receipt and delete this
> message from all data storage systems.
>

Re: Interesting problem introduced by CDATA section

Posted by hi...@wso2.com.

Hi,

I guess the culprit is AXIOM (see [1]). It doesn't handle CDATA elements
very well. I encountered similar issues when developing the FIX transport
module for Synapse. But fortunately for me I could take care of the
problem at the transport level itself.

Thanks

Best Regards,
Hiranya Jayathilaka

[1] https://issues.apache.org/jira/browse/WSCOMMONS-305)




> I suppose one horrible hack I could employ would be to use a Ruby script
> or
> Java class to post it as a regular HTTP post and then simply not specify a
> send element so that it doesn't get posted from Synapse?
>
> jeff
>
> On Thu, Mar 27, 2008 at 9:25 AM, Jeff Davis <jd...@idalica.com> wrote:
>
>> I played around with a jRuby script that adds the CDATA segment back,
>> but
>> unfortunately, when the XML is sent out, it again resorts to the other
>> behavior (this is probably an obvious thing to you guys,but I'm not as
>> familiar with the inner workings of Synapse). It sounds like I might be
>> out
>> of luck here, and as someone pointed earlier, it's not an issue with
>> Synapse, per se, but an erroneously design web service.
>>
>> I take it there is no way to send back a "raw" request, whereby no XML
>> processing is done (basically posts a string, as-is).
>>
>> jeff
>>
>>
>> On Thu, Mar 27, 2008 at 8:51 AM, Paul Fremantle <pz...@gmail.com>
>> wrote:
>>
>> > Is there a way we can create a mediator that reconverts back to a
>> > CDATA? I've played around a bit with Axiom, but it seems a little
>> > tricky to force CDATA.
>> >
>> > Paul
>> >
>> > ---------- Forwarded message ----------
>> > From: Paul Fremantle <pz...@gmail.com>
>> > Date: Thu, Mar 27, 2008 at 2:19 PM
>> > Subject: Re: Interesting problem introduced by CDATA section
>> > To: user@synapse.apache.org
>> >
>> >
>> > Jeff
>> >
>> >  The annoying answer is that the service is wrong - its an XML error
>> to
>> >  differentiate between those two XMLs.
>> >  However, we'll see if there is a way to sort this out.
>> >
>> >  Paul
>> >
>> >
>> >
>> >  On Thu, Mar 27, 2008 at 4:28 AM, Jeff Davis <jd...@idalica.com>
>> wrote:
>> >  > Well, the problem is that the web service receiving the request
>> > validates
>> >  >  it, and they have it setup on their side so that if the CDATA
>> isnt'
>> > present,
>> >  >  the service call fails because of validation errors. I have to
>> have
>> > that
>> >  >  present or it won't work (it's a partner's service).
>> >  >
>> >  >  jeff
>> >  >
>> >  >
>> >  >
>> >  >  On Wed, Mar 26, 2008 at 10:05 PM, Upul Godage
>> <up...@gmail.com>
>> > wrote:
>> >  >
>> >  >  > Content wise there is no difference between CDATA sections and
>> the
>> >  >  > resultant
>> >  >  > escaped text data.  < cannot be in parsed character data so it
>> is
>> >  >  > converted
>> >  >  > to &lt; so it is not mixed up with element starting elements. I
>> > think when
>> >  >  > reading from the parser, default parser does not make a
>> difference
>> > between
>> >  >  > the CDATA sections and the normal text sections and the Synapse
>> > sees them
>> >  >  > as
>> >  >  > just normal text. So the significance of CDATA markers are
>> dropped
>> > when it
>> >  >  > is parsed. Only the serialized form changes but the "content
>> > remains
>> >  >  > exactly
>> >  >  > the same."
>> >  >  >
>> >  >  > Do you face a problem when not having it in the extact CDATA
>> form?
>> >  >  >
>> >  >  > Upul
>> >  >  >
>> >  >  >
>> >  >  >
>> >  >  > On Thu, Mar 27, 2008 at 8:07 AM, Jeff Davis <jd...@idalica.com>
>> > wrote:
>> >  >  >
>> >  >  > > I'm attempting to access a SOAP web service that,
>> unfortunately,
>> > uses a
>> >  >  > > CDATA section within the body of the XML (this wasn't my
>> > choosing, :-).
>> >  >  > > The
>> >  >  > > abbreviated XML looks like:
>> >  >  > >
>> >  >  > > <env:Envelope xmlns:env="http://www.xxx.com/hrit/envelope"
>> >  >  > >    xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
>> >  >  > >    xmlns:datetime="http://exslt.org/dates-and-times">
>> >  >  > >    <env:Sender>
>> >  >  > >        <env:id>test</env:id>
>> >  >  > >    </env:Sender>
>> >  >  > >
>> >  >  > >    <env:Packet>
>> >  >  > >        <env:PacketInfo packetType="data">
>> >  >  > >            <env:packetId>1</env:packetId>
>> >  >  > >        </env:PacketInfo>
>> >  >  > >        <env:payload><![CDATA[
>> >  >  > > <Candidate xmlns="http://ns.hr-xml.org/2004-08-02" >
>> >  >  > > <test>
>> >  >  > >    <info>this is a test</info>
>> >  >  > > </test>]]></env:payload>
>> >  >  > >    </env:Packet>
>> >  >  > > </env:Envelope>
>> >  >  > >
>> >  >  > > The issue I encounter is that, when this is sent out by
>> Synapse,
>> > it
>> >  >  > > appears
>> >  >  > > as (not showing the soap wrapper):
>> >  >  > >
>> >  >  > > <env:Envelope xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
>> >  >  > > xmlns:datetime="
>> >  >  > > http://exslt.org/dates-and-times">
>> >  >  > >    <env:Sender>
>> >  >  > >        <env:id>test</env:id>
>> >  >  > >    </env:Sender>
>> >  >  > >
>> >  >  > >    <env:Packet>
>> >  >  > >        <env:PacketInfo packetType="data">
>> >  >  > >            <env:packetId>1</env:packetId>
>> >  >  > >        </env:PacketInfo>
>> >  >  > >        <env:payload>
>> >  >  > >            &lt;Candidate
>> xmlns="http://ns.hr-xml.org/2004-08-02"
>> >  >  > > xmlns:oa="
>> >  >  > > http://www.openapplications.org/oagis" xmlns:ds="
>> >  >  > > http://www.w3.org/2000/09/xmldsig#">
>> >  >  > >            &lt;test>
>> >  >  > >            &lt;info>this is a test&lt;/info>
>> >  >  > >            &lt;/test></env:payload>
>> >  >  > >    </env:Packet>
>> >  >  > > </env:Envelope>
>> >  >  > >
>> >  >  > > Notice the CDATA section has disappeared, and the unwanted
>> &lt;
>> > appear
>> >  >  > in
>> >  >  > > lieu of the < within that. Researching the issue a bit, I
>> > discovered
>> >  >  > this
>> >  >  > > is
>> >  >  > > the expected behavior from Saxon (which I believe is the XSTL
>> > being used
>> >  >  > > by
>> >  >  > > Synapse). I can reproduce this if I just use a blank
>> stylesheet.
>> > Now, if
>> >  >  > I
>> >  >  > > apply this stylesheet and run it through Saxon manually, it
>> > works great:
>> >  >  > >
>> >  >  > > <xsl:stylesheet
>> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>> >  >  > version="
>> >  >  > > 2.0"  xmlns:env="http://www.xxx.com/hrit/envelope">
>> >  >  > >    <xsl:output use-character-maps="xml"
>> >  >  > > cdata-section-elements="env:payload"/>
>> >  >  > >    <xsl:character-map name="xml">
>> >  >  > >        <xsl:output-character character="&lt;" string="&lt;" />
>> >  >  > >        <xsl:output-character character="&gt;" string="&gt;" />
>> >  >  > >        <xsl:output-character character="&#xD;" string="&#xD;"
>> />
>> >  >  > >        <xsl:output-character character="&#47;" string="&#47;"
>> />
>> >  >  > >        <xsl:output-character character="&#xE0F1;"
>> >  >  > string="&lt;![CDATA["/>
>> >  >  > >        <xsl:output-character character="&#xE0F2;"
>> string="]]>"/>
>> >  >  > >    </xsl:character-map>
>> >  >  > >
>> >  >  > >        <xsl:template match="/'">
>> >  >  > >                   <xsl:copy-of select="*" />
>> >  >  > >        </xsl:template>
>> >  >  > >
>> >  >  > > </xsl:stylesheet>
>> >  >  > >
>> >  >  > > Unfortunately, when I plugin this stylesheet into the Synapse
>> > <in>
>> >  >  > route,
>> >  >  > > it
>> >  >  > > has no apparent affect (I twiddled with it to make sure it
>> was,
>> > in fact,
>> >  >  > > being used, and it was).
>> >  >  > >
>> >  >  > > This is leaving me with a real quandary -- any suggestions?
>> >  >  > >
>> >  >  > > jeff
>> >  >  > >
>> >  >  >
>> >  >
>> >  >
>> >  >
>> >  >  --
>> >  >  Jeff Davis
>> >  >  Senior Architect
>> >  >  Idalica Corporation
>> >  >  MSN: jeffdavis_ca@hotmail.com
>> >  >  Skype: jeffdavis_ca
>> >  >  Phone: 719-287-8656
>> >  >  Enabling Business Through Open Source Technologies
>> >  >  www.idalica.com
>> >  >
>> >  >  IMPORTANT: This electronic message is for exclusive use by the
>> > person(s) to
>> >  >  whom it is addressed, and may contain information that is
>> > confidential or
>> >  >  privileged and exempt from disclosure under applicable law. If you
>> > are not
>> >  >  an intended recipient, please be aware that any disclosure,
>> > dissemination,
>> >  >  distribution or copying of this communication, or the use of its
>> > contents,
>> >  >  is prohibited. If you have received this message in error, please
>> >  >  immediately notify the sender of your inadvertent receipt and
>> delete
>> > this
>> >  >  message from all data storage systems.
>> >  >
>> >
>> >
>> >
>> >  --
>> >  Paul Fremantle
>> >  Co-Founder and VP of Technical Sales, WSO2
>> >  Apache Synapse PMC Chair
>> >  OASIS WS-RX TC Co-chair
>> >
>> >  blog: http://pzf.fremantle.org
>> >  paul@wso2.com
>> >
>> >  "Oxygenating the Web Service Platform", www.wso2.com
>> >
>> >
>> >
>> > --
>> > Paul Fremantle
>> > Co-Founder and VP of Technical Sales, WSO2
>> > Apache Synapse PMC Chair
>> > OASIS WS-RX TC Co-chair
>> >
>> > blog: http://pzf.fremantle.org
>> > paul@wso2.com
>> >
>> > "Oxygenating the Web Service Platform", www.wso2.com
>> >
>>
>>
>>
>> --
>> Jeff Davis
>> Senior Architect
>> Idalica Corporation
>> MSN: jeffdavis_ca@hotmail.com
>> Skype: jeffdavis_ca
>> Phone: 719-287-8656
>> Enabling Business Through Open Source Technologies
>> www.idalica.com
>>
>> IMPORTANT: This electronic message is for exclusive use by the person(s)
>> to whom it is addressed, and may contain information that is
>> confidential or
>> privileged and exempt from disclosure under applicable law. If you are
>> not
>> an intended recipient, please be aware that any disclosure,
>> dissemination,
>> distribution or copying of this communication, or the use of its
>> contents,
>> is prohibited. If you have received this message in error, please
>> immediately notify the sender of your inadvertent receipt and delete
>> this
>> message from all data storage systems.
>>
>
>
>
> --
> Jeff Davis
> Senior Architect
> Idalica Corporation
> MSN: jeffdavis_ca@hotmail.com
> Skype: jeffdavis_ca
> Phone: 719-287-8656
> Enabling Business Through Open Source Technologies
> www.idalica.com
>
> IMPORTANT: This electronic message is for exclusive use by the person(s)
> to
> whom it is addressed, and may contain information that is confidential or
> privileged and exempt from disclosure under applicable law. If you are not
> an intended recipient, please be aware that any disclosure, dissemination,
> distribution or copying of this communication, or the use of its contents,
> is prohibited. If you have received this message in error, please
> immediately notify the sender of your inadvertent receipt and delete this
> message from all data storage systems.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org

Re: Interesting problem introduced by CDATA section

Posted by Jeff Davis <jd...@idalica.com>.

I suppose one horrible hack I could employ would be to use a Ruby script or
Java class to post it as a regular HTTP post and then simply not specify a
send element so that it doesn't get posted from Synapse?

jeff

On Thu, Mar 27, 2008 at 9:25 AM, Jeff Davis <jd...@idalica.com> wrote:

> I played around with a jRuby script that adds the CDATA segment back, but
> unfortunately, when the XML is sent out, it again resorts to the other
> behavior (this is probably an obvious thing to you guys,but I'm not as
> familiar with the inner workings of Synapse). It sounds like I might be out
> of luck here, and as someone pointed earlier, it's not an issue with
> Synapse, per se, but an erroneously design web service.
>
> I take it there is no way to send back a "raw" request, whereby no XML
> processing is done (basically posts a string, as-is).
>
> jeff
>
>
> On Thu, Mar 27, 2008 at 8:51 AM, Paul Fremantle <pz...@gmail.com> wrote:
>
> > Is there a way we can create a mediator that reconverts back to a
> > CDATA? I've played around a bit with Axiom, but it seems a little
> > tricky to force CDATA.
> >
> > Paul
> >
> > ---------- Forwarded message ----------
> > From: Paul Fremantle <pz...@gmail.com>
> > Date: Thu, Mar 27, 2008 at 2:19 PM
> > Subject: Re: Interesting problem introduced by CDATA section
> > To: user@synapse.apache.org
> >
> >
> > Jeff
> >
> >  The annoying answer is that the service is wrong - its an XML error to
> >  differentiate between those two XMLs.
> >  However, we'll see if there is a way to sort this out.
> >
> >  Paul
> >
> >
> >
> >  On Thu, Mar 27, 2008 at 4:28 AM, Jeff Davis <jd...@idalica.com> wrote:
> >  > Well, the problem is that the web service receiving the request
> > validates
> >  >  it, and they have it setup on their side so that if the CDATA isnt'
> > present,
> >  >  the service call fails because of validation errors. I have to have
> > that
> >  >  present or it won't work (it's a partner's service).
> >  >
> >  >  jeff
> >  >
> >  >
> >  >
> >  >  On Wed, Mar 26, 2008 at 10:05 PM, Upul Godage <up...@gmail.com>
> > wrote:
> >  >
> >  >  > Content wise there is no difference between CDATA sections and the
> >  >  > resultant
> >  >  > escaped text data.  < cannot be in parsed character data so it is
> >  >  > converted
> >  >  > to &lt; so it is not mixed up with element starting elements. I
> > think when
> >  >  > reading from the parser, default parser does not make a difference
> > between
> >  >  > the CDATA sections and the normal text sections and the Synapse
> > sees them
> >  >  > as
> >  >  > just normal text. So the significance of CDATA markers are dropped
> > when it
> >  >  > is parsed. Only the serialized form changes but the "content
> > remains
> >  >  > exactly
> >  >  > the same."
> >  >  >
> >  >  > Do you face a problem when not having it in the extact CDATA form?
> >  >  >
> >  >  > Upul
> >  >  >
> >  >  >
> >  >  >
> >  >  > On Thu, Mar 27, 2008 at 8:07 AM, Jeff Davis <jd...@idalica.com>
> > wrote:
> >  >  >
> >  >  > > I'm attempting to access a SOAP web service that, unfortunately,
> > uses a
> >  >  > > CDATA section within the body of the XML (this wasn't my
> > choosing, :-).
> >  >  > > The
> >  >  > > abbreviated XML looks like:
> >  >  > >
> >  >  > > <env:Envelope xmlns:env="http://www.xxx.com/hrit/envelope"
> >  >  > >    xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
> >  >  > >    xmlns:datetime="http://exslt.org/dates-and-times">
> >  >  > >    <env:Sender>
> >  >  > >        <env:id>test</env:id>
> >  >  > >    </env:Sender>
> >  >  > >
> >  >  > >    <env:Packet>
> >  >  > >        <env:PacketInfo packetType="data">
> >  >  > >            <env:packetId>1</env:packetId>
> >  >  > >        </env:PacketInfo>
> >  >  > >        <env:payload><![CDATA[
> >  >  > > <Candidate xmlns="http://ns.hr-xml.org/2004-08-02" >
> >  >  > > <test>
> >  >  > >    <info>this is a test</info>
> >  >  > > </test>]]></env:payload>
> >  >  > >    </env:Packet>
> >  >  > > </env:Envelope>
> >  >  > >
> >  >  > > The issue I encounter is that, when this is sent out by Synapse,
> > it
> >  >  > > appears
> >  >  > > as (not showing the soap wrapper):
> >  >  > >
> >  >  > > <env:Envelope xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
> >  >  > > xmlns:datetime="
> >  >  > > http://exslt.org/dates-and-times">
> >  >  > >    <env:Sender>
> >  >  > >        <env:id>test</env:id>
> >  >  > >    </env:Sender>
> >  >  > >
> >  >  > >    <env:Packet>
> >  >  > >        <env:PacketInfo packetType="data">
> >  >  > >            <env:packetId>1</env:packetId>
> >  >  > >        </env:PacketInfo>
> >  >  > >        <env:payload>
> >  >  > >            &lt;Candidate xmlns="http://ns.hr-xml.org/2004-08-02"
> >  >  > > xmlns:oa="
> >  >  > > http://www.openapplications.org/oagis" xmlns:ds="
> >  >  > > http://www.w3.org/2000/09/xmldsig#">
> >  >  > >            &lt;test>
> >  >  > >            &lt;info>this is a test&lt;/info>
> >  >  > >            &lt;/test></env:payload>
> >  >  > >    </env:Packet>
> >  >  > > </env:Envelope>
> >  >  > >
> >  >  > > Notice the CDATA section has disappeared, and the unwanted &lt;
> > appear
> >  >  > in
> >  >  > > lieu of the < within that. Researching the issue a bit, I
> > discovered
> >  >  > this
> >  >  > > is
> >  >  > > the expected behavior from Saxon (which I believe is the XSTL
> > being used
> >  >  > > by
> >  >  > > Synapse). I can reproduce this if I just use a blank stylesheet.
> > Now, if
> >  >  > I
> >  >  > > apply this stylesheet and run it through Saxon manually, it
> > works great:
> >  >  > >
> >  >  > > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> >  >  > version="
> >  >  > > 2.0"  xmlns:env="http://www.xxx.com/hrit/envelope">
> >  >  > >    <xsl:output use-character-maps="xml"
> >  >  > > cdata-section-elements="env:payload"/>
> >  >  > >    <xsl:character-map name="xml">
> >  >  > >        <xsl:output-character character="&lt;" string="&lt;" />
> >  >  > >        <xsl:output-character character="&gt;" string="&gt;" />
> >  >  > >        <xsl:output-character character="&#xD;" string="&#xD;" />
> >  >  > >        <xsl:output-character character="&#47;" string="&#47;" />
> >  >  > >        <xsl:output-character character="&#xE0F1;"
> >  >  > string="&lt;![CDATA["/>
> >  >  > >        <xsl:output-character character="&#xE0F2;" string="]]>"/>
> >  >  > >    </xsl:character-map>
> >  >  > >
> >  >  > >        <xsl:template match="/'">
> >  >  > >                   <xsl:copy-of select="*" />
> >  >  > >        </xsl:template>
> >  >  > >
> >  >  > > </xsl:stylesheet>
> >  >  > >
> >  >  > > Unfortunately, when I plugin this stylesheet into the Synapse
> > <in>
> >  >  > route,
> >  >  > > it
> >  >  > > has no apparent affect (I twiddled with it to make sure it was,
> > in fact,
> >  >  > > being used, and it was).
> >  >  > >
> >  >  > > This is leaving me with a real quandary -- any suggestions?
> >  >  > >
> >  >  > > jeff
> >  >  > >
> >  >  >
> >  >
> >  >
> >  >
> >  >  --
> >  >  Jeff Davis
> >  >  Senior Architect
> >  >  Idalica Corporation
> >  >  MSN: jeffdavis_ca@hotmail.com
> >  >  Skype: jeffdavis_ca
> >  >  Phone: 719-287-8656
> >  >  Enabling Business Through Open Source Technologies
> >  >  www.idalica.com
> >  >
> >  >  IMPORTANT: This electronic message is for exclusive use by the
> > person(s) to
> >  >  whom it is addressed, and may contain information that is
> > confidential or
> >  >  privileged and exempt from disclosure under applicable law. If you
> > are not
> >  >  an intended recipient, please be aware that any disclosure,
> > dissemination,
> >  >  distribution or copying of this communication, or the use of its
> > contents,
> >  >  is prohibited. If you have received this message in error, please
> >  >  immediately notify the sender of your inadvertent receipt and delete
> > this
> >  >  message from all data storage systems.
> >  >
> >
> >
> >
> >  --
> >  Paul Fremantle
> >  Co-Founder and VP of Technical Sales, WSO2
> >  Apache Synapse PMC Chair
> >  OASIS WS-RX TC Co-chair
> >
> >  blog: http://pzf.fremantle.org
> >  paul@wso2.com
> >
> >  "Oxygenating the Web Service Platform", www.wso2.com
> >
> >
> >
> > --
> > Paul Fremantle
> > Co-Founder and VP of Technical Sales, WSO2
> > Apache Synapse PMC Chair
> > OASIS WS-RX TC Co-chair
> >
> > blog: http://pzf.fremantle.org
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
>
>
>
> --
> Jeff Davis
> Senior Architect
> Idalica Corporation
> MSN: jeffdavis_ca@hotmail.com
> Skype: jeffdavis_ca
> Phone: 719-287-8656
> Enabling Business Through Open Source Technologies
> www.idalica.com
>
> IMPORTANT: This electronic message is for exclusive use by the person(s)
> to whom it is addressed, and may contain information that is confidential or
> privileged and exempt from disclosure under applicable law. If you are not
> an intended recipient, please be aware that any disclosure, dissemination,
> distribution or copying of this communication, or the use of its contents,
> is prohibited. If you have received this message in error, please
> immediately notify the sender of your inadvertent receipt and delete this
> message from all data storage systems.
>



-- 
Jeff Davis
Senior Architect
Idalica Corporation
MSN: jeffdavis_ca@hotmail.com
Skype: jeffdavis_ca
Phone: 719-287-8656
Enabling Business Through Open Source Technologies
www.idalica.com

IMPORTANT: This electronic message is for exclusive use by the person(s) to
whom it is addressed, and may contain information that is confidential or
privileged and exempt from disclosure under applicable law. If you are not
an intended recipient, please be aware that any disclosure, dissemination,
distribution or copying of this communication, or the use of its contents,
is prohibited. If you have received this message in error, please
immediately notify the sender of your inadvertent receipt and delete this
message from all data storage systems.

Re: Interesting problem introduced by CDATA section

Posted by Jeff Davis <jd...@idalica.com>.

I suppose one horrible hack I could employ would be to use a Ruby script or
Java class to post it as a regular HTTP post and then simply not specify a
send element so that it doesn't get posted from Synapse?

jeff

On Thu, Mar 27, 2008 at 9:25 AM, Jeff Davis <jd...@idalica.com> wrote:

> I played around with a jRuby script that adds the CDATA segment back, but
> unfortunately, when the XML is sent out, it again resorts to the other
> behavior (this is probably an obvious thing to you guys,but I'm not as
> familiar with the inner workings of Synapse). It sounds like I might be out
> of luck here, and as someone pointed earlier, it's not an issue with
> Synapse, per se, but an erroneously design web service.
>
> I take it there is no way to send back a "raw" request, whereby no XML
> processing is done (basically posts a string, as-is).
>
> jeff
>
>
> On Thu, Mar 27, 2008 at 8:51 AM, Paul Fremantle <pz...@gmail.com> wrote:
>
> > Is there a way we can create a mediator that reconverts back to a
> > CDATA? I've played around a bit with Axiom, but it seems a little
> > tricky to force CDATA.
> >
> > Paul
> >
> > ---------- Forwarded message ----------
> > From: Paul Fremantle <pz...@gmail.com>
> > Date: Thu, Mar 27, 2008 at 2:19 PM
> > Subject: Re: Interesting problem introduced by CDATA section
> > To: user@synapse.apache.org
> >
> >
> > Jeff
> >
> >  The annoying answer is that the service is wrong - its an XML error to
> >  differentiate between those two XMLs.
> >  However, we'll see if there is a way to sort this out.
> >
> >  Paul
> >
> >
> >
> >  On Thu, Mar 27, 2008 at 4:28 AM, Jeff Davis <jd...@idalica.com> wrote:
> >  > Well, the problem is that the web service receiving the request
> > validates
> >  >  it, and they have it setup on their side so that if the CDATA isnt'
> > present,
> >  >  the service call fails because of validation errors. I have to have
> > that
> >  >  present or it won't work (it's a partner's service).
> >  >
> >  >  jeff
> >  >
> >  >
> >  >
> >  >  On Wed, Mar 26, 2008 at 10:05 PM, Upul Godage <up...@gmail.com>
> > wrote:
> >  >
> >  >  > Content wise there is no difference between CDATA sections and the
> >  >  > resultant
> >  >  > escaped text data.  < cannot be in parsed character data so it is
> >  >  > converted
> >  >  > to &lt; so it is not mixed up with element starting elements. I
> > think when
> >  >  > reading from the parser, default parser does not make a difference
> > between
> >  >  > the CDATA sections and the normal text sections and the Synapse
> > sees them
> >  >  > as
> >  >  > just normal text. So the significance of CDATA markers are dropped
> > when it
> >  >  > is parsed. Only the serialized form changes but the "content
> > remains
> >  >  > exactly
> >  >  > the same."
> >  >  >
> >  >  > Do you face a problem when not having it in the extact CDATA form?
> >  >  >
> >  >  > Upul
> >  >  >
> >  >  >
> >  >  >
> >  >  > On Thu, Mar 27, 2008 at 8:07 AM, Jeff Davis <jd...@idalica.com>
> > wrote:
> >  >  >
> >  >  > > I'm attempting to access a SOAP web service that, unfortunately,
> > uses a
> >  >  > > CDATA section within the body of the XML (this wasn't my
> > choosing, :-).
> >  >  > > The
> >  >  > > abbreviated XML looks like:
> >  >  > >
> >  >  > > <env:Envelope xmlns:env="http://www.xxx.com/hrit/envelope"
> >  >  > >    xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
> >  >  > >    xmlns:datetime="http://exslt.org/dates-and-times">
> >  >  > >    <env:Sender>
> >  >  > >        <env:id>test</env:id>
> >  >  > >    </env:Sender>
> >  >  > >
> >  >  > >    <env:Packet>
> >  >  > >        <env:PacketInfo packetType="data">
> >  >  > >            <env:packetId>1</env:packetId>
> >  >  > >        </env:PacketInfo>
> >  >  > >        <env:payload><![CDATA[
> >  >  > > <Candidate xmlns="http://ns.hr-xml.org/2004-08-02" >
> >  >  > > <test>
> >  >  > >    <info>this is a test</info>
> >  >  > > </test>]]></env:payload>
> >  >  > >    </env:Packet>
> >  >  > > </env:Envelope>
> >  >  > >
> >  >  > > The issue I encounter is that, when this is sent out by Synapse,
> > it
> >  >  > > appears
> >  >  > > as (not showing the soap wrapper):
> >  >  > >
> >  >  > > <env:Envelope xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
> >  >  > > xmlns:datetime="
> >  >  > > http://exslt.org/dates-and-times">
> >  >  > >    <env:Sender>
> >  >  > >        <env:id>test</env:id>
> >  >  > >    </env:Sender>
> >  >  > >
> >  >  > >    <env:Packet>
> >  >  > >        <env:PacketInfo packetType="data">
> >  >  > >            <env:packetId>1</env:packetId>
> >  >  > >        </env:PacketInfo>
> >  >  > >        <env:payload>
> >  >  > >            &lt;Candidate xmlns="http://ns.hr-xml.org/2004-08-02"
> >  >  > > xmlns:oa="
> >  >  > > http://www.openapplications.org/oagis" xmlns:ds="
> >  >  > > http://www.w3.org/2000/09/xmldsig#">
> >  >  > >            &lt;test>
> >  >  > >            &lt;info>this is a test&lt;/info>
> >  >  > >            &lt;/test></env:payload>
> >  >  > >    </env:Packet>
> >  >  > > </env:Envelope>
> >  >  > >
> >  >  > > Notice the CDATA section has disappeared, and the unwanted &lt;
> > appear
> >  >  > in
> >  >  > > lieu of the < within that. Researching the issue a bit, I
> > discovered
> >  >  > this
> >  >  > > is
> >  >  > > the expected behavior from Saxon (which I believe is the XSTL
> > being used
> >  >  > > by
> >  >  > > Synapse). I can reproduce this if I just use a blank stylesheet.
> > Now, if
> >  >  > I
> >  >  > > apply this stylesheet and run it through Saxon manually, it
> > works great:
> >  >  > >
> >  >  > > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> >  >  > version="
> >  >  > > 2.0"  xmlns:env="http://www.xxx.com/hrit/envelope">
> >  >  > >    <xsl:output use-character-maps="xml"
> >  >  > > cdata-section-elements="env:payload"/>
> >  >  > >    <xsl:character-map name="xml">
> >  >  > >        <xsl:output-character character="&lt;" string="&lt;" />
> >  >  > >        <xsl:output-character character="&gt;" string="&gt;" />
> >  >  > >        <xsl:output-character character="&#xD;" string="&#xD;" />
> >  >  > >        <xsl:output-character character="&#47;" string="&#47;" />
> >  >  > >        <xsl:output-character character="&#xE0F1;"
> >  >  > string="&lt;![CDATA["/>
> >  >  > >        <xsl:output-character character="&#xE0F2;" string="]]>"/>
> >  >  > >    </xsl:character-map>
> >  >  > >
> >  >  > >        <xsl:template match="/'">
> >  >  > >                   <xsl:copy-of select="*" />
> >  >  > >        </xsl:template>
> >  >  > >
> >  >  > > </xsl:stylesheet>
> >  >  > >
> >  >  > > Unfortunately, when I plugin this stylesheet into the Synapse
> > <in>
> >  >  > route,
> >  >  > > it
> >  >  > > has no apparent affect (I twiddled with it to make sure it was,
> > in fact,
> >  >  > > being used, and it was).
> >  >  > >
> >  >  > > This is leaving me with a real quandary -- any suggestions?
> >  >  > >
> >  >  > > jeff
> >  >  > >
> >  >  >
> >  >
> >  >
> >  >
> >  >  --
> >  >  Jeff Davis
> >  >  Senior Architect
> >  >  Idalica Corporation
> >  >  MSN: jeffdavis_ca@hotmail.com
> >  >  Skype: jeffdavis_ca
> >  >  Phone: 719-287-8656
> >  >  Enabling Business Through Open Source Technologies
> >  >  www.idalica.com
> >  >
> >  >  IMPORTANT: This electronic message is for exclusive use by the
> > person(s) to
> >  >  whom it is addressed, and may contain information that is
> > confidential or
> >  >  privileged and exempt from disclosure under applicable law. If you
> > are not
> >  >  an intended recipient, please be aware that any disclosure,
> > dissemination,
> >  >  distribution or copying of this communication, or the use of its
> > contents,
> >  >  is prohibited. If you have received this message in error, please
> >  >  immediately notify the sender of your inadvertent receipt and delete
> > this
> >  >  message from all data storage systems.
> >  >
> >
> >
> >
> >  --
> >  Paul Fremantle
> >  Co-Founder and VP of Technical Sales, WSO2
> >  Apache Synapse PMC Chair
> >  OASIS WS-RX TC Co-chair
> >
> >  blog: http://pzf.fremantle.org
> >  paul@wso2.com
> >
> >  "Oxygenating the Web Service Platform", www.wso2.com
> >
> >
> >
> > --
> > Paul Fremantle
> > Co-Founder and VP of Technical Sales, WSO2
> > Apache Synapse PMC Chair
> > OASIS WS-RX TC Co-chair
> >
> > blog: http://pzf.fremantle.org
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
>
>
>
> --
> Jeff Davis
> Senior Architect
> Idalica Corporation
> MSN: jeffdavis_ca@hotmail.com
> Skype: jeffdavis_ca
> Phone: 719-287-8656
> Enabling Business Through Open Source Technologies
> www.idalica.com
>
> IMPORTANT: This electronic message is for exclusive use by the person(s)
> to whom it is addressed, and may contain information that is confidential or
> privileged and exempt from disclosure under applicable law. If you are not
> an intended recipient, please be aware that any disclosure, dissemination,
> distribution or copying of this communication, or the use of its contents,
> is prohibited. If you have received this message in error, please
> immediately notify the sender of your inadvertent receipt and delete this
> message from all data storage systems.
>



-- 
Jeff Davis
Senior Architect
Idalica Corporation
MSN: jeffdavis_ca@hotmail.com
Skype: jeffdavis_ca
Phone: 719-287-8656
Enabling Business Through Open Source Technologies
www.idalica.com

IMPORTANT: This electronic message is for exclusive use by the person(s) to
whom it is addressed, and may contain information that is confidential or
privileged and exempt from disclosure under applicable law. If you are not
an intended recipient, please be aware that any disclosure, dissemination,
distribution or copying of this communication, or the use of its contents,
is prohibited. If you have received this message in error, please
immediately notify the sender of your inadvertent receipt and delete this
message from all data storage systems.

Re: Interesting problem introduced by CDATA section

Posted by Jeff Davis <jd...@idalica.com>.

I played around with a jRuby script that adds the CDATA segment back, but
unfortunately, when the XML is sent out, it again resorts to the other
behavior (this is probably an obvious thing to you guys,but I'm not as
familiar with the inner workings of Synapse). It sounds like I might be out
of luck here, and as someone pointed earlier, it's not an issue with
Synapse, per se, but an erroneously design web service.

I take it there is no way to send back a "raw" request, whereby no XML
processing is done (basically posts a string, as-is).

jeff

On Thu, Mar 27, 2008 at 8:51 AM, Paul Fremantle <pz...@gmail.com> wrote:

> Is there a way we can create a mediator that reconverts back to a
> CDATA? I've played around a bit with Axiom, but it seems a little
> tricky to force CDATA.
>
> Paul
>
> ---------- Forwarded message ----------
> From: Paul Fremantle <pz...@gmail.com>
> Date: Thu, Mar 27, 2008 at 2:19 PM
> Subject: Re: Interesting problem introduced by CDATA section
> To: user@synapse.apache.org
>
>
> Jeff
>
>  The annoying answer is that the service is wrong - its an XML error to
>  differentiate between those two XMLs.
>  However, we'll see if there is a way to sort this out.
>
>  Paul
>
>
>
>  On Thu, Mar 27, 2008 at 4:28 AM, Jeff Davis <jd...@idalica.com> wrote:
>  > Well, the problem is that the web service receiving the request
> validates
>  >  it, and they have it setup on their side so that if the CDATA isnt'
> present,
>  >  the service call fails because of validation errors. I have to have
> that
>  >  present or it won't work (it's a partner's service).
>  >
>  >  jeff
>  >
>  >
>  >
>  >  On Wed, Mar 26, 2008 at 10:05 PM, Upul Godage <up...@gmail.com>
> wrote:
>  >
>  >  > Content wise there is no difference between CDATA sections and the
>  >  > resultant
>  >  > escaped text data.  < cannot be in parsed character data so it is
>  >  > converted
>  >  > to &lt; so it is not mixed up with element starting elements. I
> think when
>  >  > reading from the parser, default parser does not make a difference
> between
>  >  > the CDATA sections and the normal text sections and the Synapse sees
> them
>  >  > as
>  >  > just normal text. So the significance of CDATA markers are dropped
> when it
>  >  > is parsed. Only the serialized form changes but the "content remains
>  >  > exactly
>  >  > the same."
>  >  >
>  >  > Do you face a problem when not having it in the extact CDATA form?
>  >  >
>  >  > Upul
>  >  >
>  >  >
>  >  >
>  >  > On Thu, Mar 27, 2008 at 8:07 AM, Jeff Davis <jd...@idalica.com>
> wrote:
>  >  >
>  >  > > I'm attempting to access a SOAP web service that, unfortunately,
> uses a
>  >  > > CDATA section within the body of the XML (this wasn't my choosing,
> :-).
>  >  > > The
>  >  > > abbreviated XML looks like:
>  >  > >
>  >  > > <env:Envelope xmlns:env="http://www.xxx.com/hrit/envelope"
>  >  > >    xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
>  >  > >    xmlns:datetime="http://exslt.org/dates-and-times">
>  >  > >    <env:Sender>
>  >  > >        <env:id>test</env:id>
>  >  > >    </env:Sender>
>  >  > >
>  >  > >    <env:Packet>
>  >  > >        <env:PacketInfo packetType="data">
>  >  > >            <env:packetId>1</env:packetId>
>  >  > >        </env:PacketInfo>
>  >  > >        <env:payload><![CDATA[
>  >  > > <Candidate xmlns="http://ns.hr-xml.org/2004-08-02" >
>  >  > > <test>
>  >  > >    <info>this is a test</info>
>  >  > > </test>]]></env:payload>
>  >  > >    </env:Packet>
>  >  > > </env:Envelope>
>  >  > >
>  >  > > The issue I encounter is that, when this is sent out by Synapse,
> it
>  >  > > appears
>  >  > > as (not showing the soap wrapper):
>  >  > >
>  >  > > <env:Envelope xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
>  >  > > xmlns:datetime="
>  >  > > http://exslt.org/dates-and-times">
>  >  > >    <env:Sender>
>  >  > >        <env:id>test</env:id>
>  >  > >    </env:Sender>
>  >  > >
>  >  > >    <env:Packet>
>  >  > >        <env:PacketInfo packetType="data">
>  >  > >            <env:packetId>1</env:packetId>
>  >  > >        </env:PacketInfo>
>  >  > >        <env:payload>
>  >  > >            &lt;Candidate xmlns="http://ns.hr-xml.org/2004-08-02"
>  >  > > xmlns:oa="
>  >  > > http://www.openapplications.org/oagis" xmlns:ds="
>  >  > > http://www.w3.org/2000/09/xmldsig#">
>  >  > >            &lt;test>
>  >  > >            &lt;info>this is a test&lt;/info>
>  >  > >            &lt;/test></env:payload>
>  >  > >    </env:Packet>
>  >  > > </env:Envelope>
>  >  > >
>  >  > > Notice the CDATA section has disappeared, and the unwanted &lt;
> appear
>  >  > in
>  >  > > lieu of the < within that. Researching the issue a bit, I
> discovered
>  >  > this
>  >  > > is
>  >  > > the expected behavior from Saxon (which I believe is the XSTL
> being used
>  >  > > by
>  >  > > Synapse). I can reproduce this if I just use a blank stylesheet.
> Now, if
>  >  > I
>  >  > > apply this stylesheet and run it through Saxon manually, it works
> great:
>  >  > >
>  >  > > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>  >  > version="
>  >  > > 2.0"  xmlns:env="http://www.xxx.com/hrit/envelope">
>  >  > >    <xsl:output use-character-maps="xml"
>  >  > > cdata-section-elements="env:payload"/>
>  >  > >    <xsl:character-map name="xml">
>  >  > >        <xsl:output-character character="&lt;" string="&lt;" />
>  >  > >        <xsl:output-character character="&gt;" string="&gt;" />
>  >  > >        <xsl:output-character character="&#xD;" string="&#xD;" />
>  >  > >        <xsl:output-character character="&#47;" string="&#47;" />
>  >  > >        <xsl:output-character character="&#xE0F1;"
>  >  > string="&lt;![CDATA["/>
>  >  > >        <xsl:output-character character="&#xE0F2;" string="]]>"/>
>  >  > >    </xsl:character-map>
>  >  > >
>  >  > >        <xsl:template match="/'">
>  >  > >                   <xsl:copy-of select="*" />
>  >  > >        </xsl:template>
>  >  > >
>  >  > > </xsl:stylesheet>
>  >  > >
>  >  > > Unfortunately, when I plugin this stylesheet into the Synapse <in>
>  >  > route,
>  >  > > it
>  >  > > has no apparent affect (I twiddled with it to make sure it was, in
> fact,
>  >  > > being used, and it was).
>  >  > >
>  >  > > This is leaving me with a real quandary -- any suggestions?
>  >  > >
>  >  > > jeff
>  >  > >
>  >  >
>  >
>  >
>  >
>  >  --
>  >  Jeff Davis
>  >  Senior Architect
>  >  Idalica Corporation
>  >  MSN: jeffdavis_ca@hotmail.com
>  >  Skype: jeffdavis_ca
>  >  Phone: 719-287-8656
>  >  Enabling Business Through Open Source Technologies
>  >  www.idalica.com
>  >
>  >  IMPORTANT: This electronic message is for exclusive use by the
> person(s) to
>  >  whom it is addressed, and may contain information that is confidential
> or
>  >  privileged and exempt from disclosure under applicable law. If you are
> not
>  >  an intended recipient, please be aware that any disclosure,
> dissemination,
>  >  distribution or copying of this communication, or the use of its
> contents,
>  >  is prohibited. If you have received this message in error, please
>  >  immediately notify the sender of your inadvertent receipt and delete
> this
>  >  message from all data storage systems.
>  >
>
>
>
>  --
>  Paul Fremantle
>  Co-Founder and VP of Technical Sales, WSO2
>  Apache Synapse PMC Chair
>  OASIS WS-RX TC Co-chair
>
>  blog: http://pzf.fremantle.org
>  paul@wso2.com
>
>  "Oxygenating the Web Service Platform", www.wso2.com
>
>
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>



-- 
Jeff Davis
Senior Architect
Idalica Corporation
MSN: jeffdavis_ca@hotmail.com
Skype: jeffdavis_ca
Phone: 719-287-8656
Enabling Business Through Open Source Technologies
www.idalica.com

IMPORTANT: This electronic message is for exclusive use by the person(s) to
whom it is addressed, and may contain information that is confidential or
privileged and exempt from disclosure under applicable law. If you are not
an intended recipient, please be aware that any disclosure, dissemination,
distribution or copying of this communication, or the use of its contents,
is prohibited. If you have received this message in error, please
immediately notify the sender of your inadvertent receipt and delete this
message from all data storage systems.

Fwd: Interesting problem introduced by CDATA section

Posted by Paul Fremantle <pz...@gmail.com>.

Is there a way we can create a mediator that reconverts back to a
CDATA? I've played around a bit with Axiom, but it seems a little
tricky to force CDATA.

Paul

---------- Forwarded message ----------
From: Paul Fremantle <pz...@gmail.com>
Date: Thu, Mar 27, 2008 at 2:19 PM
Subject: Re: Interesting problem introduced by CDATA section
To: user@synapse.apache.org


Jeff

 The annoying answer is that the service is wrong - its an XML error to
 differentiate between those two XMLs.
 However, we'll see if there is a way to sort this out.

 Paul



 On Thu, Mar 27, 2008 at 4:28 AM, Jeff Davis <jd...@idalica.com> wrote:
 > Well, the problem is that the web service receiving the request validates
 >  it, and they have it setup on their side so that if the CDATA isnt' present,
 >  the service call fails because of validation errors. I have to have that
 >  present or it won't work (it's a partner's service).
 >
 >  jeff
 >
 >
 >
 >  On Wed, Mar 26, 2008 at 10:05 PM, Upul Godage <up...@gmail.com> wrote:
 >
 >  > Content wise there is no difference between CDATA sections and the
 >  > resultant
 >  > escaped text data.  < cannot be in parsed character data so it is
 >  > converted
 >  > to &lt; so it is not mixed up with element starting elements. I think when
 >  > reading from the parser, default parser does not make a difference between
 >  > the CDATA sections and the normal text sections and the Synapse sees them
 >  > as
 >  > just normal text. So the significance of CDATA markers are dropped when it
 >  > is parsed. Only the serialized form changes but the "content remains
 >  > exactly
 >  > the same."
 >  >
 >  > Do you face a problem when not having it in the extact CDATA form?
 >  >
 >  > Upul
 >  >
 >  >
 >  >
 >  > On Thu, Mar 27, 2008 at 8:07 AM, Jeff Davis <jd...@idalica.com> wrote:
 >  >
 >  > > I'm attempting to access a SOAP web service that, unfortunately, uses a
 >  > > CDATA section within the body of the XML (this wasn't my choosing, :-).
 >  > > The
 >  > > abbreviated XML looks like:
 >  > >
 >  > > <env:Envelope xmlns:env="http://www.xxx.com/hrit/envelope"
 >  > >    xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
 >  > >    xmlns:datetime="http://exslt.org/dates-and-times">
 >  > >    <env:Sender>
 >  > >        <env:id>test</env:id>
 >  > >    </env:Sender>
 >  > >
 >  > >    <env:Packet>
 >  > >        <env:PacketInfo packetType="data">
 >  > >            <env:packetId>1</env:packetId>
 >  > >        </env:PacketInfo>
 >  > >        <env:payload><![CDATA[
 >  > > <Candidate xmlns="http://ns.hr-xml.org/2004-08-02" >
 >  > > <test>
 >  > >    <info>this is a test</info>
 >  > > </test>]]></env:payload>
 >  > >    </env:Packet>
 >  > > </env:Envelope>
 >  > >
 >  > > The issue I encounter is that, when this is sent out by Synapse, it
 >  > > appears
 >  > > as (not showing the soap wrapper):
 >  > >
 >  > > <env:Envelope xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
 >  > > xmlns:datetime="
 >  > > http://exslt.org/dates-and-times">
 >  > >    <env:Sender>
 >  > >        <env:id>test</env:id>
 >  > >    </env:Sender>
 >  > >
 >  > >    <env:Packet>
 >  > >        <env:PacketInfo packetType="data">
 >  > >            <env:packetId>1</env:packetId>
 >  > >        </env:PacketInfo>
 >  > >        <env:payload>
 >  > >            &lt;Candidate xmlns="http://ns.hr-xml.org/2004-08-02"
 >  > > xmlns:oa="
 >  > > http://www.openapplications.org/oagis" xmlns:ds="
 >  > > http://www.w3.org/2000/09/xmldsig#">
 >  > >            &lt;test>
 >  > >            &lt;info>this is a test&lt;/info>
 >  > >            &lt;/test></env:payload>
 >  > >    </env:Packet>
 >  > > </env:Envelope>
 >  > >
 >  > > Notice the CDATA section has disappeared, and the unwanted &lt; appear
 >  > in
 >  > > lieu of the < within that. Researching the issue a bit, I discovered
 >  > this
 >  > > is
 >  > > the expected behavior from Saxon (which I believe is the XSTL being used
 >  > > by
 >  > > Synapse). I can reproduce this if I just use a blank stylesheet. Now, if
 >  > I
 >  > > apply this stylesheet and run it through Saxon manually, it works great:
 >  > >
 >  > > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
 >  > version="
 >  > > 2.0"  xmlns:env="http://www.xxx.com/hrit/envelope">
 >  > >    <xsl:output use-character-maps="xml"
 >  > > cdata-section-elements="env:payload"/>
 >  > >    <xsl:character-map name="xml">
 >  > >        <xsl:output-character character="&lt;" string="&lt;" />
 >  > >        <xsl:output-character character="&gt;" string="&gt;" />
 >  > >        <xsl:output-character character="&#xD;" string="&#xD;" />
 >  > >        <xsl:output-character character="&#47;" string="&#47;" />
 >  > >        <xsl:output-character character="&#xE0F1;"
 >  > string="&lt;![CDATA["/>
 >  > >        <xsl:output-character character="&#xE0F2;" string="]]>"/>
 >  > >    </xsl:character-map>
 >  > >
 >  > >        <xsl:template match="/'">
 >  > >                   <xsl:copy-of select="*" />
 >  > >        </xsl:template>
 >  > >
 >  > > </xsl:stylesheet>
 >  > >
 >  > > Unfortunately, when I plugin this stylesheet into the Synapse <in>
 >  > route,
 >  > > it
 >  > > has no apparent affect (I twiddled with it to make sure it was, in fact,
 >  > > being used, and it was).
 >  > >
 >  > > This is leaving me with a real quandary -- any suggestions?
 >  > >
 >  > > jeff
 >  > >
 >  >
 >
 >
 >
 >  --
 >  Jeff Davis
 >  Senior Architect
 >  Idalica Corporation
 >  MSN: jeffdavis_ca@hotmail.com
 >  Skype: jeffdavis_ca
 >  Phone: 719-287-8656
 >  Enabling Business Through Open Source Technologies
 >  www.idalica.com
 >
 >  IMPORTANT: This electronic message is for exclusive use by the person(s) to
 >  whom it is addressed, and may contain information that is confidential or
 >  privileged and exempt from disclosure under applicable law. If you are not
 >  an intended recipient, please be aware that any disclosure, dissemination,
 >  distribution or copying of this communication, or the use of its contents,
 >  is prohibited. If you have received this message in error, please
 >  immediately notify the sender of your inadvertent receipt and delete this
 >  message from all data storage systems.
 >



 --
 Paul Fremantle
 Co-Founder and VP of Technical Sales, WSO2
 Apache Synapse PMC Chair
 OASIS WS-RX TC Co-chair

 blog: http://pzf.fremantle.org
 paul@wso2.com

 "Oxygenating the Web Service Platform", www.wso2.com



-- 
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair

blog: http://pzf.fremantle.org
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

Fwd: Interesting problem introduced by CDATA section

Posted by Paul Fremantle <pz...@gmail.com>.

Is there a way we can create a mediator that reconverts back to a
CDATA? I've played around a bit with Axiom, but it seems a little
tricky to force CDATA.

Paul

---------- Forwarded message ----------
From: Paul Fremantle <pz...@gmail.com>
Date: Thu, Mar 27, 2008 at 2:19 PM
Subject: Re: Interesting problem introduced by CDATA section
To: user@synapse.apache.org


Jeff

 The annoying answer is that the service is wrong - its an XML error to
 differentiate between those two XMLs.
 However, we'll see if there is a way to sort this out.

 Paul



 On Thu, Mar 27, 2008 at 4:28 AM, Jeff Davis <jd...@idalica.com> wrote:
 > Well, the problem is that the web service receiving the request validates
 >  it, and they have it setup on their side so that if the CDATA isnt' present,
 >  the service call fails because of validation errors. I have to have that
 >  present or it won't work (it's a partner's service).
 >
 >  jeff
 >
 >
 >
 >  On Wed, Mar 26, 2008 at 10:05 PM, Upul Godage <up...@gmail.com> wrote:
 >
 >  > Content wise there is no difference between CDATA sections and the
 >  > resultant
 >  > escaped text data.  < cannot be in parsed character data so it is
 >  > converted
 >  > to &lt; so it is not mixed up with element starting elements. I think when
 >  > reading from the parser, default parser does not make a difference between
 >  > the CDATA sections and the normal text sections and the Synapse sees them
 >  > as
 >  > just normal text. So the significance of CDATA markers are dropped when it
 >  > is parsed. Only the serialized form changes but the "content remains
 >  > exactly
 >  > the same."
 >  >
 >  > Do you face a problem when not having it in the extact CDATA form?
 >  >
 >  > Upul
 >  >
 >  >
 >  >
 >  > On Thu, Mar 27, 2008 at 8:07 AM, Jeff Davis <jd...@idalica.com> wrote:
 >  >
 >  > > I'm attempting to access a SOAP web service that, unfortunately, uses a
 >  > > CDATA section within the body of the XML (this wasn't my choosing, :-).
 >  > > The
 >  > > abbreviated XML looks like:
 >  > >
 >  > > <env:Envelope xmlns:env="http://www.xxx.com/hrit/envelope"
 >  > >    xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
 >  > >    xmlns:datetime="http://exslt.org/dates-and-times">
 >  > >    <env:Sender>
 >  > >        <env:id>test</env:id>
 >  > >    </env:Sender>
 >  > >
 >  > >    <env:Packet>
 >  > >        <env:PacketInfo packetType="data">
 >  > >            <env:packetId>1</env:packetId>
 >  > >        </env:PacketInfo>
 >  > >        <env:payload><![CDATA[
 >  > > <Candidate xmlns="http://ns.hr-xml.org/2004-08-02" >
 >  > > <test>
 >  > >    <info>this is a test</info>
 >  > > </test>]]></env:payload>
 >  > >    </env:Packet>
 >  > > </env:Envelope>
 >  > >
 >  > > The issue I encounter is that, when this is sent out by Synapse, it
 >  > > appears
 >  > > as (not showing the soap wrapper):
 >  > >
 >  > > <env:Envelope xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
 >  > > xmlns:datetime="
 >  > > http://exslt.org/dates-and-times">
 >  > >    <env:Sender>
 >  > >        <env:id>test</env:id>
 >  > >    </env:Sender>
 >  > >
 >  > >    <env:Packet>
 >  > >        <env:PacketInfo packetType="data">
 >  > >            <env:packetId>1</env:packetId>
 >  > >        </env:PacketInfo>
 >  > >        <env:payload>
 >  > >            &lt;Candidate xmlns="http://ns.hr-xml.org/2004-08-02"
 >  > > xmlns:oa="
 >  > > http://www.openapplications.org/oagis" xmlns:ds="
 >  > > http://www.w3.org/2000/09/xmldsig#">
 >  > >            &lt;test>
 >  > >            &lt;info>this is a test&lt;/info>
 >  > >            &lt;/test></env:payload>
 >  > >    </env:Packet>
 >  > > </env:Envelope>
 >  > >
 >  > > Notice the CDATA section has disappeared, and the unwanted &lt; appear
 >  > in
 >  > > lieu of the < within that. Researching the issue a bit, I discovered
 >  > this
 >  > > is
 >  > > the expected behavior from Saxon (which I believe is the XSTL being used
 >  > > by
 >  > > Synapse). I can reproduce this if I just use a blank stylesheet. Now, if
 >  > I
 >  > > apply this stylesheet and run it through Saxon manually, it works great:
 >  > >
 >  > > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
 >  > version="
 >  > > 2.0"  xmlns:env="http://www.xxx.com/hrit/envelope">
 >  > >    <xsl:output use-character-maps="xml"
 >  > > cdata-section-elements="env:payload"/>
 >  > >    <xsl:character-map name="xml">
 >  > >        <xsl:output-character character="&lt;" string="&lt;" />
 >  > >        <xsl:output-character character="&gt;" string="&gt;" />
 >  > >        <xsl:output-character character="&#xD;" string="&#xD;" />
 >  > >        <xsl:output-character character="&#47;" string="&#47;" />
 >  > >        <xsl:output-character character="&#xE0F1;"
 >  > string="&lt;![CDATA["/>
 >  > >        <xsl:output-character character="&#xE0F2;" string="]]>"/>
 >  > >    </xsl:character-map>
 >  > >
 >  > >        <xsl:template match="/'">
 >  > >                   <xsl:copy-of select="*" />
 >  > >        </xsl:template>
 >  > >
 >  > > </xsl:stylesheet>
 >  > >
 >  > > Unfortunately, when I plugin this stylesheet into the Synapse <in>
 >  > route,
 >  > > it
 >  > > has no apparent affect (I twiddled with it to make sure it was, in fact,
 >  > > being used, and it was).
 >  > >
 >  > > This is leaving me with a real quandary -- any suggestions?
 >  > >
 >  > > jeff
 >  > >
 >  >
 >
 >
 >
 >  --
 >  Jeff Davis
 >  Senior Architect
 >  Idalica Corporation
 >  MSN: jeffdavis_ca@hotmail.com
 >  Skype: jeffdavis_ca
 >  Phone: 719-287-8656
 >  Enabling Business Through Open Source Technologies
 >  www.idalica.com
 >
 >  IMPORTANT: This electronic message is for exclusive use by the person(s) to
 >  whom it is addressed, and may contain information that is confidential or
 >  privileged and exempt from disclosure under applicable law. If you are not
 >  an intended recipient, please be aware that any disclosure, dissemination,
 >  distribution or copying of this communication, or the use of its contents,
 >  is prohibited. If you have received this message in error, please
 >  immediately notify the sender of your inadvertent receipt and delete this
 >  message from all data storage systems.
 >



 --
 Paul Fremantle
 Co-Founder and VP of Technical Sales, WSO2
 Apache Synapse PMC Chair
 OASIS WS-RX TC Co-chair

 blog: http://pzf.fremantle.org
 paul@wso2.com

 "Oxygenating the Web Service Platform", www.wso2.com



-- 
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair

blog: http://pzf.fremantle.org
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org

Re: Interesting problem introduced by CDATA section

Posted by Paul Fremantle <pz...@gmail.com>.

Jeff

The annoying answer is that the service is wrong - its an XML error to
differentiate between those two XMLs.
However, we'll see if there is a way to sort this out.

Paul

On Thu, Mar 27, 2008 at 4:28 AM, Jeff Davis <jd...@idalica.com> wrote:
> Well, the problem is that the web service receiving the request validates
>  it, and they have it setup on their side so that if the CDATA isnt' present,
>  the service call fails because of validation errors. I have to have that
>  present or it won't work (it's a partner's service).
>
>  jeff
>
>
>
>  On Wed, Mar 26, 2008 at 10:05 PM, Upul Godage <up...@gmail.com> wrote:
>
>  > Content wise there is no difference between CDATA sections and the
>  > resultant
>  > escaped text data.  < cannot be in parsed character data so it is
>  > converted
>  > to &lt; so it is not mixed up with element starting elements. I think when
>  > reading from the parser, default parser does not make a difference between
>  > the CDATA sections and the normal text sections and the Synapse sees them
>  > as
>  > just normal text. So the significance of CDATA markers are dropped when it
>  > is parsed. Only the serialized form changes but the "content remains
>  > exactly
>  > the same."
>  >
>  > Do you face a problem when not having it in the extact CDATA form?
>  >
>  > Upul
>  >
>  >
>  >
>  > On Thu, Mar 27, 2008 at 8:07 AM, Jeff Davis <jd...@idalica.com> wrote:
>  >
>  > > I'm attempting to access a SOAP web service that, unfortunately, uses a
>  > > CDATA section within the body of the XML (this wasn't my choosing, :-).
>  > > The
>  > > abbreviated XML looks like:
>  > >
>  > > <env:Envelope xmlns:env="http://www.xxx.com/hrit/envelope"
>  > >    xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
>  > >    xmlns:datetime="http://exslt.org/dates-and-times">
>  > >    <env:Sender>
>  > >        <env:id>test</env:id>
>  > >    </env:Sender>
>  > >
>  > >    <env:Packet>
>  > >        <env:PacketInfo packetType="data">
>  > >            <env:packetId>1</env:packetId>
>  > >        </env:PacketInfo>
>  > >        <env:payload><![CDATA[
>  > > <Candidate xmlns="http://ns.hr-xml.org/2004-08-02" >
>  > > <test>
>  > >    <info>this is a test</info>
>  > > </test>]]></env:payload>
>  > >    </env:Packet>
>  > > </env:Envelope>
>  > >
>  > > The issue I encounter is that, when this is sent out by Synapse, it
>  > > appears
>  > > as (not showing the soap wrapper):
>  > >
>  > > <env:Envelope xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
>  > > xmlns:datetime="
>  > > http://exslt.org/dates-and-times">
>  > >    <env:Sender>
>  > >        <env:id>test</env:id>
>  > >    </env:Sender>
>  > >
>  > >    <env:Packet>
>  > >        <env:PacketInfo packetType="data">
>  > >            <env:packetId>1</env:packetId>
>  > >        </env:PacketInfo>
>  > >        <env:payload>
>  > >            &lt;Candidate xmlns="http://ns.hr-xml.org/2004-08-02"
>  > > xmlns:oa="
>  > > http://www.openapplications.org/oagis" xmlns:ds="
>  > > http://www.w3.org/2000/09/xmldsig#">
>  > >            &lt;test>
>  > >            &lt;info>this is a test&lt;/info>
>  > >            &lt;/test></env:payload>
>  > >    </env:Packet>
>  > > </env:Envelope>
>  > >
>  > > Notice the CDATA section has disappeared, and the unwanted &lt; appear
>  > in
>  > > lieu of the < within that. Researching the issue a bit, I discovered
>  > this
>  > > is
>  > > the expected behavior from Saxon (which I believe is the XSTL being used
>  > > by
>  > > Synapse). I can reproduce this if I just use a blank stylesheet. Now, if
>  > I
>  > > apply this stylesheet and run it through Saxon manually, it works great:
>  > >
>  > > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>  > version="
>  > > 2.0"  xmlns:env="http://www.xxx.com/hrit/envelope">
>  > >    <xsl:output use-character-maps="xml"
>  > > cdata-section-elements="env:payload"/>
>  > >    <xsl:character-map name="xml">
>  > >        <xsl:output-character character="&lt;" string="&lt;" />
>  > >        <xsl:output-character character="&gt;" string="&gt;" />
>  > >        <xsl:output-character character="&#xD;" string="&#xD;" />
>  > >        <xsl:output-character character="&#47;" string="&#47;" />
>  > >        <xsl:output-character character="&#xE0F1;"
>  > string="&lt;![CDATA["/>
>  > >        <xsl:output-character character="&#xE0F2;" string="]]>"/>
>  > >    </xsl:character-map>
>  > >
>  > >        <xsl:template match="/'">
>  > >                   <xsl:copy-of select="*" />
>  > >        </xsl:template>
>  > >
>  > > </xsl:stylesheet>
>  > >
>  > > Unfortunately, when I plugin this stylesheet into the Synapse <in>
>  > route,
>  > > it
>  > > has no apparent affect (I twiddled with it to make sure it was, in fact,
>  > > being used, and it was).
>  > >
>  > > This is leaving me with a real quandary -- any suggestions?
>  > >
>  > > jeff
>  > >
>  >
>
>
>
>  --
>  Jeff Davis
>  Senior Architect
>  Idalica Corporation
>  MSN: jeffdavis_ca@hotmail.com
>  Skype: jeffdavis_ca
>  Phone: 719-287-8656
>  Enabling Business Through Open Source Technologies
>  www.idalica.com
>
>  IMPORTANT: This electronic message is for exclusive use by the person(s) to
>  whom it is addressed, and may contain information that is confidential or
>  privileged and exempt from disclosure under applicable law. If you are not
>  an intended recipient, please be aware that any disclosure, dissemination,
>  distribution or copying of this communication, or the use of its contents,
>  is prohibited. If you have received this message in error, please
>  immediately notify the sender of your inadvertent receipt and delete this
>  message from all data storage systems.
>



-- 
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair

blog: http://pzf.fremantle.org
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

Re: Interesting problem introduced by CDATA section

Posted by Jeff Davis <jd...@idalica.com>.

Well, the problem is that the web service receiving the request validates
it, and they have it setup on their side so that if the CDATA isnt' present,
the service call fails because of validation errors. I have to have that
present or it won't work (it's a partner's service).

jeff

On Wed, Mar 26, 2008 at 10:05 PM, Upul Godage <up...@gmail.com> wrote:

> Content wise there is no difference between CDATA sections and the
> resultant
> escaped text data.  < cannot be in parsed character data so it is
> converted
> to &lt; so it is not mixed up with element starting elements. I think when
> reading from the parser, default parser does not make a difference between
> the CDATA sections and the normal text sections and the Synapse sees them
> as
> just normal text. So the significance of CDATA markers are dropped when it
> is parsed. Only the serialized form changes but the "content remains
> exactly
> the same."
>
> Do you face a problem when not having it in the extact CDATA form?
>
> Upul
>
>
>
> On Thu, Mar 27, 2008 at 8:07 AM, Jeff Davis <jd...@idalica.com> wrote:
>
> > I'm attempting to access a SOAP web service that, unfortunately, uses a
> > CDATA section within the body of the XML (this wasn't my choosing, :-).
> > The
> > abbreviated XML looks like:
> >
> > <env:Envelope xmlns:env="http://www.xxx.com/hrit/envelope"
> >    xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
> >    xmlns:datetime="http://exslt.org/dates-and-times">
> >    <env:Sender>
> >        <env:id>test</env:id>
> >    </env:Sender>
> >
> >    <env:Packet>
> >        <env:PacketInfo packetType="data">
> >            <env:packetId>1</env:packetId>
> >        </env:PacketInfo>
> >        <env:payload><![CDATA[
> > <Candidate xmlns="http://ns.hr-xml.org/2004-08-02" >
> > <test>
> >    <info>this is a test</info>
> > </test>]]></env:payload>
> >    </env:Packet>
> > </env:Envelope>
> >
> > The issue I encounter is that, when this is sent out by Synapse, it
> > appears
> > as (not showing the soap wrapper):
> >
> > <env:Envelope xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
> > xmlns:datetime="
> > http://exslt.org/dates-and-times">
> >    <env:Sender>
> >        <env:id>test</env:id>
> >    </env:Sender>
> >
> >    <env:Packet>
> >        <env:PacketInfo packetType="data">
> >            <env:packetId>1</env:packetId>
> >        </env:PacketInfo>
> >        <env:payload>
> >            &lt;Candidate xmlns="http://ns.hr-xml.org/2004-08-02"
> > xmlns:oa="
> > http://www.openapplications.org/oagis" xmlns:ds="
> > http://www.w3.org/2000/09/xmldsig#">
> >            &lt;test>
> >            &lt;info>this is a test&lt;/info>
> >            &lt;/test></env:payload>
> >    </env:Packet>
> > </env:Envelope>
> >
> > Notice the CDATA section has disappeared, and the unwanted &lt; appear
> in
> > lieu of the < within that. Researching the issue a bit, I discovered
> this
> > is
> > the expected behavior from Saxon (which I believe is the XSTL being used
> > by
> > Synapse). I can reproduce this if I just use a blank stylesheet. Now, if
> I
> > apply this stylesheet and run it through Saxon manually, it works great:
> >
> > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> version="
> > 2.0"  xmlns:env="http://www.xxx.com/hrit/envelope">
> >    <xsl:output use-character-maps="xml"
> > cdata-section-elements="env:payload"/>
> >    <xsl:character-map name="xml">
> >        <xsl:output-character character="&lt;" string="&lt;" />
> >        <xsl:output-character character="&gt;" string="&gt;" />
> >        <xsl:output-character character="&#xD;" string="&#xD;" />
> >        <xsl:output-character character="&#47;" string="&#47;" />
> >        <xsl:output-character character="&#xE0F1;"
> string="&lt;![CDATA["/>
> >        <xsl:output-character character="&#xE0F2;" string="]]>"/>
> >    </xsl:character-map>
> >
> >        <xsl:template match="/'">
> >                   <xsl:copy-of select="*" />
> >        </xsl:template>
> >
> > </xsl:stylesheet>
> >
> > Unfortunately, when I plugin this stylesheet into the Synapse <in>
> route,
> > it
> > has no apparent affect (I twiddled with it to make sure it was, in fact,
> > being used, and it was).
> >
> > This is leaving me with a real quandary -- any suggestions?
> >
> > jeff
> >
>



-- 
Jeff Davis
Senior Architect
Idalica Corporation
MSN: jeffdavis_ca@hotmail.com
Skype: jeffdavis_ca
Phone: 719-287-8656
Enabling Business Through Open Source Technologies
www.idalica.com

IMPORTANT: This electronic message is for exclusive use by the person(s) to
whom it is addressed, and may contain information that is confidential or
privileged and exempt from disclosure under applicable law. If you are not
an intended recipient, please be aware that any disclosure, dissemination,
distribution or copying of this communication, or the use of its contents,
is prohibited. If you have received this message in error, please
immediately notify the sender of your inadvertent receipt and delete this
message from all data storage systems.

Re: Interesting problem introduced by CDATA section

Posted by Upul Godage <up...@gmail.com>.

Content wise there is no difference between CDATA sections and the resultant
escaped text data.  < cannot be in parsed character data so it is converted
to &lt; so it is not mixed up with element starting elements. I think when
reading from the parser, default parser does not make a difference between
the CDATA sections and the normal text sections and the Synapse sees them as
just normal text. So the significance of CDATA markers are dropped when it
is parsed. Only the serialized form changes but the "content remains exactly
the same."

Do you face a problem when not having it in the extact CDATA form?

Upul



On Thu, Mar 27, 2008 at 8:07 AM, Jeff Davis <jd...@idalica.com> wrote:

> I'm attempting to access a SOAP web service that, unfortunately, uses a
> CDATA section within the body of the XML (this wasn't my choosing, :-).
> The
> abbreviated XML looks like:
>
> <env:Envelope xmlns:env="http://www.xxx.com/hrit/envelope"
>    xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
>    xmlns:datetime="http://exslt.org/dates-and-times">
>    <env:Sender>
>        <env:id>test</env:id>
>    </env:Sender>
>
>    <env:Packet>
>        <env:PacketInfo packetType="data">
>            <env:packetId>1</env:packetId>
>        </env:PacketInfo>
>        <env:payload><![CDATA[
> <Candidate xmlns="http://ns.hr-xml.org/2004-08-02" >
> <test>
>    <info>this is a test</info>
> </test>]]></env:payload>
>    </env:Packet>
> </env:Envelope>
>
> The issue I encounter is that, when this is sent out by Synapse, it
> appears
> as (not showing the soap wrapper):
>
> <env:Envelope xmlns:hrxml="http://ns.hr-xml.org/2004-08-02"
> xmlns:datetime="
> http://exslt.org/dates-and-times">
>    <env:Sender>
>        <env:id>test</env:id>
>    </env:Sender>
>
>    <env:Packet>
>        <env:PacketInfo packetType="data">
>            <env:packetId>1</env:packetId>
>        </env:PacketInfo>
>        <env:payload>
>            &lt;Candidate xmlns="http://ns.hr-xml.org/2004-08-02"
> xmlns:oa="
> http://www.openapplications.org/oagis" xmlns:ds="
> http://www.w3.org/2000/09/xmldsig#">
>            &lt;test>
>            &lt;info>this is a test&lt;/info>
>            &lt;/test></env:payload>
>    </env:Packet>
> </env:Envelope>
>
> Notice the CDATA section has disappeared, and the unwanted &lt; appear in
> lieu of the < within that. Researching the issue a bit, I discovered this
> is
> the expected behavior from Saxon (which I believe is the XSTL being used
> by
> Synapse). I can reproduce this if I just use a blank stylesheet. Now, if I
> apply this stylesheet and run it through Saxon manually, it works great:
>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="
> 2.0"  xmlns:env="http://www.xxx.com/hrit/envelope">
>    <xsl:output use-character-maps="xml"
> cdata-section-elements="env:payload"/>
>    <xsl:character-map name="xml">
>        <xsl:output-character character="&lt;" string="&lt;" />
>        <xsl:output-character character="&gt;" string="&gt;" />
>        <xsl:output-character character="&#xD;" string="&#xD;" />
>        <xsl:output-character character="&#47;" string="&#47;" />
>        <xsl:output-character character="&#xE0F1;" string="&lt;![CDATA["/>
>        <xsl:output-character character="&#xE0F2;" string="]]>"/>
>    </xsl:character-map>
>
>        <xsl:template match="/'">
>                   <xsl:copy-of select="*" />
>        </xsl:template>
>
> </xsl:stylesheet>
>
> Unfortunately, when I plugin this stylesheet into the Synapse <in> route,
> it
> has no apparent affect (I twiddled with it to make sure it was, in fact,
> being used, and it was).
>
> This is leaving me with a real quandary -- any suggestions?
>
> jeff
>