[
https://issues.apache.org/jira/browse/CALCITE-7082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-7082:
------------------------------------
Labels: pull-request-available (was: )
> CalciteSystemProperty saffron.properties lookup is unusual
> ----------------------------------------------------------
>
> Key: CALCITE-7082
> URL: https://issues.apache.org/jira/browse/CALCITE-7082
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Chris Dennis
> Priority: Minor
> Labels: pull-request-available
>
> The CalciteSystemProperty property loading logic implements an unusual
> priority system. I'm not sure if this is accidental or not. The current
> implemented lookup procedure is:
> # If there is a ThreadContextClassLoader set: look for a
> `saffron.properties` resource via it. If found merge with the system
> properties and move ahead. _If no resource is found just use the system
> properties._
> # If no ThreadContextClassLoader is set: look for a `saffron.properties`
> resource via the loader of CalciteSystemProperty. If found merge with the
> system properties and move ahead. If no resource is found just use the system
> properties.
> What this means is if you have a saffron.properties resource visible through
> the Calcite loader, but someone has set a TCCL for unrelated reasons, then it
> breaks the intended lookup.
> In my specific case I'm dealing with a library thats loading Calcite in an
> isolated classloader with custom saffron.properties settings... but then any
> TCCL usage by a user breaks the saffron.properties lookup.
> I'm proposing we switch to either:
> # a model where saffron.properties is loaded from TCCL first, but delegates
> to the Calcite loader if no resource is found.
> # a model where properties are loaded from both, and then merged together,
> in preference order: System, TCCL, Calcite Loader.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
