Re: [Axis2] with Rampart -- XMLStreamException "the prefix ==> Already exists for namespace
Try for this
http://people.apache.org/repo/m2-snapshot-repository/org/apache/axis2/
On Mon, Nov 16, 2009 at 11:13 PM, Jaime Hablutzel Egoavil
wrote:
>
> I guess
>
> http://svn.apache.org/repos/asf/webservices/axis2/trunk/java/
>
> Jaime Hablutzel | 9-8964-0369
>
> (tildes omitidas intencionalmente)
>
>
>
>
>
>
>
> > Date: Mon, 16 Nov 2009 05:48:48 -0800
> > From: thiruma...@yahoo.com
> > To: axis-user@ws.apache.org
> > Subject: Re: [Axis2] with Rampart -- XMLStreamException "the prefix ==>
> > Already exists for namespace
> >
> >
> > Hi Axis User:
> >
> > Can you please anyone tell me where I can download the Axis2/Java
> > nightly builds (V 1.5)?
> > I have been asking for last 2 weeks. Nobody responded.
> >
> > Thanks
> > Srini
> >
> >
> > srini.maran wrote:
> > >
> > > Hi Amila.
> > >
> > > Where i can download the Axis2/Java nightly builds(V 1.5)? Please
> > > advice.
> > > We have PROD release scheduled in 2 weeks. I'd like to test this fix
> > > ASAP.
> > >
> > > Thanks
> > > Srini
> > >
> > >
> > > srini.maran wrote:
> > >>
> > >> Hi Amila.
> > >>
> > >> Thanks Amila..
> > >>
> > >> Please advice on where I can download Axis2/Java nightly builds(V 1.5),
> > >> The
> > >> Axis2 Website only points to a directory where only Axis2/C Nightly
> > >> downloads are available.
> > >>
> > >> Thanks
> > >> Srini
> > >>
> > >>
> > >> Amila Suriarachchi wrote:
> > >>>
> > >>> I removed this check please have a look at with a nightly build.
> > >>>
> > >>> thanks,
> > >>> Amila.
> > >>>
> > >>> On Thu, Oct 29, 2009 at 6:47 PM, srini.maran
> > >>> wrote:
> > >>>
> > >>>>
> > >>>> Hi Amila.
> > >>>>
> > >>>> Thanks for your response.
> > >>>>
> > >>>> I don't get it "Can you check this by using a response get without
> > >>>> rampart? ". Do you mean to say run
> > >>>> the client without Rampart enabled? or you are talking different.
> > >>>>
> > >>>> My client and server code is working fine without Rampart. It's
> > >>>> failing
> > >>>> when i enable Rampart. Basically,
> > >>>> it's failing in the client code when stub generates SOAP header with
> > >>>> auth
> > >>>> info(using policy file). It could be same issue in
> > >>>> server side too.
> > >>>>
> > >>>> Below is my client code:
> > >>>>
> > >>>> HubServiceStub stub = new
> > >>>> HubServiceStub("http://localhost:8180/";);
> > >>>> ServiceClient client = stub._getServiceClient();
> > >>>>
> > >>>> Options options = client.getOptions();
> > >>>> options.setProperty(RampartMessageData.KEY_RAMPART_POLICY,
> > >>>> loadPolicy("plain-policy-client.xml"));
> > >>>> options.setUserName("libuser");
> > >>>> options.setPassword("books");
> > >>>> client.engageModule("rampart");
> > >>>>
> > >>>> Channel2 chl1 = new Channel2();
> > >>>> // popultes the inpuit object
> > >>>> chl1.setAdmin("")
> > >>>>
> > >>>> .
> > >>>> MessageE resp = stub.hubFeed(chl1); --> throws exception.
> > >>>>
> > >>>> I am getting the exception when i invoke the service hubFeed.
> > >>>>
> > >>>> I am able to successfully test the Rampart & IBM article WS-security
> > >>>> sample apps with no issue. It's a
> > >>>> simple service with no complex schema.
> > >>>>
> > >>>> Please let me know if you need any further details.
> > >>>>
> > >>>> I will really appreciate you on helping me to solve this issue.
> > >>>>
> > >>>> Thanks
> > >>>> Srini
> > >>>>
> > >>>>
>
RE: [Axis2] with Rampart -- XMLStreamException "the prefix ==> Already exists for namespace
I guess
http://svn.apache.org/repos/asf/webservices/axis2/trunk/java/
Jaime Hablutzel | 9-8964-0369
(tildes omitidas intencionalmente)
> Date: Mon, 16 Nov 2009 05:48:48 -0800
> From: thiruma...@yahoo.com
> To: axis-user@ws.apache.org
> Subject: Re: [Axis2] with Rampart -- XMLStreamException "the prefix ==>
> Already exists for namespace
>
>
> Hi Axis User:
>
> Can you please anyone tell me where I can download the Axis2/Java
> nightly builds (V 1.5)?
> I have been asking for last 2 weeks. Nobody responded.
>
> Thanks
> Srini
>
>
> srini.maran wrote:
> >
> > Hi Amila.
> >
> > Where i can download the Axis2/Java nightly builds(V 1.5)? Please
> > advice.
> > We have PROD release scheduled in 2 weeks. I'd like to test this fix
> > ASAP.
> >
> > Thanks
> > Srini
> >
> >
> > srini.maran wrote:
> >>
> >> Hi Amila.
> >>
> >> Thanks Amila..
> >>
> >> Please advice on where I can download Axis2/Java nightly builds(V 1.5),
> >> The
> >> Axis2 Website only points to a directory where only Axis2/C Nightly
> >> downloads are available.
> >>
> >> Thanks
> >> Srini
> >>
> >>
> >> Amila Suriarachchi wrote:
> >>>
> >>> I removed this check please have a look at with a nightly build.
> >>>
> >>> thanks,
> >>> Amila.
> >>>
> >>> On Thu, Oct 29, 2009 at 6:47 PM, srini.maran
> >>> wrote:
> >>>
> >>>>
> >>>> Hi Amila.
> >>>>
> >>>> Thanks for your response.
> >>>>
> >>>> I don't get it "Can you check this by using a response get without
> >>>> rampart? ". Do you mean to say run
> >>>> the client without Rampart enabled? or you are talking different.
> >>>>
> >>>> My client and server code is working fine without Rampart. It's
> >>>> failing
> >>>> when i enable Rampart. Basically,
> >>>> it's failing in the client code when stub generates SOAP header with
> >>>> auth
> >>>> info(using policy file). It could be same issue in
> >>>> server side too.
> >>>>
> >>>> Below is my client code:
> >>>>
> >>>> HubServiceStub stub = new
> >>>> HubServiceStub("http://localhost:8180/";);
> >>>> ServiceClient client = stub._getServiceClient();
> >>>>
> >>>> Options options = client.getOptions();
> >>>> options.setProperty(RampartMessageData.KEY_RAMPART_POLICY,
> >>>>loadPolicy("plain-policy-client.xml"));
> >>>> options.setUserName("libuser");
> >>>> options.setPassword("books");
> >>>> client.engageModule("rampart");
> >>>>
> >>>> Channel2 chl1 = new Channel2();
> >>>> // popultes the inpuit object
> >>>> chl1.setAdmin("")
> >>>>
> >>>> .
> >>>> MessageE resp = stub.hubFeed(chl1); --> throws exception.
> >>>>
> >>>>I am getting the exception when i invoke the service hubFeed.
> >>>>
> >>>>I am able to successfully test the Rampart & IBM article WS-security
> >>>> sample apps with no issue. It's a
> >>>>simple service with no complex schema.
> >>>>
> >>>>Please let me know if you need any further details.
> >>>>
> >>>>I will really appreciate you on helping me to solve this issue.
> >>>>
> >>>> Thanks
> >>>> Srini
> >>>>
> >>>>
> >>>>
> >>>> Amila Suriarachchi wrote:
> >>>> >
> >>>> > On Wed, Oct 28, 2009 at 1:31 AM, Andreas Veithen
> >>>> > wrote:
> >>>> >
> >>>> >> Srini,
> >>>> >>
> >>>> >> Here is the explanation of this issue, as I see it:
> >>>> >>
> >>>> >> - When WS-Security is disabled, ADB streams the XML data directly to
> >>>> >> the wire, using an XMLStreamWriter from Woodstox (which is indeed
> >
Re: [Axis2] with Rampart -- XMLStreamException "the prefix ==> Already exists for namespace
Hi Axis User:
Can you please anyone tell me where I can download the Axis2/Java
nightly builds (V 1.5)?
I have been asking for last 2 weeks. Nobody responded.
Thanks
Srini
srini.maran wrote:
>
> Hi Amila.
>
> Where i can download the Axis2/Java nightly builds(V 1.5)? Please
> advice.
> We have PROD release scheduled in 2 weeks. I'd like to test this fix
> ASAP.
>
> Thanks
> Srini
>
>
> srini.maran wrote:
>>
>> Hi Amila.
>>
>> Thanks Amila..
>>
>> Please advice on where I can download Axis2/Java nightly builds(V 1.5),
>> The
>> Axis2 Website only points to a directory where only Axis2/C Nightly
>> downloads are available.
>>
>> Thanks
>> Srini
>>
>>
>> Amila Suriarachchi wrote:
>>>
>>> I removed this check please have a look at with a nightly build.
>>>
>>> thanks,
>>> Amila.
>>>
>>> On Thu, Oct 29, 2009 at 6:47 PM, srini.maran
>>> wrote:
>>>
Hi Amila.
Thanks for your response.
I don't get it "Can you check this by using a response get without
rampart? ". Do you mean to say run
the client without Rampart enabled? or you are talking different.
My client and server code is working fine without Rampart. It's
failing
when i enable Rampart. Basically,
it's failing in the client code when stub generates SOAP header with
auth
info(using policy file). It could be same issue in
server side too.
Below is my client code:
HubServiceStub stub = new
HubServiceStub("http://localhost:8180/";);
ServiceClient client = stub._getServiceClient();
Options options = client.getOptions();
options.setProperty(RampartMessageData.KEY_RAMPART_POLICY,
loadPolicy("plain-policy-client.xml"));
options.setUserName("libuser");
options.setPassword("books");
client.engageModule("rampart");
Channel2 chl1 = new Channel2();
// popultes the inpuit object
chl1.setAdmin("")
.
MessageE resp = stub.hubFeed(chl1); --> throws exception.
I am getting the exception when i invoke the service hubFeed.
I am able to successfully test the Rampart & IBM article WS-security
sample apps with no issue. It's a
simple service with no complex schema.
Please let me know if you need any further details.
I will really appreciate you on helping me to solve this issue.
Thanks
Srini
Amila Suriarachchi wrote:
>
> On Wed, Oct 28, 2009 at 1:31 AM, Andreas Veithen
> wrote:
>
>> Srini,
>>
>> Here is the explanation of this issue, as I see it:
>>
>> - When WS-Security is disabled, ADB streams the XML data directly to
>> the wire, using an XMLStreamWriter from Woodstox (which is indeed
>> wrapped to handle MTOM, but this is not important). No problem here
>> because the XMLStreamWriter from Woodstox conforms to StAX and ADB
in
>> Axis2 1.5 uses the XMLStreamWriter correctly (up to a minor issue
>> fixed in trunk).
>>
>> - When WS-Security is enabled, the XML can't be streamed to the wire
>> directly because Rampart needs to post-process the response. ADB
>> handles this by using an XMLStreamWriter implementation that will
>> build an Axiom (see AXIS2-4413). This is the MTOMAwareOMBuilder that
>> you see.
>>
>> The problem is that MTOMAwareOMBuilder is not a correct
implementation
>> of XMLStreamWriter. While the sequence of events produced by ADB is
>> correct (otherwise it would have failed with Woodstox),
>> MTOMAwareOMBuilder thinks that there is a collision between two
>> namespace bindings. The code in this class at least has two issues:
>>
>> - writeStartElement, writeAttribute, writeNamespace and
>> writeDefaultNamespace may all modify the namespace context (by
calling
>> getOMNamespace). This is incorrect: according to the specs, only
>> setPrefix and setDefaultNamespace modify the namespace context of
the
>> XMLStreamWriter.
>>
>
> ADB write element method looks like this.
>
> xmlWriter.writeStartElement(prefix, localPart, namespace);
> xmlWriter.writeNamespace(prefix, namespace);
> xmlWriter.setPrefix(prefix, namespace);
>
> does the spec specify any order?
>
>
>
>>
>> - The namespace context is not scoped. Normally, the namespace
>> bindings declared by setPrefix and setDefaultNamespace only remain
>> visible in the current element. This is not the case (see the usage
of
>> a simple HashMap in MTOMAwareOMBuilder and OMStreamNamespaceContext.
>>
>> In your case, the problem is probably caused by the second issue:
>> MTOMAwareOMBuilder probably believe
Re: [Axis2] with Rampart -- XMLStreamException "the prefix ==> Already exists for namespace
Hi Amila.
Where i can download the Axis2/Java nightly builds(V 1.5)? Please
advice.
We have PROD release scheduled in 2 weeks. I'd like to test this fix
ASAP.
Thanks
Srini
srini.maran wrote:
>
> Hi Amila.
>
> Thanks Amila..
>
> Please advice on where I can download Axis2/Java nightly builds(V 1.5),
> The
> Axis2 Website only points to a directory where only Axis2/C Nightly
> downloads are available.
>
> Thanks
> Srini
>
>
> Amila Suriarachchi wrote:
>>
>> I removed this check please have a look at with a nightly build.
>>
>> thanks,
>> Amila.
>>
>> On Thu, Oct 29, 2009 at 6:47 PM, srini.maran
>> wrote:
>>
>>>
>>> Hi Amila.
>>>
>>> Thanks for your response.
>>>
>>> I don't get it "Can you check this by using a response get without
>>> rampart? ". Do you mean to say run
>>> the client without Rampart enabled? or you are talking different.
>>>
>>> My client and server code is working fine without Rampart. It's
>>> failing
>>> when i enable Rampart. Basically,
>>> it's failing in the client code when stub generates SOAP header with
>>> auth
>>> info(using policy file). It could be same issue in
>>> server side too.
>>>
>>> Below is my client code:
>>>
>>> HubServiceStub stub = new
>>> HubServiceStub("http://localhost:8180/";);
>>> ServiceClient client = stub._getServiceClient();
>>>
>>> Options options = client.getOptions();
>>> options.setProperty(RampartMessageData.KEY_RAMPART_POLICY,
>>>loadPolicy("plain-policy-client.xml"));
>>> options.setUserName("libuser");
>>> options.setPassword("books");
>>> client.engageModule("rampart");
>>>
>>> Channel2 chl1 = new Channel2();
>>> // popultes the inpuit object
>>> chl1.setAdmin("")
>>>
>>> .
>>> MessageE resp = stub.hubFeed(chl1); --> throws exception.
>>>
>>>I am getting the exception when i invoke the service hubFeed.
>>>
>>>I am able to successfully test the Rampart & IBM article WS-security
>>> sample apps with no issue. It's a
>>>simple service with no complex schema.
>>>
>>>Please let me know if you need any further details.
>>>
>>>I will really appreciate you on helping me to solve this issue.
>>>
>>> Thanks
>>> Srini
>>>
>>>
>>>
>>> Amila Suriarachchi wrote:
>>> >
>>> > On Wed, Oct 28, 2009 at 1:31 AM, Andreas Veithen
>>> > wrote:
>>> >
>>> >> Srini,
>>> >>
>>> >> Here is the explanation of this issue, as I see it:
>>> >>
>>> >> - When WS-Security is disabled, ADB streams the XML data directly to
>>> >> the wire, using an XMLStreamWriter from Woodstox (which is indeed
>>> >> wrapped to handle MTOM, but this is not important). No problem here
>>> >> because the XMLStreamWriter from Woodstox conforms to StAX and ADB in
>>> >> Axis2 1.5 uses the XMLStreamWriter correctly (up to a minor issue
>>> >> fixed in trunk).
>>> >>
>>> >> - When WS-Security is enabled, the XML can't be streamed to the wire
>>> >> directly because Rampart needs to post-process the response. ADB
>>> >> handles this by using an XMLStreamWriter implementation that will
>>> >> build an Axiom (see AXIS2-4413). This is the MTOMAwareOMBuilder that
>>> >> you see.
>>> >>
>>> >> The problem is that MTOMAwareOMBuilder is not a correct
>>> implementation
>>> >> of XMLStreamWriter. While the sequence of events produced by ADB is
>>> >> correct (otherwise it would have failed with Woodstox),
>>> >> MTOMAwareOMBuilder thinks that there is a collision between two
>>> >> namespace bindings. The code in this class at least has two issues:
>>> >>
>>> >> - writeStartElement, writeAttribute, writeNamespace and
>>> >> writeDefaultNamespace may all modify the namespace context (by
>>> calling
>>> >> getOMNamespace). This is incorrect: according to the specs, only
>>> >> setPrefix and setDefaultNamespace modify the namespace context of the
>>> >> XMLStreamWriter.
>>> >>
>>> >
>>> > ADB write element method looks like this.
>>> >
>>> > xmlWriter.writeStartElement(prefix, localPart, namespace);
>>> > xmlWriter.writeNamespace(prefix, namespace);
>>> > xmlWriter.setPrefix(prefix, namespace);
>>> >
>>> > does the spec specify any order?
>>> >
>>> >
>>> >
>>> >>
>>> >> - The namespace context is not scoped. Normally, the namespace
>>> >> bindings declared by setPrefix and setDefaultNamespace only remain
>>> >> visible in the current element. This is not the case (see the usage
>>> of
>>> >> a simple HashMap in MTOMAwareOMBuilder and OMStreamNamespaceContext.
>>> >>
>>> >> In your case, the problem is probably caused by the second issue:
>>> >> MTOMAwareOMBuilder probably believes that there is a collision
>>> between
>>> >> a newly declared namespace binding and an existing one that actually
>>> >> should be out of scope.
>>> >>
>>> >
>>> > can you check this by using a response get without rampart? if so we
>>> can
>>> > remove this check.
>>> >
>>> > thanks,
>>> > Amila.
>>> >
>>> >>
>>> >> Regards,
>>> >>
>>> >> Andreas
>>> >>
>>> >> On Tue, Oc
Re: [Axis2] with Rampart -- XMLStreamException "the prefix ==> Already exists for namespace
Hi Amila.
Where i can download the Axis2/Java nightly builds(V 1.5)? Please
advice.
We have PROD release scheduled in 2 weeks. I'd like to test this fix
ASAP.
Thanks
Srini
srini.maran wrote:
>
> Hi Amila.
>
> Thanks Amila..
>
> Please advice on where I can download Axis2/Java nightly builds(V 1.5),
> The
> Axis2 Website only points to a directory where only Axis2/C Nightly
> downloads are available.
>
> Thanks
> Srini
>
>
> Amila Suriarachchi wrote:
>>
>> I removed this check please have a look at with a nightly build.
>>
>> thanks,
>> Amila.
>>
>> On Thu, Oct 29, 2009 at 6:47 PM, srini.maran
>> wrote:
>>
>>>
>>> Hi Amila.
>>>
>>> Thanks for your response.
>>>
>>> I don't get it "Can you check this by using a response get without
>>> rampart? ". Do you mean to say run
>>> the client without Rampart enabled? or you are talking different.
>>>
>>> My client and server code is working fine without Rampart. It's
>>> failing
>>> when i enable Rampart. Basically,
>>> it's failing in the client code when stub generates SOAP header with
>>> auth
>>> info(using policy file). It could be same issue in
>>> server side too.
>>>
>>> Below is my client code:
>>>
>>> HubServiceStub stub = new
>>> HubServiceStub("http://localhost:8180/";);
>>> ServiceClient client = stub._getServiceClient();
>>>
>>> Options options = client.getOptions();
>>> options.setProperty(RampartMessageData.KEY_RAMPART_POLICY,
>>>loadPolicy("plain-policy-client.xml"));
>>> options.setUserName("libuser");
>>> options.setPassword("books");
>>> client.engageModule("rampart");
>>>
>>> Channel2 chl1 = new Channel2();
>>> // popultes the inpuit object
>>> chl1.setAdmin("")
>>>
>>> .
>>> MessageE resp = stub.hubFeed(chl1); --> throws exception.
>>>
>>>I am getting the exception when i invoke the service hubFeed.
>>>
>>>I am able to successfully test the Rampart & IBM article WS-security
>>> sample apps with no issue. It's a
>>>simple service with no complex schema.
>>>
>>>Please let me know if you need any further details.
>>>
>>>I will really appreciate you on helping me to solve this issue.
>>>
>>> Thanks
>>> Srini
>>>
>>>
>>>
>>> Amila Suriarachchi wrote:
>>> >
>>> > On Wed, Oct 28, 2009 at 1:31 AM, Andreas Veithen
>>> > wrote:
>>> >
>>> >> Srini,
>>> >>
>>> >> Here is the explanation of this issue, as I see it:
>>> >>
>>> >> - When WS-Security is disabled, ADB streams the XML data directly to
>>> >> the wire, using an XMLStreamWriter from Woodstox (which is indeed
>>> >> wrapped to handle MTOM, but this is not important). No problem here
>>> >> because the XMLStreamWriter from Woodstox conforms to StAX and ADB in
>>> >> Axis2 1.5 uses the XMLStreamWriter correctly (up to a minor issue
>>> >> fixed in trunk).
>>> >>
>>> >> - When WS-Security is enabled, the XML can't be streamed to the wire
>>> >> directly because Rampart needs to post-process the response. ADB
>>> >> handles this by using an XMLStreamWriter implementation that will
>>> >> build an Axiom (see AXIS2-4413). This is the MTOMAwareOMBuilder that
>>> >> you see.
>>> >>
>>> >> The problem is that MTOMAwareOMBuilder is not a correct
>>> implementation
>>> >> of XMLStreamWriter. While the sequence of events produced by ADB is
>>> >> correct (otherwise it would have failed with Woodstox),
>>> >> MTOMAwareOMBuilder thinks that there is a collision between two
>>> >> namespace bindings. The code in this class at least has two issues:
>>> >>
>>> >> - writeStartElement, writeAttribute, writeNamespace and
>>> >> writeDefaultNamespace may all modify the namespace context (by
>>> calling
>>> >> getOMNamespace). This is incorrect: according to the specs, only
>>> >> setPrefix and setDefaultNamespace modify the namespace context of the
>>> >> XMLStreamWriter.
>>> >>
>>> >
>>> > ADB write element method looks like this.
>>> >
>>> > xmlWriter.writeStartElement(prefix, localPart, namespace);
>>> > xmlWriter.writeNamespace(prefix, namespace);
>>> > xmlWriter.setPrefix(prefix, namespace);
>>> >
>>> > does the spec specify any order?
>>> >
>>> >
>>> >
>>> >>
>>> >> - The namespace context is not scoped. Normally, the namespace
>>> >> bindings declared by setPrefix and setDefaultNamespace only remain
>>> >> visible in the current element. This is not the case (see the usage
>>> of
>>> >> a simple HashMap in MTOMAwareOMBuilder and OMStreamNamespaceContext.
>>> >>
>>> >> In your case, the problem is probably caused by the second issue:
>>> >> MTOMAwareOMBuilder probably believes that there is a collision
>>> between
>>> >> a newly declared namespace binding and an existing one that actually
>>> >> should be out of scope.
>>> >>
>>> >
>>> > can you check this by using a response get without rampart? if so we
>>> can
>>> > remove this check.
>>> >
>>> > thanks,
>>> > Amila.
>>> >
>>> >>
>>> >> Regards,
>>> >>
>>> >> Andreas
>>> >>
>>> >> On Tue, Oc
Re: [Axis2] with Rampart -- XMLStreamException "the prefix ==> Already exists for namespace
Hi Amila.
Thanks Amila..
Please advice on where I can download Axis2/Java nightly builds(V 1.5),
The
Axis2 Website only points to a directory where only Axis2/C Nightly
downloads are available.
Thanks
Srini
Amila Suriarachchi wrote:
>
> I removed this check please have a look at with a nightly build.
>
> thanks,
> Amila.
>
> On Thu, Oct 29, 2009 at 6:47 PM, srini.maran wrote:
>
>>
>> Hi Amila.
>>
>> Thanks for your response.
>>
>> I don't get it "Can you check this by using a response get without
>> rampart? ". Do you mean to say run
>> the client without Rampart enabled? or you are talking different.
>>
>> My client and server code is working fine without Rampart. It's failing
>> when i enable Rampart. Basically,
>> it's failing in the client code when stub generates SOAP header with
>> auth
>> info(using policy file). It could be same issue in
>> server side too.
>>
>> Below is my client code:
>>
>> HubServiceStub stub = new
>> HubServiceStub("http://localhost:8180/";);
>> ServiceClient client = stub._getServiceClient();
>>
>> Options options = client.getOptions();
>> options.setProperty(RampartMessageData.KEY_RAMPART_POLICY,
>>loadPolicy("plain-policy-client.xml"));
>> options.setUserName("libuser");
>> options.setPassword("books");
>> client.engageModule("rampart");
>>
>> Channel2 chl1 = new Channel2();
>> // popultes the inpuit object
>> chl1.setAdmin("")
>>
>> .
>> MessageE resp = stub.hubFeed(chl1); --> throws exception.
>>
>>I am getting the exception when i invoke the service hubFeed.
>>
>>I am able to successfully test the Rampart & IBM article WS-security
>> sample apps with no issue. It's a
>>simple service with no complex schema.
>>
>>Please let me know if you need any further details.
>>
>>I will really appreciate you on helping me to solve this issue.
>>
>> Thanks
>> Srini
>>
>>
>>
>> Amila Suriarachchi wrote:
>> >
>> > On Wed, Oct 28, 2009 at 1:31 AM, Andreas Veithen
>> > wrote:
>> >
>> >> Srini,
>> >>
>> >> Here is the explanation of this issue, as I see it:
>> >>
>> >> - When WS-Security is disabled, ADB streams the XML data directly to
>> >> the wire, using an XMLStreamWriter from Woodstox (which is indeed
>> >> wrapped to handle MTOM, but this is not important). No problem here
>> >> because the XMLStreamWriter from Woodstox conforms to StAX and ADB in
>> >> Axis2 1.5 uses the XMLStreamWriter correctly (up to a minor issue
>> >> fixed in trunk).
>> >>
>> >> - When WS-Security is enabled, the XML can't be streamed to the wire
>> >> directly because Rampart needs to post-process the response. ADB
>> >> handles this by using an XMLStreamWriter implementation that will
>> >> build an Axiom (see AXIS2-4413). This is the MTOMAwareOMBuilder that
>> >> you see.
>> >>
>> >> The problem is that MTOMAwareOMBuilder is not a correct implementation
>> >> of XMLStreamWriter. While the sequence of events produced by ADB is
>> >> correct (otherwise it would have failed with Woodstox),
>> >> MTOMAwareOMBuilder thinks that there is a collision between two
>> >> namespace bindings. The code in this class at least has two issues:
>> >>
>> >> - writeStartElement, writeAttribute, writeNamespace and
>> >> writeDefaultNamespace may all modify the namespace context (by calling
>> >> getOMNamespace). This is incorrect: according to the specs, only
>> >> setPrefix and setDefaultNamespace modify the namespace context of the
>> >> XMLStreamWriter.
>> >>
>> >
>> > ADB write element method looks like this.
>> >
>> > xmlWriter.writeStartElement(prefix, localPart, namespace);
>> > xmlWriter.writeNamespace(prefix, namespace);
>> > xmlWriter.setPrefix(prefix, namespace);
>> >
>> > does the spec specify any order?
>> >
>> >
>> >
>> >>
>> >> - The namespace context is not scoped. Normally, the namespace
>> >> bindings declared by setPrefix and setDefaultNamespace only remain
>> >> visible in the current element. This is not the case (see the usage of
>> >> a simple HashMap in MTOMAwareOMBuilder and OMStreamNamespaceContext.
>> >>
>> >> In your case, the problem is probably caused by the second issue:
>> >> MTOMAwareOMBuilder probably believes that there is a collision between
>> >> a newly declared namespace binding and an existing one that actually
>> >> should be out of scope.
>> >>
>> >
>> > can you check this by using a response get without rampart? if so we
>> can
>> > remove this check.
>> >
>> > thanks,
>> > Amila.
>> >
>> >>
>> >> Regards,
>> >>
>> >> Andreas
>> >>
>> >> On Tue, Oct 27, 2009 at 19:53, srini.maran
>> wrote:
>> >> >
>> >> > Hi Axis User.
>> >> >
>> >> >I am getting the below error in the client code when I
>> try
>> >> to
>> >> > invoke the service with WS-Security Rampart. I am using Asix2-1.5
>> and
>> >> > Rampart-1.4
>> >> >
>> >> > XMLStreamException "the prefix ==> Already exists for
>> >> namespace
>> >> > in “urn:com1” "
>>
Re: [Axis2] with Rampart -- XMLStreamException "the prefix ==> Already exists for namespace
I removed this check please have a look at with a nightly build.
thanks,
Amila.
On Thu, Oct 29, 2009 at 6:47 PM, srini.maran wrote:
>
> Hi Amila.
>
> Thanks for your response.
>
> I don't get it "Can you check this by using a response get without
> rampart? ". Do you mean to say run
> the client without Rampart enabled? or you are talking different.
>
> My client and server code is working fine without Rampart. It's failing
> when i enable Rampart. Basically,
> it's failing in the client code when stub generates SOAP header with auth
> info(using policy file). It could be same issue in
> server side too.
>
> Below is my client code:
>
> HubServiceStub stub = new
> HubServiceStub("http://localhost:8180/";);
> ServiceClient client = stub._getServiceClient();
>
> Options options = client.getOptions();
> options.setProperty(RampartMessageData.KEY_RAMPART_POLICY,
>loadPolicy("plain-policy-client.xml"));
> options.setUserName("libuser");
> options.setPassword("books");
> client.engageModule("rampart");
>
> Channel2 chl1 = new Channel2();
> // popultes the inpuit object
> chl1.setAdmin("")
>
> .
> MessageE resp = stub.hubFeed(chl1); --> throws exception.
>
>I am getting the exception when i invoke the service hubFeed.
>
>I am able to successfully test the Rampart & IBM article WS-security
> sample apps with no issue. It's a
>simple service with no complex schema.
>
>Please let me know if you need any further details.
>
>I will really appreciate you on helping me to solve this issue.
>
> Thanks
> Srini
>
>
>
> Amila Suriarachchi wrote:
> >
> > On Wed, Oct 28, 2009 at 1:31 AM, Andreas Veithen
> > wrote:
> >
> >> Srini,
> >>
> >> Here is the explanation of this issue, as I see it:
> >>
> >> - When WS-Security is disabled, ADB streams the XML data directly to
> >> the wire, using an XMLStreamWriter from Woodstox (which is indeed
> >> wrapped to handle MTOM, but this is not important). No problem here
> >> because the XMLStreamWriter from Woodstox conforms to StAX and ADB in
> >> Axis2 1.5 uses the XMLStreamWriter correctly (up to a minor issue
> >> fixed in trunk).
> >>
> >> - When WS-Security is enabled, the XML can't be streamed to the wire
> >> directly because Rampart needs to post-process the response. ADB
> >> handles this by using an XMLStreamWriter implementation that will
> >> build an Axiom (see AXIS2-4413). This is the MTOMAwareOMBuilder that
> >> you see.
> >>
> >> The problem is that MTOMAwareOMBuilder is not a correct implementation
> >> of XMLStreamWriter. While the sequence of events produced by ADB is
> >> correct (otherwise it would have failed with Woodstox),
> >> MTOMAwareOMBuilder thinks that there is a collision between two
> >> namespace bindings. The code in this class at least has two issues:
> >>
> >> - writeStartElement, writeAttribute, writeNamespace and
> >> writeDefaultNamespace may all modify the namespace context (by calling
> >> getOMNamespace). This is incorrect: according to the specs, only
> >> setPrefix and setDefaultNamespace modify the namespace context of the
> >> XMLStreamWriter.
> >>
> >
> > ADB write element method looks like this.
> >
> > xmlWriter.writeStartElement(prefix, localPart, namespace);
> > xmlWriter.writeNamespace(prefix, namespace);
> > xmlWriter.setPrefix(prefix, namespace);
> >
> > does the spec specify any order?
> >
> >
> >
> >>
> >> - The namespace context is not scoped. Normally, the namespace
> >> bindings declared by setPrefix and setDefaultNamespace only remain
> >> visible in the current element. This is not the case (see the usage of
> >> a simple HashMap in MTOMAwareOMBuilder and OMStreamNamespaceContext.
> >>
> >> In your case, the problem is probably caused by the second issue:
> >> MTOMAwareOMBuilder probably believes that there is a collision between
> >> a newly declared namespace binding and an existing one that actually
> >> should be out of scope.
> >>
> >
> > can you check this by using a response get without rampart? if so we can
> > remove this check.
> >
> > thanks,
> > Amila.
> >
> >>
> >> Regards,
> >>
> >> Andreas
> >>
> >> On Tue, Oct 27, 2009 at 19:53, srini.maran
> wrote:
> >> >
> >> > Hi Axis User.
> >> >
> >> >I am getting the below error in the client code when I try
> >> to
> >> > invoke the service with WS-Security Rampart. I am using Asix2-1.5 and
> >> > Rampart-1.4
> >> >
> >> > XMLStreamException "the prefix ==> Already exists for
> >> namespace
> >> > in “urn:com1” "
> >> > when WS-Security Rampart is engaged for Axis 2 web-services
> >> >
> >> > Attached are the error log file (stacktrace) & client code.
> I
> >> am
> >> > using XML import in the schema. I am able to successfully test the
> >> Rampart
> >> > policy samples without any issue.
> >> >
> >> > I am getting error when I add rampart in our existing
> service
> >> > which has com
Re: [Axis2] with Rampart -- XMLStreamException "the prefix ==> Already exists for namespace
On Thu, Oct 29, 2009 at 11:33, Amila Suriarachchi wrote: > > > On Wed, Oct 28, 2009 at 1:31 AM, Andreas Veithen > wrote: >> >> Srini, >> >> Here is the explanation of this issue, as I see it: >> >> - When WS-Security is disabled, ADB streams the XML data directly to >> the wire, using an XMLStreamWriter from Woodstox (which is indeed >> wrapped to handle MTOM, but this is not important). No problem here >> because the XMLStreamWriter from Woodstox conforms to StAX and ADB in >> Axis2 1.5 uses the XMLStreamWriter correctly (up to a minor issue >> fixed in trunk). >> >> - When WS-Security is enabled, the XML can't be streamed to the wire >> directly because Rampart needs to post-process the response. ADB >> handles this by using an XMLStreamWriter implementation that will >> build an Axiom (see AXIS2-4413). This is the MTOMAwareOMBuilder that >> you see. >> >> The problem is that MTOMAwareOMBuilder is not a correct implementation >> of XMLStreamWriter. While the sequence of events produced by ADB is >> correct (otherwise it would have failed with Woodstox), >> MTOMAwareOMBuilder thinks that there is a collision between two >> namespace bindings. The code in this class at least has two issues: >> >> - writeStartElement, writeAttribute, writeNamespace and >> writeDefaultNamespace may all modify the namespace context (by calling >> getOMNamespace). This is incorrect: according to the specs, only >> setPrefix and setDefaultNamespace modify the namespace context of the >> XMLStreamWriter. > > ADB write element method looks like this. > > xmlWriter.writeStartElement(prefix, localPart, namespace); > xmlWriter.writeNamespace(prefix, namespace); > xmlWriter.setPrefix(prefix, namespace); > > does the spec specify any order? > Except for the obvious constraint that writeNamespace must follow writeStartElement, the specs don't specify the order. However, they specify that the scope of the namespace binding declared by setPrefix is the current element. Therefore, if one wants to make sure that the namespace context of the XMLStreamWriter accurately reflects the namespace context in the document being written, setPrefix must be called after writeStartElement. Since ADB makes use of the namespace context of the writer to choose namespace prefixes, the order is correct and must be like that. For more details, see [1]. [1] http://people.apache.org/~veithen/axiom/devguide/ch02.html > >> >> - The namespace context is not scoped. Normally, the namespace >> bindings declared by setPrefix and setDefaultNamespace only remain >> visible in the current element. This is not the case (see the usage of >> a simple HashMap in MTOMAwareOMBuilder and OMStreamNamespaceContext. >> >> In your case, the problem is probably caused by the second issue: >> MTOMAwareOMBuilder probably believes that there is a collision between >> a newly declared namespace binding and an existing one that actually >> should be out of scope. > > can you check this by using a response get without rampart? if so we can > remove this check. > > thanks, > Amila. >> >> Regards, >> >> Andreas >> >> On Tue, Oct 27, 2009 at 19:53, srini.maran wrote: >> > >> > Hi Axis User. >> > >> > I am getting the below error in the client code when I try to >> > invoke the service with WS-Security Rampart. I am using Asix2-1.5 and >> > Rampart-1.4 >> > >> > XMLStreamException "the prefix ==> Already exists for >> > namespace >> > in “urn:com1” " >> > when WS-Security Rampart is engaged for Axis 2 web-services >> > >> > Attached are the error log file (stacktrace) & client code. I >> > am >> > using XML import in the schema. I am able to successfully test the >> > Rampart >> > policy samples without any issue. >> > >> > I am getting error when I add rampart in our existing service >> > which has complex schema. Has this error occurred due to xml import? >> > >> > Below is my XSD hierarchy >> > >> > service.wsdl -- >> > >> > >> > > > schemaLocation="../schema/hub_channel.xsd" /> - in >> > > > schemaLocation="../schema/hub_message.xsd" /> - out >> > >> > >> > >> > hub_channel.xsd(urn:chl) imports the below scheams. >> > > > schemaLocation="hub_common.xsd" /> >> > > > schemaLocation="hub_user.xsd" /> >> > >> > hub_message.xsd(urn:msg) import >> > > > schemaLocation="hub_common.xsd" /> >> > >> > Can you please help on this issue? I will really appreciate >> > you. >> > I have been trying for last 1 week to resolve it. I couldn’t resolve it. >> > >> > I searched in Axis User, people encountered the same. I don't >> > think it's resolved. >> > Here is the link: >> > http://www.mail-archive.com/axis-user@ws.apache.org/msg40661.html >> > In the forum, one of the user Richard mentioned Rampart devs >> > would like to acknowledge the >>
Re: [Axis2] with Rampart -- XMLStreamException "the prefix ==> Already exists for namespace
Hi Amila.
Thanks for your response.
I don't get it "Can you check this by using a response get without
rampart? ". Do you mean to say run
the client without Rampart enabled? or you are talking different.
My client and server code is working fine without Rampart. It's failing
when i enable Rampart. Basically,
it's failing in the client code when stub generates SOAP header with auth
info(using policy file). It could be same issue in
server side too.
Below is my client code:
HubServiceStub stub = new
HubServiceStub("http://localhost:8180/";);
ServiceClient client = stub._getServiceClient();
Options options = client.getOptions();
options.setProperty(RampartMessageData.KEY_RAMPART_POLICY,
loadPolicy("plain-policy-client.xml"));
options.setUserName("libuser");
options.setPassword("books");
client.engageModule("rampart");
Channel2 chl1 = new Channel2();
// popultes the inpuit object
chl1.setAdmin("")
.
MessageE resp = stub.hubFeed(chl1); --> throws exception.
I am getting the exception when i invoke the service hubFeed.
I am able to successfully test the Rampart & IBM article WS-security
sample apps with no issue. It's a
simple service with no complex schema.
Please let me know if you need any further details.
I will really appreciate you on helping me to solve this issue.
Thanks
Srini
Amila Suriarachchi wrote:
>
> On Wed, Oct 28, 2009 at 1:31 AM, Andreas Veithen
> wrote:
>
>> Srini,
>>
>> Here is the explanation of this issue, as I see it:
>>
>> - When WS-Security is disabled, ADB streams the XML data directly to
>> the wire, using an XMLStreamWriter from Woodstox (which is indeed
>> wrapped to handle MTOM, but this is not important). No problem here
>> because the XMLStreamWriter from Woodstox conforms to StAX and ADB in
>> Axis2 1.5 uses the XMLStreamWriter correctly (up to a minor issue
>> fixed in trunk).
>>
>> - When WS-Security is enabled, the XML can't be streamed to the wire
>> directly because Rampart needs to post-process the response. ADB
>> handles this by using an XMLStreamWriter implementation that will
>> build an Axiom (see AXIS2-4413). This is the MTOMAwareOMBuilder that
>> you see.
>>
>> The problem is that MTOMAwareOMBuilder is not a correct implementation
>> of XMLStreamWriter. While the sequence of events produced by ADB is
>> correct (otherwise it would have failed with Woodstox),
>> MTOMAwareOMBuilder thinks that there is a collision between two
>> namespace bindings. The code in this class at least has two issues:
>>
>> - writeStartElement, writeAttribute, writeNamespace and
>> writeDefaultNamespace may all modify the namespace context (by calling
>> getOMNamespace). This is incorrect: according to the specs, only
>> setPrefix and setDefaultNamespace modify the namespace context of the
>> XMLStreamWriter.
>>
>
> ADB write element method looks like this.
>
> xmlWriter.writeStartElement(prefix, localPart, namespace);
> xmlWriter.writeNamespace(prefix, namespace);
> xmlWriter.setPrefix(prefix, namespace);
>
> does the spec specify any order?
>
>
>
>>
>> - The namespace context is not scoped. Normally, the namespace
>> bindings declared by setPrefix and setDefaultNamespace only remain
>> visible in the current element. This is not the case (see the usage of
>> a simple HashMap in MTOMAwareOMBuilder and OMStreamNamespaceContext.
>>
>> In your case, the problem is probably caused by the second issue:
>> MTOMAwareOMBuilder probably believes that there is a collision between
>> a newly declared namespace binding and an existing one that actually
>> should be out of scope.
>>
>
> can you check this by using a response get without rampart? if so we can
> remove this check.
>
> thanks,
> Amila.
>
>>
>> Regards,
>>
>> Andreas
>>
>> On Tue, Oct 27, 2009 at 19:53, srini.maran wrote:
>> >
>> > Hi Axis User.
>> >
>> >I am getting the below error in the client code when I try
>> to
>> > invoke the service with WS-Security Rampart. I am using Asix2-1.5 and
>> > Rampart-1.4
>> >
>> > XMLStreamException "the prefix ==> Already exists for
>> namespace
>> > in “urn:com1” "
>> > when WS-Security Rampart is engaged for Axis 2 web-services
>> >
>> > Attached are the error log file (stacktrace) & client code. I
>> am
>> > using XML import in the schema. I am able to successfully test the
>> Rampart
>> > policy samples without any issue.
>> >
>> > I am getting error when I add rampart in our existing service
>> > which has complex schema. Has this error occurred due to xml import?
>> >
>> > Below is my XSD hierarchy
>> >
>> > service.wsdl --
>> >
>> >
>> > > > schemaLocation="../schema/hub_channel.xsd" /> - in
>> > > > schemaLocation="../schema/hub_message.xsd" /> - out
>> >
>> >
>> >
>> >
Re: [Axis2] with Rampart -- XMLStreamException "the prefix ==> Already exists for namespace
On Wed, Oct 28, 2009 at 1:31 AM, Andreas Veithen wrote: > Srini, > > Here is the explanation of this issue, as I see it: > > - When WS-Security is disabled, ADB streams the XML data directly to > the wire, using an XMLStreamWriter from Woodstox (which is indeed > wrapped to handle MTOM, but this is not important). No problem here > because the XMLStreamWriter from Woodstox conforms to StAX and ADB in > Axis2 1.5 uses the XMLStreamWriter correctly (up to a minor issue > fixed in trunk). > > - When WS-Security is enabled, the XML can't be streamed to the wire > directly because Rampart needs to post-process the response. ADB > handles this by using an XMLStreamWriter implementation that will > build an Axiom (see AXIS2-4413). This is the MTOMAwareOMBuilder that > you see. > > The problem is that MTOMAwareOMBuilder is not a correct implementation > of XMLStreamWriter. While the sequence of events produced by ADB is > correct (otherwise it would have failed with Woodstox), > MTOMAwareOMBuilder thinks that there is a collision between two > namespace bindings. The code in this class at least has two issues: > > - writeStartElement, writeAttribute, writeNamespace and > writeDefaultNamespace may all modify the namespace context (by calling > getOMNamespace). This is incorrect: according to the specs, only > setPrefix and setDefaultNamespace modify the namespace context of the > XMLStreamWriter. > ADB write element method looks like this. xmlWriter.writeStartElement(prefix, localPart, namespace); xmlWriter.writeNamespace(prefix, namespace); xmlWriter.setPrefix(prefix, namespace); does the spec specify any order? > > - The namespace context is not scoped. Normally, the namespace > bindings declared by setPrefix and setDefaultNamespace only remain > visible in the current element. This is not the case (see the usage of > a simple HashMap in MTOMAwareOMBuilder and OMStreamNamespaceContext. > > In your case, the problem is probably caused by the second issue: > MTOMAwareOMBuilder probably believes that there is a collision between > a newly declared namespace binding and an existing one that actually > should be out of scope. > can you check this by using a response get without rampart? if so we can remove this check. thanks, Amila. > > Regards, > > Andreas > > On Tue, Oct 27, 2009 at 19:53, srini.maran wrote: > > > > Hi Axis User. > > > >I am getting the below error in the client code when I try to > > invoke the service with WS-Security Rampart. I am using Asix2-1.5 and > > Rampart-1.4 > > > > XMLStreamException "the prefix ==> Already exists for namespace > > in “urn:com1” " > > when WS-Security Rampart is engaged for Axis 2 web-services > > > > Attached are the error log file (stacktrace) & client code. I > am > > using XML import in the schema. I am able to successfully test the > Rampart > > policy samples without any issue. > > > > I am getting error when I add rampart in our existing service > > which has complex schema. Has this error occurred due to xml import? > > > > Below is my XSD hierarchy > > > > service.wsdl -- > > > > > >> schemaLocation="../schema/hub_channel.xsd" /> - in > >> schemaLocation="../schema/hub_message.xsd" /> - out > > > > > > > >hub_channel.xsd(urn:chl) imports the below scheams. > > > schemaLocation="hub_common.xsd" /> > > > schemaLocation="hub_user.xsd" /> > > > >hub_message.xsd(urn:msg) import > > > schemaLocation="hub_common.xsd" /> > > > >Can you please help on this issue? I will really appreciate > you. > > I have been trying for last 1 week to resolve it. I couldn’t resolve it. > > > >I searched in Axis User, people encountered the same. I don't > > think it's resolved. > >Here is the link: > > http://www.mail-archive.com/axis-user@ws.apache.org/msg40661.html > >In the forum, one of the user Richard mentioned Rampart devs > > would like to acknowledge the > >problem and maybe even fix it > > > >One user debugged the issue and added the below comments in > the > > forum > > > >"I debugged the code and observed that, in the serialize > method > > of the XML node POJO > > (generated by WSDL2JAVA), the "MTOMAwareXMLStreamWriter > > xmlWriter" parameter gets an > > instance of MTOMAwareOMBuilder if WS-Security is enabled. > > Whereas, without WS-Security it gets an instance of > > > > org.apache.axis2.databinding.utils.writer.MTOMAwareXMLSerializer which > uses > > MTOMXMLStreamWriter which in turn uses > > com.ctc.wstx.sw.SimpleNsStreamWriter to > > serialize the response. > > I also tried using AXIS 1.4 without any success. Any idea how > > can this problem can be solved? > > Is there a
Re: [Axis2] with Rampart -- XMLStreamException "the prefix ==> Already exists for namespace
Hi Andreas. Thanks for very quick response. I will really appreciate you. Do we have fix for this issue? if not, Can we create a bug in the Axis JIRA? or Is there any workaround solution? WS-security is working fine in Sample application(Rampart & IBM article sample). I am able to test successfully without any issue. It's failing in our existing service that has complex schema with import. I want to mention one more thing i am using elementFormDefault="unqualified" and attributeFormDefault = "unqualified". Is that matter? Is this issue in Axis-Axiom or Rampart security component? Thanks Srini Andreas Veithen-2 wrote: > > Srini, > > Here is the explanation of this issue, as I see it: > > - When WS-Security is disabled, ADB streams the XML data directly to > the wire, using an XMLStreamWriter from Woodstox (which is indeed > wrapped to handle MTOM, but this is not important). No problem here > because the XMLStreamWriter from Woodstox conforms to StAX and ADB in > Axis2 1.5 uses the XMLStreamWriter correctly (up to a minor issue > fixed in trunk). > > - When WS-Security is enabled, the XML can't be streamed to the wire > directly because Rampart needs to post-process the response. ADB > handles this by using an XMLStreamWriter implementation that will > build an Axiom (see AXIS2-4413). This is the MTOMAwareOMBuilder that > you see. > > The problem is that MTOMAwareOMBuilder is not a correct implementation > of XMLStreamWriter. While the sequence of events produced by ADB is > correct (otherwise it would have failed with Woodstox), > MTOMAwareOMBuilder thinks that there is a collision between two > namespace bindings. The code in this class at least has two issues: > > - writeStartElement, writeAttribute, writeNamespace and > writeDefaultNamespace may all modify the namespace context (by calling > getOMNamespace). This is incorrect: according to the specs, only > setPrefix and setDefaultNamespace modify the namespace context of the > XMLStreamWriter. > > - The namespace context is not scoped. Normally, the namespace > bindings declared by setPrefix and setDefaultNamespace only remain > visible in the current element. This is not the case (see the usage of > a simple HashMap in MTOMAwareOMBuilder and OMStreamNamespaceContext. > > In your case, the problem is probably caused by the second issue: > MTOMAwareOMBuilder probably believes that there is a collision between > a newly declared namespace binding and an existing one that actually > should be out of scope. > > Regards, > > Andreas > > On Tue, Oct 27, 2009 at 19:53, srini.maran wrote: >> >> Hi Axis User. >> >> I am getting the below error in the client code when I try to >> invoke the service with WS-Security Rampart. I am using Asix2-1.5 and >> Rampart-1.4 >> >> XMLStreamException "the prefix ==> Already exists for namespace >> in “urn:com1” " >> when WS-Security Rampart is engaged for Axis 2 web-services >> >> Attached are the error log file (stacktrace) & client code. I >> am >> using XML import in the schema. I am able to successfully test the >> Rampart >> policy samples without any issue. >> >> I am getting error when I add rampart in our existing service >> which has complex schema. Has this error occurred due to xml import? >> >> Below is my XSD hierarchy >> >> service.wsdl -- >> >> >> > schemaLocation="../schema/hub_channel.xsd" /> - in >> > schemaLocation="../schema/hub_message.xsd" /> - out >> >> >> >> hub_channel.xsd(urn:chl) imports the below scheams. >> > schemaLocation="hub_common.xsd" /> >> > schemaLocation="hub_user.xsd" /> >> >> hub_message.xsd(urn:msg) import >> > schemaLocation="hub_common.xsd" /> >> >> Can you please help on this issue? I will really appreciate >> you. >> I have been trying for last 1 week to resolve it. I couldn’t resolve it. >> >> I searched in Axis User, people encountered the same. I don't >> think it's resolved. >> Here is the link: >> http://www.mail-archive.com/axis-user@ws.apache.org/msg40661.html >> In the forum, one of the user Richard mentioned Rampart devs >> would like to acknowledge the >> problem and maybe even fix it >> >> One user debugged the issue and added the below comments in >> the >> forum >> >> "I debugged the code and observed that, in the serialize >> method >> of the XML node POJO >> (generated by WSDL2JAVA), the "MTOMAwareXMLStreamWriter >> xmlWriter" parameter gets an >> instance of MTOMAwareOMBuilder if WS-Security is enabled. >> Whereas, without WS-Security it gets an instance of >> >> org.apache.axis2.databinding.utils.writer.MTOMAwareXMLSerializer which >> uses >> MTOMXMLStreamWriter which in turn uses >> com.ctc.wstx.sw.SimpleNsStreamWriter to >>
Re: [Axis2] with Rampart -- XMLStreamException "the prefix ==> Already exists for namespace
Srini, Here is the explanation of this issue, as I see it: - When WS-Security is disabled, ADB streams the XML data directly to the wire, using an XMLStreamWriter from Woodstox (which is indeed wrapped to handle MTOM, but this is not important). No problem here because the XMLStreamWriter from Woodstox conforms to StAX and ADB in Axis2 1.5 uses the XMLStreamWriter correctly (up to a minor issue fixed in trunk). - When WS-Security is enabled, the XML can't be streamed to the wire directly because Rampart needs to post-process the response. ADB handles this by using an XMLStreamWriter implementation that will build an Axiom (see AXIS2-4413). This is the MTOMAwareOMBuilder that you see. The problem is that MTOMAwareOMBuilder is not a correct implementation of XMLStreamWriter. While the sequence of events produced by ADB is correct (otherwise it would have failed with Woodstox), MTOMAwareOMBuilder thinks that there is a collision between two namespace bindings. The code in this class at least has two issues: - writeStartElement, writeAttribute, writeNamespace and writeDefaultNamespace may all modify the namespace context (by calling getOMNamespace). This is incorrect: according to the specs, only setPrefix and setDefaultNamespace modify the namespace context of the XMLStreamWriter. - The namespace context is not scoped. Normally, the namespace bindings declared by setPrefix and setDefaultNamespace only remain visible in the current element. This is not the case (see the usage of a simple HashMap in MTOMAwareOMBuilder and OMStreamNamespaceContext. In your case, the problem is probably caused by the second issue: MTOMAwareOMBuilder probably believes that there is a collision between a newly declared namespace binding and an existing one that actually should be out of scope. Regards, Andreas On Tue, Oct 27, 2009 at 19:53, srini.maran wrote: > > Hi Axis User. > > I am getting the below error in the client code when I try to > invoke the service with WS-Security Rampart. I am using Asix2-1.5 and > Rampart-1.4 > > XMLStreamException "the prefix ==> Already exists for namespace > in “urn:com1” " > when WS-Security Rampart is engaged for Axis 2 web-services > > Attached are the error log file (stacktrace) & client code. I am > using XML import in the schema. I am able to successfully test the Rampart > policy samples without any issue. > > I am getting error when I add rampart in our existing service > which has complex schema. Has this error occurred due to xml import? > > Below is my XSD hierarchy > > service.wsdl -- > > > schemaLocation="../schema/hub_channel.xsd" /> - in > schemaLocation="../schema/hub_message.xsd" /> - out > > > > hub_channel.xsd(urn:chl) imports the below scheams. > schemaLocation="hub_common.xsd" /> > schemaLocation="hub_user.xsd" /> > > hub_message.xsd(urn:msg) import > schemaLocation="hub_common.xsd" /> > > Can you please help on this issue? I will really appreciate you. > I have been trying for last 1 week to resolve it. I couldn’t resolve it. > > I searched in Axis User, people encountered the same. I don't > think it's resolved. > Here is the link: > http://www.mail-archive.com/axis-user@ws.apache.org/msg40661.html > In the forum, one of the user Richard mentioned Rampart devs > would like to acknowledge the > problem and maybe even fix it > > One user debugged the issue and added the below comments in the > forum > > "I debugged the code and observed that, in the serialize method > of the XML node POJO > (generated by WSDL2JAVA), the "MTOMAwareXMLStreamWriter > xmlWriter" parameter gets an > instance of MTOMAwareOMBuilder if WS-Security is enabled. > Whereas, without WS-Security it gets an instance of > > org.apache.axis2.databinding.utils.writer.MTOMAwareXMLSerializer which uses > MTOMXMLStreamWriter which in turn uses > com.ctc.wstx.sw.SimpleNsStreamWriter to > serialize the response. > I also tried using AXIS 1.4 without any success. Any idea how > can this problem can be solved? > Is there a way to let Rampart know which serializer should be > used? Am I missing any > configuration details of Rampart? " > > Thanks > Srini Maran > > http://www.nabble.com/file/p26083056/Error1.rtf Error1.rtf > http://www.nabble.com/file/p26083056/Client.rtf Client.rtf > -- > View this message in context: > http://www.nabble.com/-Axis2--with-RampartXMLStreamException-%22the-prefix-%3D%3D%3E-Already-exists-for-namespace-tp26083056p26083056.html > Sent from the Axis - User mailing list archive at Nabble.com. > >
