This is resolved. Registering the WSS and DOM handlers with XFire and
not on a service by service basis resolved the issue. Details below:
In certain scenarios we were trying to programmatically register
services using the Spring API like so:
XFireExporter serviceExporter = new XFireExporter();
XFire xfire = (XFire) SpringLoader.getInstance().getBean("xfire");
serviceExporter.setXfire(xfire);
serviceExporter.setServiceFactory((ServiceFactory)
SpringLoader.getInstance().getBean("xfire.serviceFactory"));
serviceExporter.setName(entry.getQname().toString());
serviceExporter.setServiceBean(serviceImpl);
serviceExporter.setServiceClass(this.getClass().forName(entry.getServiceInterfaces().get(0).getServiceInterface()));
serviceExporter.afterPropertiesSet();
//store service exporter for later use
We were registering in/out/fault security handlers with each service
programmatically. This was giving the exception below, during faults.
It may have been a problem with the programmatic setup.
In order to get this working the security handlers had to be registered
on the XFire instance.
Like so:
XFire xfire = (XFire) SpringLoader.getInstance().getBean("xfire");
List inHandlers = new ArrayList();
inHandlers.add(new org.codehaus.xfire.util.dom.DOMInHandler());
inHandlers.add(new WorkflowXFireWSS4JInHandler());
inHandlers.add(new org.codehaus.xfire.util.LoggingHandler());
xfire.getInHandlers().addAll(inHandlers);
List outHandlers = new ArrayList();
outHandlers.add(new org.codehaus.xfire.util.dom.DOMOutHandler());
outHandlers.add(new WorkflowXFireWSS4JOutHandler());
outHandlers.add(new org.codehaus.xfire.util.LoggingHandler());
xfire.getOutHandlers().addAll(outHandlers);
List faultHandlers = new ArrayList();
faultHandlers.add(new org.codehaus.xfire.util.dom.DOMOutHandler());
faultHandlers.add(new WorkflowXFireWSS4JOutHandler());
faultHandlers.add(new org.codehaus.xfire.util.LoggingHandler());
xfire.getFaultHandlers().addAll(faultHandlers);
This could have been done via Spring.
Next, the client needs to NOT have any faults handlers registered.
Registering WSS handlers as fault handlers will cause problems.
Client client = Client.getInstance(userService);
client.addOutHandler(new DOMOutHandler());
Properties outProperties = new Properties();
configureOutProperties(outProperties);
client.addOutHandler(new WSS4JOutHandler(outProperties));
client.addInHandler(new DOMInHandler());
Properties inProperties = new Properties();
configureOutProperties(inProperties);
client.addInHandler(new WSS4JInHandler(inProperties));
At this point everything is working well.
Thanks,
Ryan
Ryan Kirkendall wrote:
Did that, but I wasn't sure if this was the right way to go or not. Here
are the handlers:
faultHandlers.add(new org.codehaus.xfire.util.dom.DOMOutHandler());
faultHandlers.add(new WorkflowXFireWSS4JOutHandler());
The exception I'm getting is below.
Xalan 2.7
Xerces 2.9 download
WSS4J 1.5.0 -> 1.5.1 gives NPE at different spot but fails all the same
These results are repeatable with
Xerces 2.7.1 (which is the default with the Xalan 2.7 download).
2007-02-22 12:12:18,538 [http-8080-Processor24] DEBUG
org.codehaus.xfire.handler.HandlerPipeline :: Invoking handler
edu.iu.uis.eden.config.xfire.WorkflowXFireWSS4JOutHandler in phase user
2007-02-22 12:12:18,538 [http-8080-Processor24] DEBUG
org.codehaus.xfire.security.wss4j.WSS4JOutHandler :: WSDoAllSender:
enter invoke()
2007-02-22 12:12:18,538 [http-8080-Processor24] DEBUG
org.codehaus.xfire.security.wss4j.WSS4JOutHandler :: Action: 2
2007-02-22 12:12:18,538 [http-8080-Processor24] DEBUG
org.codehaus.xfire.security.wss4j.WSS4JOutHandler :: Actor: null
2007-02-22 12:12:18,626 [http-8080-Processor24] ERROR
org.codehaus.xfire.handler.DefaultFaultHandler :: Could not send fault.
org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or
change an object in a way which is incorrect with regard to namespaces.
at org.apache.xerces.dom.CoreDocumentImpl.checkNamespaceWF(Unknown
Source)
at org.apache.xerces.dom.ElementNSImpl.setName(Unknown Source)
at org.apache.xerces.dom.ElementNSImpl.<init>(Unknown Source)
at org.apache.xerces.dom.CoreDocumentImpl.createElementNS(Unknown
Source)
at
org.apache.ws.security.util.WSSecurityUtil.createElementInSameNamespace(WSSecurityUtil.java:519)
at
org.apache.ws.security.util.WSSecurityUtil.findWsseSecurityHeaderBlock(WSSecurityUtil.java:637)
at
org.apache.ws.security.message.WSSecHeader.insertSecurityHeader(WSSecHeader.java:134)
at
org.apache.ws.security.handler.WSHandler.doSenderAction(WSHandler.java:98)
at
org.codehaus.xfire.security.wss4j.WSS4JOutHandler.invoke(WSS4JOutHandler.java:154)
at
org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
at
org.codehaus.xfire.handler.DefaultFaultHandler.sendFault(DefaultFaultHandler.java:88)
at
org.codehaus.xfire.handler.DefaultFaultHandler.invoke(DefaultFaultHandler.java:51)
In case the last handler 'WorkflowXFireWSS4JOutHandler' looks strange.
It is a subclass of WSS4JOutHandler that builds a Crypto from app config
instead of a props file. It works fine for everything but faults.
Ryan
Tomek Sztelak wrote:
Try adding WSS4J and dom handlers to faultsHandlers chain.
On 2/22/07, Ryan Kirkendall <[EMAIL PROTECTED]> wrote:
Hello,
I'm using XFire with WSS4J to sign messages. This works great, until
there is a fault. In which case my client complains that the message is
not signed.
How do I sign a fault so the client does not complain the return message
is unsigned?
Thanks in advance,
Ryan Kirkendall
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
