Using Xfire 1.2.4, I've succeeded doing this with a services.xml. The problem
is that on service side, I throw a FaultInfoException with a detail, and on
client side I catch a XFireRuntimeException without this detail. No way to
get the detail exception !
The second problem is that using Xfire 1.2.5, there is a regression =>I have
the message : Unexpected EOF in prolog
at [row,col {unknown-source}]: [1,0]
Differences between my tests in 1.2.4 and 1.2.5 : wss4j-1.5.0.jar =>
wss4j-1.5.1.jar, xbean-spring-2.7.jar => xbean-spring-2.8.jar,
xfire-all-1.2.4.jar =>xfire-all-1.2.5.jar
Conclusion : there are 2 problems (bugs ?)
My services.xml :
<beans xmlns="http://xfire.codehaus.org/config/1.0";>
<xfire>
<inHandlers>
<handler
handlerClass="org.codehaus.xfire.util.dom.DOMInHandler" />
<bean
class="org.codehaus.xfire.security.wss4j.WSS4JInHandler" xmlns="">
<property name="properties">
<props>
<prop
key="action">Signature</prop>
<prop
key="signaturePropFile">service.properties</prop>
<prop
key="passwordCallbackClass">net.xxx.astral.handler.PasswordHandler</prop>
</props>
</property>
</bean>
<handler
handlerClass="net.xxx.astral.handler.SecurityHandler" />
</inHandlers>
<outHandlers>
<handler
handlerClass="org.codehaus.xfire.util.dom.DOMOutHandler" />
<bean
class="org.codehaus.xfire.security.wss4j.WSS4JOutHandler" xmlns="">
<property name="properties">
<props>
<prop
key="action">Signature</prop>
<prop
key="signaturePropFile">service.properties</prop>
<prop
key="signatureKeyIdentifier">DirectReference</prop>
<prop
key="passwordCallbackClass">net.xxx.astral.handler.PasswordHandler</prop>
<prop key="user">wsopcvm</prop>
</props>
</property>
</bean>
</outHandlers>
<faultHandlers>
<handler
handlerClass="org.codehaus.xfire.util.dom.DOMOutHandler" />
<bean
class="org.codehaus.xfire.security.wss4j.WSS4JOutHandler" xmlns="">
<property name="properties">
<props>
<prop
key="action">Signature</prop>
<prop
key="signaturePropFile">service.properties</prop>
<prop
key="signatureKeyIdentifier">DirectReference</prop>
<prop
key="passwordCallbackClass">net.xxx.astral.handler.PasswordHandler</prop>
<prop key="user">wsopcvm</prop>
</props>
</property>
</bean>
</faultHandlers>
</xfire>
<service>
<name>Patrimoine</name>
<namespace>http://astral.xxx.net/Patrimoine</namespace>
<serviceClass>net.xxx.astral.service.PatrimoineImpl</serviceClass>
<serviceFactory>jsr181</serviceFactory>
</service>
</beans>
Ryan Kirkendall wrote:
>
> 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
>
>
>
--
View this message in context:
http://www.nabble.com/Faults-not-signed-tf3273593.html#a9490664
Sent from the XFire - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
