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 <[email protected]> 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/[email protected]/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.
>>
>>
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-Axis2--with-Rampart----XMLStreamException-%22the-prefix-%3D%3D%3E-Already-exists-for-namespace-tp26083056p26094414.html
Sent from the Axis - User mailing list archive at Nabble.com.

Reply via email to