NullPointerException from call to ServletApiRequest#getUserPrincipal with Jetty

[Thopap]

Jetty version(s) 12.0.11

Jetty Environment jetty ee10

Java version/vendor Temurin-21.0.2+13

OS type/version Windows 11

Description We experience an NullPointerException when running Async Soap Transactions with CXF, especially when CXF Logging is enabled and the getUserPrincipal is called by CXF. The issue looks quiet similar to #10498, but we use the most recent version of jetty and we also do not use websocket.

Here the stacktrace that we see when CXF background thread.

java.lang.NullPointerException: Cannot invoke "org.eclipse.jetty.server.Request.getAttribute(String)" because "request" is null at org.eclipse.jetty.server.Request.getAuthenticationState(Request.java:983) ~[jetty-server-12.0.11.jar:12.0.11] at org.eclipse.jetty.security.AuthenticationState.getAuthenticationState(AuthenticationState.java:45) ~[jetty-security-12.0.11.jar:12.0.11] at org.eclipse.jetty.ee10.servlet.ServletApiRequest.getAuthentication(ServletApiRequest.java:254) ~[jetty-ee10-servlet-12.0.11.jar:12.0.11] at org.eclipse.jetty.ee10.servlet.ServletApiRequest.getUndeferredAuthentication(ServletApiRequest.java:259) ~[jetty-ee10-servlet-12.0.11.jar:12.0.11] at org.eclipse.jetty.ee10.servlet.ServletApiRequest.getUserPrincipal(ServletApiRequest.java:478) ~[jetty-ee10-servlet-12.0.11.jar:12.0.11] at org.apache.cxf.transport.http.AbstractHTTPDestination$2.getUserPrincipal(AbstractHTTPDestination.java:397) ~[cxf-rt-transports-http-4.0.5.jar:4.0.5] at org.apache.cxf.ext.logging.event.DefaultLogEventMapper.getPrincipal(DefaultLogEventMapper.java:117) ~[cxf-rt-features-logging-4.0.5.jar:4.0.5] at org.apache.cxf.ext.logging.event.DefaultLogEventMapper.map(DefaultLogEventMapper.java:104) ~[cxf-rt-features-logging-4.0.5.jar:4.0.5] at org.apache.cxf.ext.logging.LoggingInInterceptor.handleMessage(LoggingInInterceptor.java:93) ~[cxf-rt-features-logging-4.0.5.jar:4.0.5] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) ~[cxf-core-4.0.5.jar:4.0.5] at org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:277) ~[cxf-core-4.0.5.jar:4.0.5] at org.apache.cxf.ws.addressing.impl.InternalContextUtils$1.run(InternalContextUtils.java:319) ~[cxf-rt-ws-addr-4.0.5.jar:4.0.5] at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:413) ~[cxf-core-4.0.5.jar:4.0.5] at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?] at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?] at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:346) ~[cxf-core-4.0.5.jar:4.0.5] at java.base/java.lang.Thread.run(Thread.java:1583) [?:?]

How to reproduce? Thats the tricky part. It's currently reproducablible with a slightly complex integration test with the combination of CXF, CXF-logging enabled, and jetty. Hopefully a failure can be identified in the provided stacktrace.

[joakime]

Cannot invoke "org.eclipse.jetty.server.Request.getAttribute(String)" because "request" is null

That points at use of the HttpServletRequest after the request has been fully processed and has reached a point where it has been recycled, rendering the Request unavailable for further work.

[Thopap]

If i understand the CXF handling correctly for async jax-ws (soap) responses, they are processed in a separate thread when received, since the caller do not expect a response. So you are right, looks like the original servlet request is already processed.

The question here is, if the behavior for such a case is defined in some way? is the NPE a valid response for such a state? I assume CXF must prevent accessing the HttpServletRequest for such situations.

[joakime]

The question here is, if the behavior for such a case is defined in some way? is the NPE a valid response for such a state?

This is a completely undefined area of the various specs. All manners of odd and bad behavior exist in this space.

I assume CXF must prevent accessing the HttpServletRequest for such situations.

This is what must happen. CXF isn't the only one dealing with this kind of issue btw.

See Spring's issue for this as well, (the title is misleading, it happens on many containers, not just Jetty, you can see that from the comments/reports in it)

• https://github.com/spring-projects/spring-security/issues/9175

[Thopap]

Thank you.

I have placed the question in the cxf channel (https://lists.apache.org/thread/ws20fg0xz5sn188k2p28o72sfp33zxy9) and it look like it is already planned to be fixed with their next release https://issues.apache.org/jira/browse/CXF-9004