On Sun, May 2, 2010 at 05:58, Kasun Indrasiri <[email protected]> wrote: > Hi all, > So, are we going to live with coalescing parsing in Synapse? As > per SYNAPSE-280 which is pointed out by Andreas what are the benefits that > we can get from using non-coalescing mode in Synapse and in that case are we > planning to move to non-coalescing in the future? > And even though we resolve SYNAPSE-624 as 'not-a but', I guess > replacing OMText#getText by OMElement#getText() is still applicable.
I don't see any reason why we should not fix the code to make proper use of OMElement#getText(). > Thanks, > Kasun > > On Sat, May 1, 2010 at 3:05 PM, Hiranya Jayathilaka <[email protected]> > wrote: >> >> Hi Indika, >> >> On Fri, Apr 30, 2010 at 10:23 PM, indika kumara <[email protected]> >> wrote: >>> >>> Hiranya ... it seems that as Andreas pointed out in ws commons list, the >>> working with Axiom in non coalescing can be a risk. >> >> Yes. Actually that discussion helped me understand a lot. It seems the >> existing logic in Synapse+Axiom for handling local entries with CDATA >> elements is correct after all. The problem with serialization I pointed out >> in my previous mail is to be expected. Even though the serialized XML is >> lexically different from the input XML, their XML infosets are equal. Even >> though AXIOM has removed CDATA tags, the text has been encoded to escape any >> invalid characters like '<'. >> All in all I think we can live with the existing logic. We can resolve >> SYNAPSE-624 as 'not a bug'. However there are few things that need be >> properly communicated to the users through our docs. >> 1. If a local entry text contains any XML markup the whole text must be >> wrapped in CDATA tags >> eg: <localEntry >> key="foo"><![CDATA[mc.setPayloadXML(<xml>data</xml>);]]></localEntry> >> 2. If a local entry text contains XML markup and CDATA tags then we should >> properly escape the CDATA tags to avoid having nested CDATA elements. >> (Nested CDATA elements cause XML parser to throw a parse exception) >> eg: <localEntry >> key="foo"><![CDATA[mc.setPayloadXML(<xml><![CDATA[data]]]]><![CDATA[></xml>);]]></localEntry> >> 3. XML local entries with CDATA elements will not have the CDATA tags in >> the serialized version >> I have updated the test cases to cover all these scenarios and the >> expected behavior. >> Thanks, >> Hiranya >> >>> >>> is the 'coalescing' off/on a system property ? and if not , is there >>> any way to create a new parser instance in non coalescing mode only for >>> synapse configuration parsing ? >>> >>> Thanks >>> >>> Indika >>> >>> On Fri, Apr 30, 2010 at 6:41 PM, Hiranya Jayathilaka >>> <[email protected]> wrote: >>>> >>>> Hi Folks, >>>> While doing some work on SYNAPSE-624, I have realized that Synapse does >>>> not handle local entry values with CDATA elements properly. Axiom seems to >>>> drop CDATA elements while parsing XML. For an example given the following >>>> local entry configuration: >>>> <localEntry key="foo"><test><![CDATA[<SomeXML/>]]></test></localEntry> >>>> the serialized XML would be as follows: >>>> <localEntry key="foo"><test><SomeXML/></test></localEntry> >>>> >>>> Note that the CDATA element is gone, and its value has been partially >>>> encoded. The way out of this issue is to disable coalescing in the parser. >>>> But that would be globally applied to all XML parsing logic in Synapse >>>> (unless we somehow use a separate OM builder for parsing local entries). So >>>> how do you think we should handle this scenario? >>>> Thanks >>>> -- >>>> Hiranya Jayathilaka >>>> Software Engineer; >>>> WSO2 Inc.; http://wso2.org >>>> E-mail: [email protected]; Mobile: +94 77 633 3491 >>>> Blog: http://techfeast-hiranya.blogspot.com >>> >> >> >> >> -- >> Hiranya Jayathilaka >> Software Engineer; >> WSO2 Inc.; http://wso2.org >> E-mail: [email protected]; Mobile: +94 77 633 3491 >> Blog: http://techfeast-hiranya.blogspot.com > > > > -- > Kasun Indrasiri > Senior Software Engineer, > WSO2 Inc. - "Lean . Enterprise . Middleware" - http://www.wso2.com/ > Blog : http://kasunpanorama.blogspot.com/ > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
