Julian Hyde created CALCITE-5295: ------------------------------------ Summary: Read the values of plugins (such as connect string properties) from ThreadLocal fields Key: CALCITE-5295 URL: https://issues.apache.org/jira/browse/CALCITE-5295 Project: Calcite Issue Type: Bug Components: avatica Reporter: Julian Hyde
This change would allow plugin values to come from a field whose type is {{ThreadLocal}}. This will be useful in scenarios where the value of the plugin cannot be statically captured in a class, but depends upon the dynamic state of the program. This requirement often occurs during testing. Avatica allows plug-ins in several places, but most notably connection properties. For example, if I have {{httpclient_factory=com.example.MyClass#INSTANCE}} in the connect string, Avatica will look for a static field {{INSTANCE}} in class {{com.example.MyClass}} and cast it to a {{AvaticaHttpClientFactoryImpl}}. This change would extend that schema to allow instead such fields to be a {{ThreadLocal}}, as follows: {code:java} public class MyClass { public static final ThreadLocal<AvaticaHttpClientFactoryImpl> INSTANCE = new ThreadLocal<>(); } {code} The code change would be to the {{AvaticaUtilsinstantiatePlugin}} method. Other code using that utility method, such as Calcite, would inherit that functionality. We should evaluate whether this functionality poses a security risk. In opinion, it does not. To inject a malicious value into the plugin, the attacker need to already control the JVM instantiating the plugin. If anything, this reduces security risk, because a {{ThreadLocal}} allows the value to be set for a shorter duration, and only read/written from the current thread. Therefore malicious threads in the same JVM, or malicious code operating earlier or later in the same thread, cannot interfere. -- This message was sent by Atlassian Jira (v8.20.10#820010)