Hello CXF Team, we have observed an ERROR constellation in combination with CXF (4.0.5), a JAX-WS async post response, the cxf message logger enabled and jetty (12) as server implementation.
If a jax-ws (async response) message is received we see a NullPointer in jetty, when the LoggingInInterceptor try to read the subject from the current request. Originally i thought this might be an issue with jetty, so i have created https://github.com/jetty/jetty.project/issues/12080, but the discussion seems to indicate, that CXF access the HttpServletRequest object after jetty already complete the request. Current workaround: If we simply disable the CXF logging interceptor, everythings works fine. Here the excerpt of the stacktrace: > > 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] > > I try to analyse a bit the situation: In case of a JAX-WS async Post Response message, process the Soap message in a separate thread ( https://github.com/apache/cxf/blob/main/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/impl/InternalContextUtils.java#L317) to not block the request. In case a LoggingInInterceptor is configured, the interceptor access the original http request to get the subject from: https://github.com/apache/cxf/blob/main/rt/features/logging/src/main/java/org/apache/cxf/ext/logging/event/DefaultLogEventMapper.java#L117 This handling now causes e.g. in Jetty that a NullPointer is raised, because the httpServletRequest is already fully processed and no longer available. My understanding: CXF shall not access HttpServletRequest for a async response processing. >From my understanding: Option A: Remove the whole SecurityContext similar to the PathInfo from the message: https://github.com/apache/cxf/blob/main/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/impl/InternalContextUtils.java#L309 Option B: Prevent accessing the getUserPrincipal from the http Request if a async Post Response message is processed. (not quite sure what might be a good indicator) Option C: Create a kind of copy of the user Principal before starting the new thread to retain the subject details. I am interested to hear from the CXF team if my assumption that this looks like a CXF failure case is correct and if one of the options (or maybe others) might be the solution. Thank you, Best regards, Thomas
