Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
NullPointerException on First invocation to Spring WS Service with Nonce [SWS-841] #915
I have a web service implemented with Spring WS stack over a JBoss 5.1 GA.
The service has configured as one of the interceptors the security interceptor:
<bean id="wsSecurityInterceptor" class="org.springframework.ws.soap.security.xwss.XwsSecurityInterceptor"> <property name="policyConfiguration" value="/WEB-INF/securityPolicy.xml" /> <property name="callbackHandlers"> <list> <ref bean="ldapAuthenticationHandler" /> </list> </property> </bean>
The content of securityPolicy.xml file is the following one:
<xwss:RequireUsernameToken passwordDigestRequired="false" nonceRequired="true" />
The problem is that since I set the nonceRequired attribute to true, always the first invocation sent to the service returns a NullPointerException:
<SOAP-ENV:Fault> <faultcode>SOAP-ENV:Client</faultcode> <faultstring xml:lang="en">java.lang.NullPointerException; nested exception is com.sun.xml.wss.XWSSecurityException: java.lang.NullPointerException</faultstring> </SOAP-ENV:Fault>
On following invocations exception is never found again.
Is there any way to avoid this problem? The environment on which the app is installed restarts everyday so always users get this error once a day.
I attach the full appContext file of the web service in case it helps.
Thanks a lot and regards.
Referenced from: commits f3445a8
1 votes, 3 watchers
Arjen Poutsma commented
After some more verification, it seems that the NPE occurs when a message does contain a Nonce element, but does not contain a Created element. XWSS does not like this, and throws a NullPointerException with the following stacktrace:
The stacktrace originates from the fact that com.sun.xml.wss.impl.misc.NonceCache.validateAndCacheNonce wants to insert a null value for the created date into a Hashtable, which does not allow null values.
I tried to create a workaround for this, by repeating the XWSS method call twice (as suggested in the description), but this seems to have no effect.
Closing as Won't Fix, because it appears to be a XWSS issue with no possible workaround. If more investigation is requested, please supply a reproducible test case in the same format as org.springframework.ws.soap.security.xwss.XwssMessageInterceptorUsernameTokenTest.