You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by Sanjiva Weerawarana <sa...@opensource.lk> on 2006/07/19 21:12:38 UTC

[Fwd: [Axis2] axiom redundant namespace serialization...]

Please note ..

Sanjiva.

Re: [Fwd: [Axis2] axiom redundant namespace serialization...]

Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi Srinath,
AFAIR OM always preserves the namespace information but does the
optimization while writing.

Ajith

On 7/25/06, Srinath Perera <he...@gmail.com> wrote:
> 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 <gl...@thoughtcraft.com> 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 <gl...@thoughtcraft.com> 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 <sa...@opensource.lk> wrote:
> > >> >> Please note ..
> > >> >>
> > >> >> Sanjiva.
> > >> >>
> > >> >>
> > >> >>
> > >> >> ---------- Forwarded message ----------
> > >> >> From: "Tony Dean" <To...@sas.com>
> > >> >> To: <ax...@ws.apache.org>
> > >> >> 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
> > >> >> tony.dean@sas.com
> > >> >>
> > >> >> SAS... The Power to Know
> > >> >> http://www.sas.com
> > >> >>
> > >> >>
> > >> >> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > >> >> For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> > >> >> For additional commands, e-mail: commons-dev-help@ws.apache.org
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: commons-dev-help@ws.apache.org
> > >>
> > >>
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: commons-dev-help@ws.apache.org
> >
> >
>
>
> --
> ============================
> Srinath Perera:
>    http://www.cs.indiana.edu/~hperera/
>    http://www.bloglines.com/blog/hemapani
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>


-- 
Ajith Ranabahu

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org


Re: [Fwd: [Axis2] axiom redundant namespace serialization...]

Posted by Srinath Perera <he...@gmail.com>.
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 <gl...@thoughtcraft.com> 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 <gl...@thoughtcraft.com> 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 <sa...@opensource.lk> wrote:
> >> >> Please note ..
> >> >>
> >> >> Sanjiva.
> >> >>
> >> >>
> >> >>
> >> >> ---------- Forwarded message ----------
> >> >> From: "Tony Dean" <To...@sas.com>
> >> >> To: <ax...@ws.apache.org>
> >> >> 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
> >> >> tony.dean@sas.com
> >> >>
> >> >> SAS... The Power to Know
> >> >> http://www.sas.com
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> >> >> For additional commands, e-mail: axis-dev-help@ws.apache.org
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> >> >> For additional commands, e-mail: commons-dev-help@ws.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: commons-dev-help@ws.apache.org
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>


-- 
============================
Srinath Perera:
   http://www.cs.indiana.edu/~hperera/
   http://www.bloglines.com/blog/hemapani

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org


Re: [Fwd: [Axis2] axiom redundant namespace serialization...]

Posted by Glen Daniels <gl...@thoughtcraft.com>.
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 <gl...@thoughtcraft.com> 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 <sa...@opensource.lk> wrote:
>> >> Please note ..
>> >>
>> >> Sanjiva.
>> >>
>> >>
>> >>
>> >> ---------- Forwarded message ----------
>> >> From: "Tony Dean" <To...@sas.com>
>> >> To: <ax...@ws.apache.org>
>> >> 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
>> >> tony.dean@sas.com
>> >>
>> >> SAS... The Power to Know
>> >> http://www.sas.com
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: axis-dev-help@ws.apache.org
>> >>
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: commons-dev-help@ws.apache.org
>> >>
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: commons-dev-help@ws.apache.org
>>
>>
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org


Re: [Fwd: [Axis2] axiom redundant namespace serialization...]

Posted by Srinath Perera <he...@gmail.com>.
Hi Glen;

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

Thanks
Srinath



On 7/19/06, Glen Daniels <gl...@thoughtcraft.com> 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 <sa...@opensource.lk> wrote:
> >> Please note ..
> >>
> >> Sanjiva.
> >>
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: "Tony Dean" <To...@sas.com>
> >> To: <ax...@ws.apache.org>
> >> 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
> >> tony.dean@sas.com
> >>
> >> SAS... The Power to Know
> >> http://www.sas.com
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-dev-help@ws.apache.org
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: commons-dev-help@ws.apache.org
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>


-- 
============================
Srinath Perera:
   http://www.cs.indiana.edu/~hperera/
   http://www.bloglines.com/blog/hemapani

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org


Re: [Fwd: [Axis2] axiom redundant namespace serialization...]

Posted by Glen Daniels <gl...@thoughtcraft.com>.
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 <sa...@opensource.lk> wrote:
>> Please note ..
>>
>> Sanjiva.
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: "Tony Dean" <To...@sas.com>
>> To: <ax...@ws.apache.org>
>> 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
>> tony.dean@sas.com
>>
>> SAS... The Power to Know
>> http://www.sas.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: commons-dev-help@ws.apache.org
>>
>>
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org


Re: [Fwd: [Axis2] axiom redundant namespace serialization...]

Posted by Srinath Perera <he...@gmail.com>.
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 <sa...@opensource.lk> wrote:
> Please note ..
>
> Sanjiva.
>
>
>
> ---------- Forwarded message ----------
> From: "Tony Dean" <To...@sas.com>
> To: <ax...@ws.apache.org>
> 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
> tony.dean@sas.com
>
> SAS... The Power to Know
> http://www.sas.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>


-- 
============================
Srinath Perera:
   http://www.cs.indiana.edu/~hperera/
   http://www.bloglines.com/blog/hemapani

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org