Have HandlerInterceptor being ScopedValue friendly

[Mumeii]

Hi

Since the arrival of Java 21 and the virtual threads, I'm trying to make the most use of it while working on a Proof Of Concept

My goal is to :

1. setup a classical Spring Boot MVC, REST API, project
2. then use the springthreads.virtual.enabled: true flag
3. from this point, see what I can replace in my controlers / services / etc with the use of :
   • either StructuredTaskScope
   • or ScopedValue

I've reached the third step and globally everything is going pretty smoothly.

Unfortunately, I've hit a corner case for which one, so far, I can't see any straightforward way to work around ... at least without changing Spring boot framework

This case is the following :

Setup an HandlerInterceptor that init a ScopedValue according to the received request's properties

By design I guess, the current ScopedValue API disallow accessing to Scoped Value outside of the lambas passed to its run, call or get(Supplier<? extends R> op) methods.

I.E. the beast code I've managed to produce is this one :

	@Override
	public boolean preHandle(
		final HttpServletRequest request,
		final HttpServletResponse response,
		final Object handler
	) {
		ScopedValue.where(
			SCOPED_USER_ID,
			getUserIdFromRequest( request )
		);

		// Following logging fails on a NoSuchElementException, because the previous where 
		// call has only effects on child lambdas it can trigger ... 
		log.debug( STR."Found in SCOPED_USER_ID : \{SCOPED_USER_ID.get()}" );

                return true;
	}

Which, as you can see, fails on a NoSuchElementException

Thus, the only solution I can imagine right now, with the current ScopedValue API constraints, is to find a way to have the rest of the processing chain been performed within the lambda passed to one of the previously mentionned methods :

	@Override
	public boolean preHandle(
		final HttpServletRequest request,
		final HttpServletResponse response,
		final Object handler,
		final InterceptorChain chain
	) {
		ScopedValue
			.where( SCOPED_USER_ID, getUserIdFromRequest( request ) )
			.run( () -> {

				// here it's ok :
				log.debug( STR."[INSIDE] Found SCOPED_USER_ID : \{SCOPED_USER_ID.get()}" );

				// but ... the rest of the processing chain MUST unravel within this lambda :) ...
				chain.next(); // ??
			} );

		return true;
	}

But it would necessitate to really nest the subsequent interceptor's call, and thus, to change the way Spring Boot's HandlerInterceptor works.

Maybe by introducing some kind of continuous passing style system, a bit like what is done in the Filters ?

For now on, I've decided to go for a Filter, but it don't feel right

My two other options either defeat the purpose of my POC, or the point of using a HandlerInterceptor :

1. Use a ThreadLocal 😋
2. Have ALL of my controller's endpoints fetching the request details (headers, etc ...), and perform themself the ScopedValue.where( ... ).run( ... )

I guess they are many other patterns that could help copping with this limitation.

Looking forward to see your advices regarding this problematic !