[
https://issues.apache.org/jira/browse/CXF-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888929#action_12888929
]
Daniel Kulp commented on CXF-2899:
----------------------------------
The ws-security.signature.crypto method SHOULD work fine providing it propery
points to a Crypto object. How (and when) are you creating the Crypto
object? Can I see the config or code? Maybe an example test case?
> NPE in WSS4J due to null Cryptos when using ws-security.*.crypto instead of
> ws-security.*.properties
> ----------------------------------------------------------------------------------------------------
>
> Key: CXF-2899
> URL: https://issues.apache.org/jira/browse/CXF-2899
> Project: CXF
> Issue Type: Bug
> Components: Documentation
> Affects Versions: 2.2.9
> Environment: All apply, but this was discovered on 64bit Ubuntu
> Reporter: Ravi Luthra
>
> Null pointer exception in the given stack trace (see below). Turns out the
> Crypto objects are null which is caused by a documentation issue on this page:
> http://cxf.apache.org/docs/ws-securitypolicy.html
> I originally implemented my properties at runtime (using Java code directly)
> by setting up the Crypto object directly (using the Merlin class) and used
> the properties on the above mentioned URL: ws-security.signature.crypto and
> ws-security.encryption.crypto. These properties work until the stack reaches
> into the WSS4J boundary. The fix was to use the properties
> ws-security.signature.properties and ws-security.encryption.properties as
> these are the ones considered during the hand-off to WSS4J, not the
> ws-security.*.crypto properties. The stack trace went away when I used the
> other properties.
> java.lang.NullPointerException
> at
> org.apache.ws.security.message.token.X509Security.getX509Certificate(X509Security.java:92)
> at
> org.apache.ws.security.processor.BinarySecurityTokenProcessor.getCertificatesTokenReference(BinarySecurityTokenProcessor.java:105)
> at
> org.apache.ws.security.processor.BinarySecurityTokenProcessor.handleToken(BinarySecurityTokenProcessor.java:81)
> at
> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:326)
> at
> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:243)
> at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:208)
> at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:78)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:110)
> at
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:98)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:423)
> ... Unrelated portion of stack
> The fix I am asking for is a fix in the documentation next to the .crypto
> properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
