Thanks Willem It's the WS-Security header;
//soap 12 QName wsseQName = new QName(WSConstants.WSSE_NS, WSConstants.WSSE_LN); //soap 11 QName wsse11QName = new QName(WSConstants.WSSE11_NS, WSConstants.WSSE_LN); When security is enabled, we filter it. Then everything is ok. > -----original ----- > Sender: Willem Jiang [mailto:willem.ji...@gmail.com] > Date: 2011年6月14日 11:31 > Receiver: users@camel.apache.org > Subject: Re: Bean Processor cause WS Security Failure > > What's request security header name ? > Maybe we can consider to filter the security header of the CXF message > in CxfHeaderFilterStrategy. > You can configure your own HeaderFilterStrategy by extends the > CxfHeaderFilterStrategy. > > > On 6/14/11 10:37 AM, ext2 wrote: > > > > Hi: > > > > Following is a simple sayHello Webservice implemented by camel. > > <from uri="cxf:endpointHello:..."/> > > <bean ref=".." method="..."/> > > The webservice's request is configured to decrypt by server > > certificate and response is configured to encrypt by client certificate. > > > > If I use a bean as following, every thing is ok > > helloBean{ > > void sayHello(Exchange ex){ > > ex.getOut().setBody("hello"); > > } > > } > > ; > > > > But using following bean , response encryption will failed. > > HelloBean{ > > String sayHello(String greet){ > > return "hello"; > > } > > } > > > > the reason is the second bean will propagate headers(also include > > security header) from cxf request, it is conflicted with response security. > > But the first bean doesn't propagate headers; > > > > Is it issue of bean processor? cxf component? Or just a document FAQ > > to caution the user to filter the security header by himself? > > > > > > > > > > > -- > Willem > ---------------------------------- > FuseSource > Web: http://www.fusesource.com > Blog: http://willemjiang.blogspot.com (English) > http://jnn.javaeye.com (Chinese) > Twitter: willemjiang > Weibo: willemjiang
