<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Can’t you just use the runWhere at the top to set the context and then use the open syntax on the context as I described? The context has the span , security and request context information. </div><div dir="ltr"><br></div><div dir="ltr">The getTracingContext() that used to read from a TL instead loads from the scoped value. It should be less than a dozen lines of code to change in the library. </div><div dir="ltr"><br><blockquote type="cite">On Jun 11, 2024, at 5:33 AM, Marcin Grzejszczak <marcin.grzejszczak@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>> 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?</div><div><br></div><div>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. <br></div><div><br></div><div>> 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.</div><div><br></div><div>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. <br></div><div><br></div><div>> 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/</div><div><br></div><div>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:</div><div><br></div><div>ScopedValue.runWhere(scopedValue, someValue, () -> {<br> codeToRun();<br> });</div><div><br></div><div>Proposed approach:</div><div><br>try(Scope scope = ScopedValue.openScope(scopedValue, someValue)) {<br></div><div> codeToRun();<br></div><div>}</div><div><br></div><div>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.<br></div><div><br></div><div>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?</div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Pozdrawiam / Best regards,</div><div>Marcin Grzejszczak</div><div><br><div><a href="https://marcin.grzejszczak.pl" target="_blank">https://marcin.grzejszczak.pl</a></div><div><a href="https://toomuchcoding.com" target="_blank">https://toomuchcoding.com</a></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">wt., 11 cze 2024 o 09:07 Andrew Haley <<a href="mailto:aph-open@littlepinkcloud.com">aph-open@littlepinkcloud.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/10/24 18:34, Robert Engels wrote:<br>
> so the scoped value is not immutable, only the reference is constant.<br>
> <br>
> This doesn’t match the JEP or I am misunderstanding it.<br>
<br>
Think of a scoped value as being like a final local reference variable. It is<br>
immutable, clearly, but its referent is not.<br>
<br>
-- <br>
Andrew Haley (he/him)<br>
Java Platform Lead Engineer<br>
Red Hat UK Ltd. <<a href="https://www.redhat.com" rel="noreferrer" target="_blank">https://www.redhat.com</a>><br>
<a href="https://keybase.io/andrewhaley" rel="noreferrer" target="_blank">https://keybase.io/andrewhaley</a><br>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671<br>
<br>
</blockquote></div>
</div></blockquote></body></html>