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 ?
Kim 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. > > > Andreas > > On Wed, Apr 15, 2009 at 23:09, kimhorn <[email protected]> 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 ? >> >> Kim >> >> >> 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 <: >>> >>> <ws1:claimData><![CDATA["{claimData}"]]></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>]]><![CDATA["{claimData}"]]><![CDATA[</ws1:claimData> >>> ... >>> ]]> >>> >>> >>> Andreas >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Does-CData-work---tp23052352p23067194.html >> Sent from the Synapse - Dev mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > -- View this message in context: http://www.nabble.com/Does-CData-work---tp23052352p23088563.html Sent from the Synapse - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
