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 :
  4. either StructuredTaskScope
  5. 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 !

Comment From: bclozel

Thanks for reaching out. You are right, HandlerInterceptor is meant to act at different stages of the request handling and provide decision points.

HandlerInterceptor is basically similar to a Servlet Filter, but in contrast to the latter it just allows custom pre-processing with the option of prohibiting the execution of the handler itself, and custom post-processing. Filters are more powerful, for example they allow for exchanging the request and response objects that are handed down the chain. Note that a filter gets configured in web. xml, a HandlerInterceptor in the application context.

In that sense, the Servlet Filter contract is much more appropriate for the use case you're showing.

Right now scoped values are in third preview for Java 23 and I don't think we should introduce new contracts until we have a clearer vision and concrete use cases for this.