atom feed15 messages in org.apache.ws.synapse-devRe: Does CData work ?
FromSent OnAttachments
kimhornApr 14, 2009 9:28 pm 
Kim HornApr 14, 2009 9:32 pm 
Andreas VeithenApr 15, 2009 1:12 am 
kimhornApr 15, 2009 2:08 pm 
Andreas VeithenApr 16, 2009 2:41 pm 
kimhornApr 16, 2009 5:34 pm 
Andreas VeithenApr 17, 2009 1:08 am 
Andreas VeithenApr 18, 2009 5:44 am 
kimhornApr 19, 2009 3:18 pm 
Andreas VeithenApr 20, 2009 12:16 am 
Kim HornApr 26, 2009 8:12 pm 
Kim HornApr 26, 2009 9:11 pm 
Andreas VeithenMay 5, 2009 8:24 am 
Kim HornMay 5, 2009 11:32 pm 
kimhornMay 11, 2009 11:53 pm 
Subject:Re: Does CData work ?
From:Andreas Veithen (andr@gmail.com)
Date:Apr 20, 2009 12:16:11 am
List:org.apache.ws.synapse-dev

I think the risk is very small and is largely compensated by the fact that I did a whole bunch of bug fixes in Axiom.

Andreas

2009/4/20 kimhorn <kim.@icsglobal.net>:

That great Andreas, I will test it out.

Do you think using 1.2.9 with Synapse Snapshot and 1.3 could be a risk and result in other incompatabilities ?

Thanks so much Kim

Andreas Veithen-2 wrote:

Update: WSCOMMONS-461 is now implemented. See [1] for instructions on how to use this feature.

[1] http://people.apache.org/~veithen/synapse/faq.html#cdata

On Fri, Apr 17, 2009 at 02:34, kimhorn <kim.@icsglobal.net> wrote:

Hi,

thanks again for that. You saved me some time experimenting. I will look at Jira 280 etc; and wait for 1.2.9. Did you mean a Synapse snapshot ?

Andreas Veithen-2 wrote:

I think the primary issue is SYNAPSE-280. There are three solutions/workarounds for this issue:

1. Modify Synapse as described in the JIRA issue (only works for standalone deployments). 2. Make CDATA processing configurable at the Axiom level, as described in WSCOMMONS-461. This will only be ready for 1.2.9, but you can use a snapshot version. Since this is a change to a single class, we could also prepare a patch with this. 3. Simply upgrade Woodstox to 4.0.x, because in that version the XML parser is non coalescing by default (as required by the specs) and reports CDATA sections.

As mentioned in SYNAPSE-280, there could be issues because of code in Axis2 or Synapse that implicitly assumes that the parser is coalescing. If this problem arises, there is a workaround: by carefully setting the properties on the Woodstox parser, one can configure it to coalesce text nodes and CDATA sections separately (i.e. without merging text nodes and CDATA sections as in the real coalescing mode).

There is also another thing that could become an issue under some circumstances: when sending several consecutive CDATA events to a XMLStreamWriter, it will write them as distinct CDATA sections. This makes sense but it is a limitation when there is a need to wrap a very long text in a single CDATA section.

I'm not aware of any other issues related to CDATA sections.

On Wed, Apr 15, 2009 at 23:09, kimhorn <kim.@icsglobal.net> wrote:

Thanks, i'l try that. There was a lot of issues around CDATA, in the past, and I was wondering if Synapse (Axis, Axiom..) handles them before experimenting further ?

Andreas Veithen-2 wrote:

Is the Javascript the problem ? Note it is impossible to insert the CDATA in the Javascript as then the Javscript become invalid due to the nested CDATA. Hence why I used Java.

I see 3 possible ways to achieve this (assuming that the XML scripting supports CDATA sections, which needs to be confirmed):

* I think scripts can be loaded from registry entries and that plain text files are supported by the registry. In that case there is no problem with escaping.

* Instead of escaping the JavaScript using a CDATA section, use entities, i.e. replace all < by &lt;:

&lt;ws1:claimData>&lt;![CDATA["{claimData}"]]>&lt;/ws1:claimData>

* Escape the JavaScript using a CDATA section, except for the embedded ]]>:

<![CDATA[ ... <ws1:claimData><![CDATA["{claimData}"]]>]]><![CDATA[</ws1:claimData> ... ]]>

Alternatively, if you want something (slightly) more readable:

<![CDATA[ ... <ws1:claimData>]]>&lt;![CDATA["{claimData}"]]><![CDATA[</ws1:claimData> ... ]]>