Hi Thomas, FYI, Apache CXF 4.0.5 doesn't support Jetty12 yet, the upcoming CXF 4.1 will support Jetty12.
And back to this question, I believe this has been fixed by https://issues.apache.org/jira/browse/CXF-9004 And will be available in CXF 4.1 Best Regards Freeman On Wed, Jul 24, 2024 at 11:51 AM T. Papke <x...@thopap.de> wrote: > Hello CXF Teams, > > 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 >
