Thanks Anthony (and others),
 
Your advice has helped us resolve the issue.
 
For reference (for any others that might encounter a similar issue to
this), in Axis2-1.1, we had to modify the
org.apache.axis2.handlers.addressing.AddressingOutHandler.java within
the addressing-1.1.mar used by Axis2.
 
The original code would only allow the name space to be set to the
final value (http://www.w3.org/2005/08/addressing), or the submission
value (http://schemas.xmlsoap.org/ws/2004/08/addressing). If the
client's AddressingConstants.WS_ADDRESSING_VERSION property was not
either one of these values, it would be ignored, and the final value
used.
 
To overcome this problem (where a .Net WSE 2.0 webservice, using
WS-Addressing requires the
http://schemas.xmlsoap.org/ws/2004/03/addressing namespace to be
specified), we have added a small section to allow the addition of the
http://schemas.xmlsoap.org/ws/2004/03/addressing namespace as an
option. I should caution, that this modification, although appears to
work with the .Net WSE 2.0 webservice that we are communicating with, we
have not done exhaustive tests yet to confirm what side effects this may
cause. Also, in our research of this problem, it appears that this is a
known problem for .Net clients as well, where .Net WSE 3.0 clients also
have problems talking with .Net WSE 2.0 services due to this addressing
namespace issue (See Ref:
http://weblogs.asp.net/cibrax/archive/2005/11/25/431528.aspx and 
 
To be honest - if it was possible, the ideal solution would be to turn
off addressing for the WSE 2.0 service.
 
 
org.apache.axis2.handlers.addressing.AddressingOutHandler.java
========================================
...
public static String WSA_NAMESPACE_WS_2004_03 =
"http://schemas.xmlsoap.org/ws/2004/03/addressing";;
...

String namespace = Final.WSA_NAMESPACE;
        
       if
(Submission.WSA_NAMESPACE.equals(addressingVersionFromCurrentMsgCtxt))
{
           isFinalAddressingNamespace = false;
           namespace = Submission.WSA_NAMESPACE;
       }

        if (WSA_NAMESPACE_WS_2004_03
.equals(addressingVersionFromCurrentMsgCtxt)) {
            isFinalAddressingNamespace = false;
            namespace = WSA_NAMESPACE_WS_2004_03;
        }
========================================
 
We then set up the request to use the namespace within the client
using
============================================
...
binding._getServiceClient().getOptions().setProperty(AddressingConstants.WS_ADDRESSING_VERSION,
AddressingOutHandler.WSA_NAMESPACE_WS_2004_03);
...
============================================
 

>>> [EMAIL PROTECTED] 09/06/07 1:07 pm >>>
I also had this same problem a year ago - you can search the mailing
list archive to find out how I got it solved - but it did change the
SOAP packets to the 2004 namespace - I had to change it for an interop
project with a .NET web service and client.

I just assumed that it was because MS take so long to release stuff -
but its been 2 years now, so it looks like they don't really care that
they aren't up to date.

Andrew McGhee wrote: 
Hi,
I'm developing a Java Axis2 1.1 client consuming a dot net web service
which requires WS-Addressing.
 
I'm having problems with changing the WS-Addr schema reference in my
request.
 
In the client I have the following code...
<code>
    public static void setClientProperties(org.apache.axis2.client.Stub
stub) {
       
stub._getServiceClient().getOptions().setProperty(AddressingConstants.WS_ADDRESSING_VERSION,
AddressingConstants.Submission.WSA_NAMESPACE);
}
</code>
 
... I can debug and see the value being set correctly, but the SOAP
request always has...
<soapenv:Envelope xmlns:wsa="http://www.w3.org/2005/08/addressing";
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
 
Is this the correct way of changing the WS-Addr namespace? In which
object should I be setting the namespace?
 
I also note that the value for the
AddressingConstants.Submission.WSA_NAMESPACE =
"http://schemas.xmlsoap.org/ws/2004/08/addressing";, yet the dot net
web service returns an error unless this is changed to
"http://schemas.xmlsoap.org/ws/2004/03/addressing"; (note the month
change).
 
I'm presuming that once I can set the WS-Addr namespace to the
submission value, I can change it to anything I like as the
setProperty() method takes an Object/String as an argument. However I'm
curious if anyone knows the history behind Microsoft using this other
namespace - is it an earlier submission or just MS creating its own
standards?

Many thanks in advance for any advice anyone can provide.


*****************************************************************
This email, including any attachments sent with it, is
confidential and for the sole use of the intended recipient(s).
This confidentiality is not waived or lost, if you receive it and
you are not the intended recipient(s), or if it is transmitted/
received in error.

Any unauthorised use, alteration, disclosure, distribution or
review of this email is strictly prohibited.  The information
contained in this email, including any attachment sent with
it, may be subject to a statutory duty of confidentiality if it
relates to health service matters.

If you are not the intended recipient(s), or if you have
received this email in error, you are asked to immediately
notify the sender by telephone collect on Australia
+61 1800 198 175 or by return email.  You should also
delete this email, and any copies, from your computer
system network and destroy any hard copies produced.

If not an intended recipient of this email, you must not copy,
distribute or take any action(s) that relies on it; any form of
disclosure, modification, distribution and/or publication of this
email is also prohibited.

Although Queensland Health takes all reasonable steps to
ensure this email does not contain malicious software,
Queensland Health does not accept responsibility for the
consequences if any person's computer inadvertently suffers
any disruption to services, loss of information, harm or is
infected with a virus, other malicious computer programme or
code that may occur as a consequence of receiving this
email.

Unless stated otherwise, this email represents only the views
of the sender and not the views of the Queensland Government.
****************************************************************

Reply via email to