Yang, Gang CTR US USA wrote:
Classification: UNCLASSIFIED
Caveats: NONE
Simon,
For bare mode, if you don't populate SOAPAction, how is the service side
going to determine the endpoint method?
The difference seems to be that the JAX-WS RI generates WSDL with a global
element name and message part name that are the same as the operation name.
Tuscany generates WSDL with a global element name and message part name
of arg0, so it needs to add SOAPAction to provide the operation name.
The JAX-WS specification says that the global element name and message
part name must be the same as the operation name, so Tuscany doesn't
conform to JAX-WS in the WSDL that it generates for bare operations.
I'll raise a JIRA for this.
Is there any reason why Tuscany shouldn't use the correct JAX-WS mapping
and remove the nonstandard addition of SOAPAction?
On the same topic, I did the work-around you and Scott suggested - to
use @WebMothod to force Tuscany to populate SOAPAction. It worked with
some extra code I had to add to my PolicyHandler.
The code that I had to add is to also modify the Tuscany internal
Message that is also passed into beforeInvoke() after the decryption is
done. My original code was only modifying the SOAP envelope in the
MessageContext. I had to do this because the Message was set to use the
SOAP body before calling PolicyHandler in
Axis2ServiceProvider.invokeTarget() and it did not work correctly when
it was used to call the endpoint via wire.invoke().
Now should the code that modifies the Tuscany internal Message be done
in my PolicyHandler code or be pulled back to Tuscany framework to hide
the relations between MessageContext/envelope and Message? To me, it
wasn't obvious how Message is related to MessageContext/envelope until I
looked at Tuscany's code. This implementation can change in the future
w/o PolicyHandler developer's knowledge. I'm wondering how others think.
There's a commented out call to beforeInvoke() at line 66 in
Axis2ServiceInOutSyncMessageReceiver, which would do what you are
suggesting. This call would run before Tuscany's Message object is
constructed, so your code would only need to manipulate the Axis2
MessageContext and Tuscany would build the correct Message object
from that.
I don't know the history of why this call was commented out and
replaced by the other beforeInvoke() call in Axis2ServiceProvider.
There's also a matching commented out afterInvoke() call at line 74
of Axis2ServiceInOutSyncMessageReceiver, together with a pair of
similar commented out calls in Axis2ServiceInMessageReceiver.
Does anyone know the history of why these other calls to beforeInvoke()
and afterInvoke() were commented out?
Simon
Thanks to Simon and Scott's suggestion.
Gang
-----Original Message-----
From: Simon Nash [mailto:n...@apache.org]
Sent: Tuesday, February 01, 2011 3:23 PM
To: dev@tuscany.apache.org
Subject: Re: An issue with Axis2 WS binding dispatcher - the dispatching
mechanism does not support SOAP message body encryption (UNCLASSIFIED)
Simon Nash wrote:
Scott Kurz wrote:
Ah, thanks Simon for reminding us of that. I'd remembered us
generating a soapAction anyway.. but that's just for the bare mapping
apparently.
I saw that code, and I was rather puzzled by it as I didn't see
anything in the JAX-WS spec to say that SOAPAction should be
generated in the bare mapping case.
Perhaps I should run a couple of Java interfaces (bare and wrapped)
through the JAX-WS RI wsgen to see what it does with them.
I tried this, and wsgen doesn't seem to treat the bare case any
differently than the wrapped case. In both cases soapAction is
generated only if specified by @WebMethod(action=....)
Why does Tuscany always generate soapAction for the bare case,
even though this is inconsistent with JAX-WS?
Simon
Classification: UNCLASSIFIED
Caveats: NONE
