[
https://issues.apache.org/jira/browse/CALCITE-7082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Dennis updated CALCITE-7082:
----------------------------------
Description:
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.
was:
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.
> 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
>
> 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)
