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 <[email protected]> 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 <[email protected]> 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 >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >>
