Add DefaultConfigurationStoreDecorator to support inject callContext for DefaultConfigurationStore

[gh-yzou]

The goal of this PR is to get rid of the getCurrentContext call in DefaultConfigurationStore:

1. Remove the realmOverride capability in DefaultConfigurationStore to avoid call to getCurrentContext
2. Add DefaultConfigurationStoreDecorator that takes the injected realmContext, and provides the realmOverride capabilities.
3. revert part of change in QuarkusFeaturesConfiguration.java that is introduced by b93e97b to recover the behavior

[collado-mike]

I think this needs to be @RequestScope

[gh-yzou]

@collado-mike I am not able to mark this class as Request scoped, if I mark the class as request scoped, I encounter error like the following

 [error]: Build step io.quarkus.arc.deployment.ArcProcessor#registerBeans threw an exception: jakarta.enterprise.inject.spi.DefinitionException: A decorator must be @Dependent but org.apache.polaris.service.config.DefaultConfigurationStoreDecorator declares jakarta.enterprise.context.RequestScoped
                at io.quarkus.arc.processor.Decorators.createDecorator(Decorators.java:69)
                at io.quarkus.arc.processor.BeanDeployment.findDecorators(BeanDeployment.java:1640)

According to the doc

In CDI, decorators must have the same scope or a compatible scope as the beans they decorate. 

so if the DefaultConfigurationStore is Application scoped, the DefaultConfigurationStoreDecorator is also Application scoped.

If that is the case does that mean i can not have the callContext to be injected as part of the constructor?

[gh-yzou]

Based on the offline discussion, now we are injecting the request scoped object into the application scoped objects, and things seems working fine now

[eric-maynard]

Can we use Class.cast like in PolarisConfiguration?

[gh-yzou]

are you referring to this line here https://github.com/apache/polaris/blob/main/polaris-core/src/main/java/org/apache/polaris/core/config/PolarisConfiguration.java#L125.
For PolarisConfiguration, the type is declared on definition, for example

PolarisConfiguration<Boolean>

so it knows which type to cast to. However, for this function in ConfigurationStore, it doesn't known which type to cast to, so we will not be able to do the same thing. Or are you referring to something else?

[eric-maynard]

That's true, but why are we taking a config name here? Can we offer an overloaded version that takes a PolarisConfiguration, and there we have safe casting available?

[gh-yzou]

If we want to provide another interface for access the configuration and deprecate the old usage, i think we should do that in a separate PR. The current PR is only intended to do refactor to remove the getCurrentCallContext. I would like to keep the responsibility of this PR small and concise.