Axiom never produces malformed XML. Who said that?? Andreas
On Sun, Nov 20, 2011 at 17:59, Sanjiva Weerawarana <[email protected]> wrote: > Isn't that a bug? > If I declare an NS at the Envelope node then that cannot be removed if > anyone inside uses it. If I'm serializing only the Header element(s) then > any in scope namespaces must be available and worst case every element will > re-serialize them. However under no condition is it correct to serialize a > child element and end up with malformed XML! > > Sanjiva. > > On Sat, Nov 19, 2011 at 10:28 PM, Andreas Veithen > <[email protected]> wrote: >> >> Assuming that the namespace in question is not the SOAP envelope >> namespace, instead of hacking Axiom, wouldn't it be easier to remove >> the namespace declaration from the SOAP envelope (so that it will be >> serialized in the SOAP header block)? >> >> Andreas >> >> On Sat, Nov 19, 2011 at 06:11, Charith Wickramarachchi >> <[email protected]> wrote: >> > Hi Andreas, >> > >> > Issue was this causes an Error in a 3rd party web-service engine when >> > processing some soap headers. >> > >> > Scenario is this. Synapse get a soap request which contains some >> > redundant >> > namespace declarations at header level which are internally used inside >> > the >> > headers. So when synapse forward them to the BE service they get >> > omitted as >> > they are defined at SOAP Envelope level. >> > >> > BE services header processor incorrectly assumes that headers are self >> > contained so this causes an error. >> > >> > I was wondering it may make scene to make it configurable as if we >> > think >> > of synapse point of view omitting redundant namespaces may not be a >> > good >> > idea sometimes. Specially integrating with legacies like this. WDYT ? ( >> > I do >> > agree that this in pure AXIOM point of view its the correct thing to do >> > as >> > it will reduce the data content that is written to the wire etc.. ) >> > >> > Can please you point me to a place where this is done ? So that i can >> > hack >> > the code for the time being for my self and later provide a patch if >> > devs >> > are ok with my above idea. >> > >> > thanks, >> > Charith >> > >> > >> > >> > >> > >> > On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen >> > <[email protected]> >> > wrote: >> >> >> >> No, the namespace repairing performed by the serialize and >> >> serializeAndConsume methods is not configurable. >> >> >> >> What is the use case for preserving a redundant namespace declaration >> >> on a SOAP header? >> >> >> >> Andreas >> >> >> >> On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi >> >> <[email protected]> wrote: >> >> > Hi devs , >> >> > >> >> > When we serialize a OMElement axiom will omit redundant namesspace >> >> > declarations by default. Is it possible to disable this behavior ? >> >> > In my case i want to keep the redundant namesspace declarations in >> >> > SOAP >> >> > headers. >> >> > >> >> > >> >> > thanks, >> >> > Charith >> >> > >> >> > -- >> >> > Charith Dhanushka Wickramarachchi >> >> > http://charithwiki.blogspot.com/ >> >> > >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> > >> > >> > >> > -- >> > Charith Dhanushka Wickramarachchi >> > http://charithwiki.blogspot.com/ >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > Sanjiva Weerawarana, Ph.D. > Founder, Director & Chief Scientist; Lanka Software Foundation; > http://www.opensource.lk/ > Founder, Chairman & CEO; WSO2; http://wso2.com/ > Founder & Director; Thinkcube Systems; http://www.thinkcube.com/ > Member; Apache Software Foundation; http://www.apache.org/ > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ > > Blog: http://sanjiva.weerawarana.org/ > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
