Tomasz Sztelak (JIRA) wrote:
[ http://jira.codehaus.org/browse/XFIRE-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88636 ]
Tomasz Sztelak commented on XFIRE-890:
--------------------------------------
Currently the workround to this problem is to add DOMOutHandler to global
handers chain. Then you can add WSS4JOutHandler to outHandlers and
faultHandlers on service level. I'll commit the real fix in day or two.
Thanks Tomasz! This does work for me. I'll test your patch as well
when it's ready.
Nate
Fault Handlers only working on global XFire Singleton. Ignored on service
handlers.
-------------------------------------------------------------------------------------
Key: XFIRE-890
URL: http://jira.codehaus.org/browse/XFIRE-890
Project: XFire
Issue Type: Bug
Components: Core
Affects Versions: 1.2.4
Reporter: Nate Johnson
Assigned To: Tomasz Sztelak
Ok, so here's an update. I got my services to work in both secure and
insecure mode (that is some services are published as secure, other
insecure -- not one service as both). I did this by using the handlers
on the Service objects rather than the global XFire object. Makes sense.
Here's my problem now: Faults only seem to work from the global XFire
object. So when a fault occurs, it doesn't appear that the framework
will look at the Service's handlers to handle the fault on a service by
service basis, but rather the XFire fault handlers only and since not
all services are secured, I get exceptions when wss4j headers are
expected in some cases, but not others.
I verified this by adding a secure handler to the Global XFire fault
handler, caused a fault in the insecure service and got a prolog eof
exception because the wss4j headers were missing. Then tried a secure
fault and got the real fault back in the client which is what was
expected. Flipped the scenario and got the exact opposite results.
So, what I need is the framework to use the service fault handlers when
a fault occurs (when they are registered, of course) rather than the
global handlers.
I think this is in the DefaultEndpoint class, around line 70 in the
catch block when the fault is created and piped through.
I'd be happy to test this once it is fixed.
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
