Blinky Config: Module for managing configurations

[VijayKrishna]

Premise

There has been a long-standing need to provide a way of specifying verbose configurations for a client java-agent, like Blinky Core, without changing the client's source code.

Configurations of a java-agent that are passed as cmdline arguments, like for Blinky Core, are too verbose to be specified on the command-line. A typical example of this is specifying+changing the classes to be excluded or (forcibly) included as targets of instrumentation. As such, instead of changing them on the java-agent's input arguments, Blinky Core has traditionally maintained+changed the values of such configurable lists/flags/properties in the Deputy.java source file.

Changing and managing configurable properties directly in Java source files is undesirable, as it would give the impression that these config-values are somehow integral to the implementation at hand, which they are not, and often cluter the project revision history.

Blinky Config

The goal with this module will be to provide a way specify and manage configurations for the various analysis modules in the Blinky infrastructure, starting with Blinky Core (for now).

Currrent mode-of-operations: As mentioned above the current mode of specifying configuration values is to do so by storing them in Java source files that are part of the compiled build, and changing the configurable properties in the source files directly.

Desired Change: Provide a way to store the config-values in a config file that is not a Java source code file.
Corollary: As such, we still want the actual configuration-values for the config'able properties of interest to be compiled into bytecode classfiles that are available to the rest of the code in the build-output.

Here is a list of features that will necessarily be a part of this change:

• This sub-module will enable the specification and modification of configuration values in a Yaml file, and not a Java source file.
• The sub-module will accept three inputs: (a) the Yaml file with the configuration values; (b) the classfile to which the configurable values will be compiled to; (c) the location of the compiled output where classfile is stored.
• This sub-module will compile the values in the Yaml config-file to generate/modifiy appropriate bytecode in the input Java bytecode classfile that can be used by the client java-agent's code to access user-provided configurations.
  • The idea behind converting a config file to a Java bytecode classfile is to give the analysis modules direct access to the configs through the class loader, thus avoiding the overhead in managing config-specific resource streams (for the client module, like Blinky core).
  • This will also ensure that parts of the configurations are bundled with the final Jar files of the client modules/projects.
  • Converting config files to classfiles implies that the configurations specified this way will be decided at compile-time; as such such configurations would be pre-defined and stable during runtime, i.e., they would not be configurable declaratively after the client module is packaged.
• These configurations will compiled to bytecode in a manner that will allow for overrides on the command line of the client module.