ScopedValue.runWhere not returning scope

[Marcin Grzejszczak]

> I am struggling to understand the concern. If you have a TL based
solution just stick with it. If the people are changing their code to use
VT then they are probably redesigning anyway - e.g. removing any async.

Let me quote one of my previous replies: "I mean if there's no distinction
in terms of performance between Scoped Values and Thread Locals then we
should just need to ensure that there's an interop between Thread Locals
and Scoped Values and current implementations could stay on Thread Locals.
But I thought that the very idea is to use Scoped Values preferably with
Virtual Threads to have best performance in comparison to using Thread
Locals. Maybe I made a mistake in this assumption?".

> If they are redesigning they can use an interceptor based solution that
is designed for scoped variables.

That would require a lot of libraries to redesign their API. I'm not saying
this is a bad thing but that might be a lot of work on many different
projects. Also some libraries will migrate, some won't so there needs to be
an interop between TL and SV.

Pozdrawiam / Best regards,
Marcin Grzejszczak

https://marcin.grzejszczak.pl
https://toomuchcoding.com


pt., 7 cze 2024 o 15:11 robert engels <robaho at icloud.com> napisał(a):

> I am struggling to understand the concern. If you have a TL based solution
> just stick with it. If the people are changing their code to use VT then
> they are probably redesigning anyway - e.g. removing any async.
>
> If they are redesigning they can use an interceptor based solution that is
> designed for scoped variables.
>
> On Jun 7, 2024, at 10:03 AM, Marcin Grzejszczak <
> marcin.grzejszczak at gmail.com> wrote:
>
> 
> > In AspectJ`s terms, interceptors such as these are equivalent to before
> and after advice.
>
> Correct.
>
> > To enable something like a ScopedValueInterceptor, it seems to me
> sufficient to extend this scheme to include around advice. The handler of
> AroundInterceptors would pass a proceed object to the around advice.
> ScopedValueAroundInterceptor would do whatever it wants to do, call
> scopedValue.runWhere, then call proceed inside that scope.
>
> Agreed. For this scenario preferably one could use the around advice.
> That's in the case of an ideal solution where all projects are green
> fields. But we're not in such a state.
>
> > If a design like this was deemed overkill before, perhaps its time has
> arrived.
>
> I wonder if the solution that the library maintainers should be required
> to migrate to a new design is the proper one. I've only listed 8 projects
> that Micrometer Observation instruments but I'm pretty sure that there are
> more. I wonder if such an ask to redesign the API wouldn't be an overkill?
>
> Pozdrawiam / Best regards,
> Marcin Grzejszczak
>
> https://marcin.grzejszczak.pl
> https://toomuchcoding.com
>
>
> pt., 7 cze 2024 o 14:52 Pedro Lamarão <pedro.lamarao at prodist.com.br>
> napisał(a):
>
>> Em sex., 7 de jun. de 2024 às 10:05, Marcin Grzejszczak <
>> marcin.grzejszczak at gmail.com> escreveu:
>>
>>
>>> > Can you explain that a little more? Why can't isolated functionality
>>> be added without separate before and after logic?
>>>
>>> I mentioned that above but I'll try to rephrase it. There are already
>>> solutions such as Apache CXF [1], Apache Commons for Http client [2],
>>> Datasource Proxy [3], Jersey [4][5], R2DbcProxy [6] that work with such
>>> interceptors. All that code would have to be rewritten. I'm not saying that
>>> this is not feasible but let's be realistic. Also if all of those libraries
>>> wouldn't rewrite their code then distributed tracing would be broken. If
>>> one service is not working then instead of one correlation you will get two
>>> or more.
>>>
>>
>> In AspectJ`s terms, interceptors such as these are equivalent to before
>> and after advice.
>> To enable something like a ScopedValueInterceptor, it seems to me
>> sufficient to extend this scheme to include around advices.
>> The handler of AroundInterceptors would pass a proceed object to the
>> around advice.
>> ScopedValueAroundInterceptor would do whatever it wants to do, call
>> scopedValue.runWhere, then call proceed inside that scope.
>> If a design like this was deemed overkill before, perhaps its time has
>> arrived.
>>
>> --
>> Pedro Lamarão
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240607/9d4e41bd/attachment.htm>