Ladislav Thon

I don't think there's an issue with that. (Besides the name. We need a good name.) If you think that's a reasonable way forward, I'll try to figure something out.

For an unexplainable reason, I'm quite fond of the idea of `SyntheticInjectionPoint` _extending_ `InjectionPoint` :-)

I was thinking it would be quite acceptable to do a small breaking change and say that `InjectionPoint.getMember()` may return `null` in case the bean declaring the injection point is...

Just FYI, my force-pushes recently didn't change anything in this PR, I just rebased on latest `main`.

I promised to share a slide deck that I have that illustrates known troubles with request context propagation. Here goes: https://docs.google.com/presentation/d/1EaMdHY9NkIGn1qx3KYyk9hjCnAfLGoer7n3HN-GgoTc/edit

Very nice summary, thanks! Ad item 3: the request context in Weld is not always just a thread-local `Map`. In HTTP servlet scenarios, it's a wrapper around `HttpServletRequest`, storing contextual...

Yes, that would solve _one_ of the problems, partially (only for cases where structured concurrency is a good fit, which should be like 90%, but definitely isn't 100%).

More broadly, the request scope (and the concept of normal scopes, in general) was designed for the _thread per request_ paradigm. It was in the days when Java EE prohibited...

All commands that are not read-only are routed to master nodes already, so _that_ is not an issue. I noticed a while ago that we transparently handle `ASKED` redirections, but...

You might want to debug `CommandImpl.isReadOnly()`, which determines if the command is actually treated as read-only, based on argument values first.