XFire

Empty element value can cause NPE

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.2.3, 1.2.4
  • Fix Version/s: 1.2.5
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    1

Description

From the mailing list:

I tried to upgrade from 1.2.2 to 1.2.4 (and this problem occurred after every release after 1.2.2). Whenever I try to send a SOAP request to my service and it contains:

<someNode></someNode> or <someNode />, I get a null pointer exception.

If I put a line break in the node, or even a blank space, it works fine:

<someNode>

</someNode>

The stack trace is below:

MIT: 52234 [http-8080-Processor22] ERROR org.codehaus.xfire.handler.DefaultFaultHandler - Fault occurred!

java.lang.NullPointerException

at org.codehaus.xfire.aegis.stax.ElementReader.getValue(ElementReader.java:131)

at org.codehaus.xfire.aegis.type.basic.StringType.readObject(StringType.java:21)

at org.codehaus.xfire.aegis.type.basic.BeanType.readObject(BeanType.java:159)

at org.codehaus.xfire.aegis.AegisBindingProvider.readParameter(AegisBindingProvider.java:162)

at org.codehaus.xfire.service.binding.AbstractBinding.read(AbstractBinding.java:206)

at org.codehaus.xfire.service.binding.WrappedBinding.readMessage(WrappedBinding.java:50)

at org.codehaus.xfire.soap.handler.SoapBodyHandler.invoke(SoapBodyHandler.java:42)

at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)

at org.codehaus.xfire.transport.DefaultEndpoint.onReceive(DefaultEndpoint.java:64)

at org.codehaus.xfire.transport.AbstractChannel.receive(AbstractChannel.java:38)

at org.codehaus.xfire.transport.http.XFireServletController.invoke(XFireServletController.java:301)

at org.codehaus.xfire.transport.http.XFireServletController.doService(XFireServletController.java:130)

at org.codehaus.xfire.spring.remoting.XFireServletControllerAdapter.handleRequest(XFireServletControllerAdapter.java:67)

at org.codehaus.xfire.spring.remoting.XFireExporter.handleRequest(XFireExporter.java:48)

at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:44)

at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:717)

at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:658)

at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:392)

at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:357)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)

at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)

at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)

at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)

at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)

at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)

at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)

at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)

at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)

at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)

at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)

at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)

at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)

at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:108)

at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)

at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:191)

at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)

at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)

at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:90)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)

at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)

at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)

at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)

at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)

at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)

at java.lang.Thread.run(Thread.java:595)

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Marek Went added a comment -

I noticed the same error, however it does not happen, when only Stax is used.
Once DomIn/DomOutHandler is introduced (for security purpose) the same error occurs.
Temporary solution is based on 1.2.2 (code below):

org.codehaus.xfire.aegis.stax.ElementReader

public String getValue()
{
if (value == null)
{
try
{
value = root.getElementText();

while (checkHasMoreChildReaders()) {}
}
catch (XMLStreamException e)

{ throw new XFireRuntimeException("Could not read XML stream.", e); }

}

if (value == null)
value = "";

return value.trim();
}

Show
Marek Went added a comment - I noticed the same error, however it does not happen, when only Stax is used. Once DomIn/DomOutHandler is introduced (for security purpose) the same error occurs. Temporary solution is based on 1.2.2 (code below): org.codehaus.xfire.aegis.stax.ElementReader public String getValue() { if (value == null) { try { value = root.getElementText(); while (checkHasMoreChildReaders()) {} } catch (XMLStreamException e) { throw new XFireRuntimeException("Could not read XML stream.", e); } } if (value == null) value = ""; return value.trim(); }
Hide
Permalink
Renaud Bruyeron added a comment -

This is related to XFIRE-835 I guess.
The question is: should it check for null?

The stax javadoc explicitely says that XMLStreamReader.getElementText() cannot return null: it must return a String OR throw an XMLStreamException:

See http://java.sun.com/javase/6/docs/api/javax/xml/stream/XMLStreamReader.html#getElementText()

Therefore I think ElementReader is correct, and the bug lies with org.codehaus.xfire.util.stax.W3CDOMStreamReader.getElementText() which, as it currently is implemented, can return null.
W3CDOMStreamReader is inserted as the XMLStreamReader by DOMInHandler, therefore the bug is apparent whenever one uses WS-Security indeed.

The fix should be this:

org.codehaus.xfire.util.stax.W3CDOMStreamReader

public String getElementText()
throws XMLStreamException

{ getCurrentFrame().ended = true; currentEvent = END_ELEMENT; endElement(); String result = DOMUtils.getContent(content); return result != null ? result : ""; }
Show
Renaud Bruyeron added a comment - This is related to XFIRE-835 I guess. The question is: should it check for null? The stax javadoc explicitely says that XMLStreamReader.getElementText() cannot return null: it must return a String OR throw an XMLStreamException: See http://java.sun.com/javase/6/docs/api/javax/xml/stream/XMLStreamReader.html#getElementText() Therefore I think ElementReader is correct, and the bug lies with org.codehaus.xfire.util.stax.W3CDOMStreamReader.getElementText() which, as it currently is implemented, can return null. W3CDOMStreamReader is inserted as the XMLStreamReader by DOMInHandler, therefore the bug is apparent whenever one uses WS-Security indeed. The fix should be this: org.codehaus.xfire.util.stax.W3CDOMStreamReader public String getElementText() throws XMLStreamException { getCurrentFrame().ended = true; currentEvent = END_ELEMENT; endElement(); String result = DOMUtils.getContent(content); return result != null ? result : ""; }
Hide
Permalink
Renaud Bruyeron added a comment -


This patch fixes the above issue, and provides a unit test.

Show
Renaud Bruyeron added a comment - This patch fixes the above issue, and provides a unit test.
Hide
Permalink
Dan Diephouse added a comment -

Thanks everyone, this is fixed in SVN. Release coming very soon.

Show
Dan Diephouse added a comment - Thanks everyone, this is fixed in SVN. Release coming very soon.

People

Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.