ScopedValue: Capturing current bindings

[Attila Kelemen]

David Lloyd <david.lloyd at redhat.com> ezt írta (időpont: 2023. jún. 1., Cs,
20:35):

> What I for one do *not* want is for someone other than myself to decide
> what "properly scoped" means for a given piece of code that I write, nor do
> I want behavior outside what is strictly required for implementing locally
> scoped variables.
>
>
I meant very little by "properly scoped", only that scopes organize into a
single tree (assuming an implicit scope for `main`), and all code runs in a
scope. You are still in complete control of how to create scope, and what
scope to use.


> Let me give a real-world example of why this is a problem. We have a
> security identity framework where our identities are associated in the
> manner of ScopedValue. A user may query what identity is currently active,
> and the user may execute some block of code with a new active identity.
> However, we found early on that some existing frameworks - like the Servlet
> specification for example - do not allow us to interpose a call like
> identity.runAs(() -> { ... }) in the midst of handling a request, for right
> or for wrong. So instead what we offer is a way to lexically scope a
> "flexible identity association". The identity may be changed within the
> scope of an operation, but the flexible association does not escape the
> bounds of the lexical scope that it was run under.
>
>
In my DI framework example (of course it doesn't have to be a DI framework,
the point is the lazy factory), you are currently having a different
security issue. That is, at top level I bound the factory, and then lazily
somewhere down (possibly in an authenticated scope) you could be running
(unknowingly) the factory with credentials, and that is most certainly not
something you want.

As for your concern: You are already screwed :) In fact, I have realized
that I have a (horrible) way to implement what I want with
`StructuredTaskScope`, because when I'm binding the factory in my example,
I can open a new STS, fork a task immediately which will just stop and wait
and when down the line the "resource" is requested, I will just let the
task go, and channel back the result. Actually, I'm very glad you are
making these criticisms, because it made me realize a better way to imagine
what I want (functionality wise it would be the same). That is, my
`CapturedScopedValueContext.inContext` method should be imagined as running
a task in parallel, but the parallel task is being executed in a higher
level scope. So, even if nothing else comes out of it, I'm already glad to
have written this, and that you responded :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230601/827ec1f5/attachment-0001.htm>