Ok, so I got around this issue by moving AddressingInHandler into the same
phase as the SoapActionInHandler and mandating that it is invoked after
SoapActionInHandler (see below).
Does anyone know if there are any drawbacks to this? I know that if I move
the SoapActionInHandler up a phase I get a NPE, so I ahve to move the
AddressingInHandler down a phase...
<property name="inHandlers">
<list>
<bean
class="
org.codehaus.xfire.soap.handler.SoapActionInHandler" />
<bean
class="org.codehaus.xfire.addressing.AddressingInHandler
">
<property name="phase" value="dispatch" />
<property name="after">
<list>
<value>
org.codehaus.xfire.soap.handler.SoapActionInHandler
</value>
</list>
</property>
</bean>
<bean
class="
com.daon.de.ws.xfire.core.handlers.ApiResolutionHandler" />
</list>
</property>
On 3/14/07, Adrian Corcoran <[EMAIL PROTECTED]> wrote:
Hi,
Can someone tell me why SoapActionInHandler overwrites the operation that
AddressingInHandler in handler may have found. Think of the case where there
is a message being sent - there is ws-addressing, someone tampers with the
headers (not signed) to alter the soap action, the AddressingInHandler does
the correct thing - sets the operation from the soap addressing, but the
SoapActionInHandler comes along and messes this up by taking the SOAPAction
from the http header and overwriting the operation if one exists.
Has anyone come across this problem? Is there an easy fix for this? I can
see how I would fix this in XFire's code base, but is there anyway to
override the (bad) behavior of the SoapActionInHandler without altering
XFire's code base?
Regards,
Adrian
