Possible NPE in RequestContextFilter when other Filters prioritized

[muhammetaltindal]

Explanation:

The RequestContextFilter has a no priority set, so the default priority of 5000 (Priorities.USER) is taken here.

If there are any other Filters, let's assume a custom AuthorizationFilter which will have a priority of 1, and that filter is declining a request and responds already, then the ContainerResponseFilter#filter implementation of RequestContextFilter causes the NPE in the SpringAttributeController#resetAttributes anonymous implementation, since the SpringAttributeController#setAttributes was called because the higher prioritized AuthorizationFilter has already responded.

Expected behavior

The expectation is that if nothing was set initially, then the ContainerResponseFilter implementation of RequestContextFilter should cause no exceptions and do nothing.

Actual behavior

Right now, a NullPointerException occurs as described in the situation above:

java.lang.NullPointerException: Cannot invoke "org.springframework.web.context.request.AbstractRequestAttributes.requestCompleted()" because "attributes" is null
	org.glassfish.jersey.server.spring.scope.RequestContextFilter$2.resetAttributes(RequestContextFilter.java:101)
	org.glassfish.jersey.server.spring.scope.RequestContextFilter.filter(RequestContextFilter.java:114)
	org.glassfish.jersey.server.ContainerFilteringStage$ResponseFilterStage.apply(ContainerFilteringStage.java:172)
	org.glassfish.jersey.server.ContainerFilteringStage$ResponseFilterStage.apply(ContainerFilteringStage.java:139)
	org.glassfish.jersey.process.internal.Stages.process(Stages.java:147)
	org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:385)
...

Possible workaround

This may be worked around by creating an own RequestContextFilter and then instantiate the actual RequestContextFilter from jersey-spring6 extension as a delegate and define the highest priority (1 for example).

However, the jersey-spring6 in version 3.1.6 is a multi-release jar, and when doing the workaround above, then IntelliJ can't compile because it confuses the different versions within the same jar, and takes the wrong one, although java 17 is used. Not sure if this is an issue from the IDE perspective or because multi-release jar is not as expected?

To circumvent the issue with the multi-release jar, one could just copy the class files from META-INF/versions/17/org/glassfish/jersey/server/spring/scope in an own package and define the priority on your own, or patch the ContainerResponseFilter implementation to not cause the NPE.

Affected artifact:

org.glassfish.jersey.ext:jersey-spring6:3.16