On Wed, Oct 28, 2009 at 1:31 AM, Andreas Veithen
<andreas.veit...@gmail.com>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 <thiruma...@yahoo.com> 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 --
> >
> > <wsdl:types>
> > <xsd:import namespace="urn:chl"
> > schemaLocation="../schema/hub_channel.xsd" /> - in
> > <xsd:import namespace="urn:msg"
> > schemaLocation="../schema/hub_message.xsd" /> - out
> > </wsdl:types>
> >
> >
> > hub_channel.xsd(urn:chl) imports the below scheams.
> > <xsd:import namespace="urn:com1"
> > schemaLocation="hub_common.xsd" />
> > <xsd:import namespace="urn:usr"
> > schemaLocation="hub_user.xsd" />
> >
> > hub_message.xsd(urn:msg) import
> > <xsd:import namespace="urn:com1"
> > 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-Rampart----XMLStreamException-%22the-prefix-%3D%3D%3E-Already-exists-for-namespace-tp26083056p26083056.html
> > Sent from the Axis - User mailing list archive at Nabble.com.
> >
> >
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
