I did some debugging and discovered that the RECV_RESULTS are not found in
the right place. My fix (probably not the best fix) is to override
getProperty() on the WSS4JOutInterceptor class as follows:


        @Override
        public Object getProperty(Object msgContext, String key)
        {
                // use the superclass first
                Object result = super.getProperty(msgContext, key);
                
                // handle the special case of the RECV_RESULTS
                if (result == null && key == WSHandlerConstants.RECV_RESULTS)
                {
                        result = ((Message) 
msgContext).getExchange().getInMessage().get(key);
                }               
                
                return result;
        }

So it appears that the RECV_RESULTS are present, but they are in the
Exchange.getInMessage(), which is not being searched by
WSS4JOutInterceptor.getProperty().

I’m using CXF 2.2.2 and wss4j-1.5.7.jar.




santhosh00724 wrote:
> 
> Did any tried it. I am trying but not able to make any progress. The code
> that is throwing exception is in 
> 
> WSS4JOutInterceptor.java Line:220
> 
> doSenderAction(doAction, doc, reqData, actions, Boolean.TRUE
>                         .equals(getProperty(mc,
> org.apache.cxf.message.Message.REQUESTOR_ROLE)));
> 
> Or can one suggest other alternatives for using multiple clients. 
> 
> 
> dkulp wrote:
>> 
>> 
>> The RECV_RESULTS is the vector of result things that should have been
>> saved 
>> from the INCOMING message.   Basically, the WSS4JInInterceptor should
>> have 
>> saved that someplace where the OUT interceptor can grab it.   
>> 
>> Dan
>> 
>> 
>> On Wed April 1 2009 9:31:52 am santhosh00724 wrote:
>>> I was debugging the code with WSS4J 1.5.6 version. When the control goes
>>> into the WSHandler's function
>>>
>>>     private void handleSpecialUser(RequestData reqData) {
>>>         if
>>> (!WSHandlerConstants.USE_REQ_SIG_CERT.equals(reqData.getEncUser())) {
>>>             return;
>>>         }
>>>         Vector results =
>>>             (Vector) getProperty(reqData.getMsgContext(),
>>> WSHandlerConstants.RECV_RESULTS);        if (results == null) {
>>>             return;
>>>         }
>>>
>>>
>>>
>>> I am getting results vector as null and the function is not executed
>>> properly. Can any one from CXF dev explain what this results vector
>>> should
>>> contain and why is it returning null. I am trying to fix it if there is
>>> no
>>> patch for cxf to handle multiple clients .. please help..
>>>
>>> Santhosh.
>>>
>>> santhosh00724 wrote:
>>> > Thank you for reply,
>>> >
>>> > This is what I am getting now. I am using CXF 2.1.3. is this a
>>> problem. I
>>> > tried using CXF 2.2 & 2.1.4 I am getting :
>>> > java.lang.ClassNotFoundException:
>>> > org.springframework.context.support.AbstractRefres
>>> > hableConfigApplicationContext
>>> >
>>> > Santhosh.
>>> >
>>> > Original Exception with CXF 2.1.3:
>>> > org.apache.ws.security.WSSecurityException: Error during encryption: ;
>>> > nested exception is:
>>> >         org.apache.ws.security.WSSecurityException: General security
>>> > error (No certificates for user useReqSigCert were found for
>>> encryption)
>>> > at
>>> >
>>> org.apache.ws.security.action.EncryptionAction.execute(EncryptionAction.j
>>> >ava:64) at
>>> >
>>> org.apache.ws.security.handler.WSHandler.doSenderAction(WSHandler.java:20
>>> >1) at
>>> >
>>> org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor.access$200(WSS4JOutI
>>> >nterceptor.java:47) at
>>> >
>>> org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutInterceptorI
>>> >nternal.handleMessage(WSS4JOutInterceptor.java:219) at
>>> >
>>> org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutInterceptorI
>>> >nternal.handleMessage(WSS4JOutInterceptor.java:107) at
>>> >
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorCh
>>> >ain.java:220) at
>>> >
>>> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(Outgoin
>>> >gChainInterceptor.java:74) at
>>> >
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorCh
>>> >ain.java:220) at
>>> >
>>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiatio
>>> >nObserver.java:78) at
>>> >
>>> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestina
>>> >tion.java:92) at
>>> >
>>> org.apache.cxf.transport.servlet.ServletController.invokeDestination(Serv
>>> >letController.java:285) at
>>> >
>>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletControll
>>> >er.java:168) at
>>> >
>>> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFSer
>>> >vlet.java:175) at
>>> >
>>> org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFSer
>>> >vlet.java:153) at
>>> > javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at
>>> > javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at
>>> >
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicat
>>> >ionFilterChain.java:290) at
>>> >
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilte
>>> >rChain.java:206) at
>>> >
>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve
>>> >.java:233) at
>>> >
>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve
>>> >.java:191) at
>>> >
>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
>>> >128) at
>>> >
>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
>>> >102) at
>>> >
>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.j
>>> >ava:109) at
>>> >
>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:28
>>> >6) at
>>> >
>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845
>>> >) at
>>> >
>>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(H
>>> >ttp11Protocol.java:583) at
>>> >
>>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>>> >         at java.lang.Thread.run(Thread.java:619)
>>> > Caused by: org.apache.ws.security.WSSecurityException: General
>>> security
>>> > error (No certificates for user useReqSigCert were found for
>>> encryption)
>>> >         at
>>> >
>>> org.apache.ws.security.message.WSSecEncrypt.prepare(WSSecEncrypt.java:248
>>> >) at
>>> >
>>> org.apache.ws.security.message.WSSecEncrypt.build(WSSecEncrypt.java:288)
>>> >         at
>>> >
>>> org.apache.ws.security.action.EncryptionAction.execute(EncryptionAction.j
>>> >ava:62) ... 27 more
>>> >
>>> > Colm O hEigeartaigh wrote:
>>> >> Hi,
>>> >>
>>> >> Can you try again, except this time using a SNAPSHOT version of WSS4J
>>> >> available here:
>>> >>
>>> >> http://people.apache.org/~coheigea/stage/wss4j/1.5.7-SNAPSHOT/
>>> >>
>>> >> Dan Kulp made some fixes lately for some multi-threaded problems that
>>> >> are included in the SNAPSHOT...this *may* be causing the problem.
>>> >>
>>> >> Colm.
>> 
>> -- 
>> Daniel Kulp
>> dk...@apache.org
>> http://www.dankulp.com/blog
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/WSSecurityEngine%3A-Callback-supplied-no-password-for%3A-null--when-using-useReqSigCert-for-encryptionUser-in-multiple-client-scenario.-tp22745189p24058681.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Reply via email to