Chris Dennis created CALCITE-7082:
-------------------------------------
Summary: 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
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)
