ScopedValue: Capturing current bindings

[Attila Kelemen]

To prove my point below, I have created very simplistic POC (ignore the
fact that it is full of poor exception handling please, and of course is
intentionally overly simplistic) that can do what I want (written in Java
20): <https://gist.github.com/kelemen/5a334e3d189f91355c4615ad94d0b6fd>

The entry point is InjectorTest, and it now properly prints "OuterValue".
So, I would slightly change my request to provide a more reasonable
implementation of my `CapturedScopes.withCurrentContext` without my
horrible abuse of STS.

Note: Ignore that I'm using my own utility `TerminableQueue`, which is just
basically a closeable channel.


Attila Kelemen <attila.kelemen85 at gmail.com> ezt írta (időpont: 2023. jún.
1., Cs, 21:06):

> 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/9a4ff6d8/attachment.htm>