Remove CallContext and its ThreadLocal usage

[adutra]

Now ready for review. It's a big PR, but there is no functional change here, only removals of CallContext and PolarisCallContext.

Fixes #463.

Removing CallContext is done in 2 commits that can be reviewed separately:

1. Removal of PolarisCallContext: this component is an aggregation of 3 application-scoped beans, and one request-scoped bean (the meta store session). It is "easy" to replace it by the components that are actually needed, however since it's used nearly everywhere, the blast radius is quite big. Application scoped beans are generally replaced with constructor injection, and request-scoped ones are passed through additional method arguments (except when the component is also request-scoped, in which case constructor injection is used).
2. Removal of CallContext proper. This is easier after step 1. The only issue is to revisit how PolarisCatalogHandlerWrapper closes the base catalog. The doCatalogOperation trick wasn't being done at the right level imho and could leave some catalogs unclosed in case of runtime errors.

[adutra]

Ready for review.

[snazy]

Thanks for this very nice cleanup!

[collado-mike]

This was a pretty major design decision, IMO. CallContext is an interface that allows for a lot of extension and flexibility in the runtime. This PR went from "Ready for review" to "merged" in 20 minutes with very little community feedback. There are a lot of implications for things like MDC variables in logs and other context variables that were being set at the start of the request and are no longer accessible to downstream components. I get that the thread local implementation wasn't loved by everyone, but to completely rip out the interface entirely is major.

cc: @jbonofre @adutra @dennishuo @eric-maynard @flyrain @RussellSpitzer @takidau

[snazy]

@collado-mike I think we all agree that a ThreadLocal is generally not a good choice. The issue tackled here is #463, which has been open for more than two months - nobody commented on that issue. Sure, this PR has been merged quite quickly, maybe too quick. But this PR does nothing else than what #463 describes.

We all explicitly agreed that we want to move to CDI and we all explicitly agreed that we want to move to Quarkus.

#463 also mentions that @RequestScoped injection is also a way to pass information around to the interested consumers.

The documented contract of that interface said: Stores elements associated with an individual REST request such as RealmContext, caller identity/role, authn/authz, etc. . It says nothing about being a public extension point. The factory functions of the interface imply that there is no other information.

The only implementation of that interface documents The Call context is allocated each time a new REST request is processed. It contains instances of low-level services required to process that request`.

@RequestScoped injection with request-scoped producers is a CDI conformant way to pass request-contextual information around.

It generally helps when the documentation are clear about the intent and structure of the code (package naming, module structure) supports/separates the intent and scope.

It would be good to know what exactly is no longer possible with @RequestScoped. I am sure we can find alternatives there.

CC @jbonofre @dimas-b @adutra @takidau @dennishuo @eric-maynard @flyrain @RussellSpitzer

[collado-mike]

@snazy I think two or three people have expressed unhappiness with the ThreadLocal solution, but I think most of us have not expressed an opinion. I don’t have a strong opinion for or against TLs - I said as much in the PR that introduced `@RealmScoped` (which, BTW, has also been unceremoniously deleted with no notice). But to say that this PR does nothing more than what was stated in #463 is strictly untrue. Removing the CallContext interface and the resolver is akin to cutting off an arm because there was a minor infection. _All_ interfaces in this project are potential extension points. _Especially_ ones that are explicitly set in the project configuration. We all agreed to use CDI, but that does not grant license to start removing interfaces and APIs without any community feedback at all. What CDI has to do with the existence of the CallContext interface is beyond me. CDI is intended to allow for easier extension by allowing installations to replace default implementations with new ones. The whole point is to support extension. Whether or not there are alternative solutions to do what the CallContext interface allowed for is not the topic of discussion. Nobody is asking you to help solve their problems. The concern is the lack of feedback requested or even considered when making wide sweeping changes in a project that is supposed to be the joint efforts of a community. There is a process to propose interface deprecation and removal. This process exists to allow the community to start using replacements over time but this process and the impact on users in this community was completely ignored in this PR

[RussellSpitzer]

This needs to be reverted and discussed.

[eric-maynard]

Why was this removed?

[adutra]

Because 1) it relies on thread locals and 2) it can be easily inlined: it starts from a CallContext, then navigates the object graph until it gets to a PolarisConfigurationStore and calls getConfiguration().

The whole method is thus generally replaceable by:

@Inject PolarisConfigurationStore configurationStore;

public T loadConfig(@Nullable RealmId realmId, PolarisConfiguration<T> configuration) {
    return configurationStore.getConfiguration(realmId, configuration);
}

[eric-maynard]

It doesn't necessarily have to rely on thread-local, couldn't the callcontext just have been injected in?

The caller won't always have a RealmId available

[adutra]

Indeed, the realmId parameter is nullable since not every call site has access to that. Without it, we always fetch the default config without considering any realm overrides.

But anyways this is going to be reverted, so I don't see the point of keeping the discussion going on.

[dennishuo]

One major element of this refactor that ended up potentially counterproductive to portability is that previously, the use of callCtx.getMetaStore() -> PolarisMetaStoreSession insulated the business-logic layer from needing to know about PolarisMetaStoreSession at all when interfacing with PolarisMetaStoreManagerImpl.

Since we want to better contain the existence of PolarisMetaStoreSession even more as a potentially db-specific implementation detail, we probably want at least some kind of other wrapper that represents RequestScoped persistence context that is also agnostic to specific persistence impls. If we do reintroduce @RequestScoped CallContext we can document this aspect as one of the purposes of the CallContext.

[snazy]

Since we want to better contain the existence of PolarisMetaStoreSession even more as a potentially db-specific implementation detail, we probably want at least some kind of other wrapper that represents RequestScoped persistence context that is also agnostic to specific persistence impls. If we do reintroduce @RequestScoped CallContext we can document this aspect as one of the purposes of the CallContext.

Just do this?

@Inject PolarisMetaStoreSession foo;