Hi Glen; +1, next tricky part is how to make use this on the server.I mean who mark the fragment to preserve the infoset. The security Handler do that, but then flag is set after the OM is parsed. So OM must preserve the information regardless of the flag value.
Thanks Srinath On 7/24/06, Glen Daniels <[EMAIL PROTECTED]> wrote:
Hi Srinath: Sorry for the late reply. > Agreed :) .. As long as we have a option and our security handlers > keep them enable by default .. Security case should be ok. > > Regarding the individual flag .. my first impression is it might be a > overkill. But there may be resobale use cases I think the use-case for the flag is that there might be particular bits of XML that are intended for re-use as fragments - if I specifically serialize those namespaces "in place" rather than letting the serializer optimize for me, then it's easier to do that. --Glen > Thanks > Srinath > > > > On 7/19/06, Glen Daniels <[EMAIL PROTECTED]> wrote: >> This sounds like a job for... >> >> OPTIONMAN! :) >> >> Clearly there should be a switch for this behavior. IMHO the default >> should be to "optimize" namespaces to serialize the minimum number >> possible, generating the leanest XML. There should be a global switch >> which can make all OMNamespaces serialize explicitly, and there should >> perhaps also be an individual flag on each OMNamespace which allows more >> subtly controlling which particular namespaces are going to be repeated >> or not. >> >> Thoughts? >> >> --Glen >> >> Srinath Perera wrote: >> > Actually I make it to print redundent namesapce >> > >> > The problem was .. security signature fails if they are optimized .. >> > and the SAML impl we use create a redundent name spaces .. which lead >> > to signature faliure. >> > >> > Thanks >> > Srinath >> > >> > On 7/19/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: >> >> Please note .. >> >> >> >> Sanjiva. >> >> >> >> >> >> >> >> ---------- Forwarded message ---------- >> >> From: "Tony Dean" <[EMAIL PROTECTED]> >> >> To: <[email protected]> >> >> Date: Wed, 19 Jul 2006 10:32:23 -0400 >> >> Subject: [Axis2] axiom redundant namespace serialization... >> >> Hi, >> >> >> >> I thought that I would just post this observation to the axis group >> >> since serialization of axiom objects directly affects the performance >> >> of axis2. >> >> >> >> In the past it seemed that axiom was doing a good job of not producing >> >> redundant namespace declarations, but with the July 18th snapshot, it >> >> does not seem as good. Let me explain. >> >> >> >> If I produce elements such as: >> >> >> >> QName qName = new QName("http://myNamespace";, "Element1"); >> >> OMElement element1 = omFactory.createOMElement(qName, null); >> >> >> >> qName = new Qname("http://myNamespace";, "Element2"); >> >> OMElement element2 = omFactory.createOMElement(qName, null); >> >> element1.addChild(element2); >> >> >> >> Now if I return this to axis2 engine as a response to service >> >> operation request, it will get serialized back to the client as >> >> something like the following: >> >> >> >> <axis2ns1:Element1 xmlns:axis2ns1="http://myNamepace";> >> >> <axis2ns2:Element2 xmlns:axis2ns2="http://myNamepace"/> >> >> </axis2ns1:Element1> >> >> >> >> Just think if you had many child elements in the same namespace. >> >> >> >> I would think an optimal, acceptable serialization would have been: >> >> >> >> <axis2ns1:Element1 xmlns:axis2ns1="http://myNamespace";> >> >> <axis2ns1:Element2/> >> >> </axis2ns1:Element2> >> >> >> >> or >> >> >> >> <Element1 xmlns="http://myNamepace";> >> >> <Element2/> >> >> </Element1> >> >> >> >> Thanks. >> >> >> >> >> >> Tony Dean >> >> SAS Institute Inc. >> >> 919.531.6704 >> >> [EMAIL PROTECTED] >> >> >> >> SAS... The Power to Know >> >> http://www.sas.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] >> >> >> >> >> > >> > >> >> --------------------------------------------------------------------- >> 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]
-- ============================ Srinath Perera: http://www.cs.indiana.edu/~hperera/ http://www.bloglines.com/blog/hemapani --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
