ScopedValue.runWhere not returning scope

[Marcin Grzejszczak]

> This benefit of having ScopedValues "plug and play" into some interceptor
architecture would come at the cost of removing the structural guarantee
that ScopedValues scopes are entered and left correctly. That guarantee
would be degraded to a user requirement, which the platform would *not* be
allowed to assume at the risk of undefined behaviour -- what happens if a
super scope is closed before a sub scope?

I've already described that in one of the previous answers. It's already a
problem in tools like Brave or OpenTelemetry. We give users the option to
operate on scopes and they indeed may mess it up. But users rarely need to
actually use that API, typically they do try with resources and we very
rarely have any issues reported for that matter. Again, "with great power
comes great responsibility", users normally wouldn't be using that API,
rather library instrumentors would. Can they break sth? Of course they can,
but then they just fix it. I don't understand the problem here. On the
other hand we (library creators) will be asked by the users about "our
support of Scoped Values" and we will need to rewrite everything in 2
places - our libraries plus the instrumented libraries to add that support.

> You can rewrite the above without using TL by creating the TracingContext
instance in the top level, and passing it as a parameter to every function
below. This is how Go handles this.

Yes, of course I can rewrite everything to make things work with SV. My ask
is not to require the library instrumentors to change their current
implementation. I've been working with tracing libraries (Spring Cloud
Sleuth, OpenZipkin Brave, Micrometer Tracing, OpenTelemetry) for the past
decade and it's not a trivial task not only from the point of view of
creating a tracing library but also adding instrumentations in other
projects.

> So why not produce an example of how it would be used? As far as I can
see, your proposal fails to ensure the property in the case I posted/

I've created samples at the very beginning with the before and after
interceptor. I obviously know that I could rewrite the interceptor to
become an around one but my point is that it's not an ideal solution to
require instrumentors to rewrite everything. Also I still see this whole
discussion as having two ways of doing the same thing. Current approach:

ScopedValue.runWhere(scopedValue, someValue, () -> {
      codeToRun();
    });

Proposed approach:

try(Scope scope = ScopedValue.openScope(scopedValue, someValue)) {
  codeToRun();
}

I understand that in the proposed approach one can mess things up, I really
do. But library instrumentors and tracing library creators would benefit
from that sort of API.

Also I've asked a different question... What if the users want to leverage
the ScopedValues to get the current span information (or current principal
from security point of view) but also they are using TL based libraries?
How would the interop look like? Let's assume that they put into the
current scope a span that they want to have within that scope, we would
need all the tracer libraries (and security components and others that use
the same mechanism) to be ScopeValue aware. Would they first try to read SV
and then if that's not there a TL? They would need to most likely read SV
and populate TL if the SV value is present so that other components that
still rely on TL would work. That would have to also work the other way
round, if a TL based library sets a value (e.g. span) then maybe the
ScopedValue should be created with a scope for that new value?

Pozdrawiam / Best regards,
Marcin Grzejszczak

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


wt., 11 cze 2024 o 09:07 Andrew Haley <aph-open at littlepinkcloud.com>
napisał(a):

> On 6/10/24 18:34, Robert Engels wrote:
> > so the scoped value is not immutable, only the reference is constant.
> >
> > This doesn’t match the JEP or I am misunderstanding it.
>
> Think of a scoped value as being like a final local reference variable. It
> is
> immutable, clearly, but its referent is not.
>
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240611/362adc61/attachment-0001.htm>