cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <freeman.f...@gmail.com>
Subject Re: TransportBinding and SignatureConfirmation
Date Wed, 10 Oct 2012 06:15:38 GMT
Hi,

A quick question, did you build from the project root or just a module?

-------------
Freeman Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042

On 2012-10-10, at 上午3:32, Sunil Bapat wrote:

> Sure. I can try submitting the bug and a patch.
> 
> I downloaded the trunk code, and tried to build without making any
> changes. I am getting test failures. Are they
> 
> expected? Is there any other setup required other than what is
> described at http://cxf.apache.org/building.html?
> 
> Maybe I am missing something.
> 
> The test failures are:
> 
>  testCallSayHi(org.apache.cxf.javascript.GreeterClientTest): Error
> creating bean with name 'greeter-service-endpoint': Cannot create
> inner bean '(inner bean)' of type
> [org.apache.cxf.javascript.hwdemo.GreeterImpl] while setting bean
> property 'serviceBean'; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error
> creating bean with name '(inner bean)' defined in class path resource
> [GreeterClientTestBeans.xml]: Instantiation of bean failed; nested
> exception is java.lang.ExceptionInInitializerError
> 
>  testRequestClosure(org.apache.cxf.javascript.GreeterClientTest):
> Error creating bean with name 'greeter-service-endpoint': Cannot
> create inner bean '(inner bean)' of type
> [org.apache.cxf.javascript.hwdemo.GreeterImpl] while setting bean
> property 'serviceBean'; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error
> creating bean with name '(inner bean)' defined in class path resource
> [GreeterClientTestBeans.xml]: Instantiation of bean failed; nested
> exception is java.lang.NoClassDefFoundError: Could not initialize
> class org.apache.cxf.javascript.hwdemo.GreeterImpl
> 
> 
> ...
> 
> Inner exception is:
> 
> Caused by: java.lang.RuntimeException: Uncompilable source code -
> cannot find symbol
>  symbol: class Greeter
>        at org.apache.cxf.javascript.hwdemo.GreeterImpl.<clinit>(GreeterImpl.java:34)
>        ... 53 more
> 
> 
> ...
> 
> [INFO] Apache CXF Runtime JavaScript Client Generator Tests  FAILURE
> 
> The missing Greeter class is in testutils.
> 
> Thanks
> Sunil.
> 
> 
> On Thu, Oct 4, 2012 at 2:54 PM, Daniel Kulp <dkulp@apache.org> wrote:
>> 
>> Definitely looks like a bug to me.   Any chance you can log it?  Since you've already
dug into there, any chance you can create a patch?
>> 
>> Dan
>> 
>> 
>> 
>> On Oct 4, 2012, at 1:30 PM, Sunil Bapat <subapat@gmail.com> wrote:
>> 
>>> I am working on writing a client to a web service using CXF 2.6.2. The
>>> service has a security policy which uses TransportBinding with SAML
>>> EndorsingSupportingTokens. The policy also requires Signature Confirmation
>>> (<sp:RequireSignatureConfirmation/>).
>>> 
>>> What is happening is that the client calls the service correctly with the
>>> required security elements. The response from the server contains a
>>> Signature Confirmation element, and the response fails with the error:
>>> Received a SignatureConfirmation element, but there are no stored signature
>>> values
>>> 
>>> Debugging through the CXF code, here's what is happening:
>>> 
>>> - After configuring the client, the WSS11Builder calls
>>> setRequireSignatureConfirmation(true) based on the policy.
>>> 
>>> - In the constructor of AbstractBindingBuilder, it initializes the
>>> signatures array property with an empty array, and puts it in the message
>>> as follows:
>>> message.getExchange().put(WSHandlerConstants.SEND_SIGV, signatures)
>>> 
>>> - In the TransportBindingHandler.handleEndorsingToken (line 300), it calls
>>> addSig, which eventually calls the doSignature. However, the signature is
>>> never added to the signatures array. (SymmetricBindingHandler and
>>> AsymmetricBindingHandler do a signatures.add)
>>> 
>>> - As a result when the service response comes to the WSS4JInInterceptor, it
>>> calls checkSignatureConfirmation in WSHandler, which retrieves the
>>> savedSignatures using
>>> List<byte[]> savedSignatures =
>>>           (List<byte[]>) getProperty(reqData.getMsgContext(),
>>> WSHandlerConstants.SEND_SIGV);
>>> 
>>> - This array is empty, since the signature was never added by
>>> TransportBindingHandler. Therefore it throws the above exception.
>>> 
>>> The question is - is this a bug, or is it by design that the
>>> SignatureConfirmation does not work with TransportBinding, and that they
>>> are not allowed together?
>>> 
>>> Thanks
>>> Sunil.
>> 
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message