Proposal: Debug and experiment flags

[gbrail]

We're a bit stuck on Reflect and Proxy support because it isn't feature-complete, and we want to have some sort of "experiment" capability so that we can enable it while we complete the implementation, rather than relying on a huge feature branch. However, our current configuration mechanism, which is the feature flags on the Context class, is a bit cumbersome, especially for enabling something that might be temporary in nature, like an experimental feature that will eventually "graduate."

As a secondary problem, we have a bunch of hard-coded static boolean "debug" flags in the product, which are currently only enabled by changing the code. Rhino doesn't need a complicated "debug framework" like an enterprise Java app, but it'd be nice to be able to enable and disable this debugging more easily.

So, I'm proposing that we add a few system properties to Rhino, and also an environment variable:

Variable	Type	Meaning
rhino.experiments	System property	Enables experimental features. Value is a comma-separated list of feature names.
rhino.debug	System property	Enables debugging. Value is a comma-separated list of things to debug.
RHINO_DEBUG	Environment variable	Same as "rhino.debug". Values will be combined and the "or" of both values will be used to enable debugging.

All of these properties will work by scanning the comma-separated list of either experiments to enable, or debug flags to enable, and if the value is in the list, it'll enable that experiment or debug flags. Unknown entries in the list will be ignored.

The idea here, at least for experiments, is that when an experiment runs its course and can be "graduated," we will just retire the flag.

So, for example, setting:

rhino.experiments=proxy,foobar

Enables the experiments named "proxy" and "foobar". If there is no feature named "foobar," then that part is just ignored, and the "proxy" feature is enabled.

Finally, I think that we should also support setting debug flags via environment variable, because depending on how we're running Rhino, it may be easier to set an environment variable than a system property.

[rPraml]

I would suggest, that we use different strategies, where to load properties:

Let's create a RhinoConfiguration class, that tries to load properties from different places:

• rhino.config from classpath
• rhino.config from current directory
• read System.getProperties() and take everything starting with "rhino."
• maybe read also environment.

Why do I want this: (especially reading config from classpath)

If you have a web application, you bundle your rhino.jar typically in your war file.
This war file runs in an application server. (e.g. Tomcat)
You can provide YOUR configuration in the classpath of your war file
the server admin needs not to edit around in server-config etc.
different war files in the same container can run rhino in different configs

Other frameworks like logback do a similar lookup strategy

[rPraml]

I think, with RhinoConfig, is easy to hide new features behind a flag and this issue may be closed. (maybe we can discuss about some naming conventions)
See also the suggestions in rhino/rhino.github.io#4
@p-bakker @gbrail FYI