Currently, the scripting environment for RHQ is only half-abstracted - the creation of the ScriptEngines is encapsulated and the intricacies of the standard bound variables setup is hidden from the user.

However, further handling of the ScriptContext (i.e. the bound variables (the standard ones + the user defined ones) and the std in/out/err) is not. This becomes particularly error-prone when the variables in the context need to react on user logging in or out (which they do, see bug 785773).

Having a "RhqScriptContext" that would encapsulate all of the above and hide the complexity from the callers would enable us to have a clear separation between a script engine and its context (as there should be per the API of javax.script).

Having this clear separation, it would be beneficial to implement, only on server-side, a script engine pool accessible from any server-side code that could be used to obtain script engines that would be used to execute scripted actions (currently, because the distinction between the engine and the context is kind of blurred from the RHQ point of view, this would be not so easy (or at least it would be error-prone)). The individual callers of these pooled script engines would manage the lifecycle of the RhqScriptContext and would only use the script engines for the execution itself.

This would make integrating scripting in various server-side areas super simple, which would then enable us to easily add support for scripting in areas where we currently don't even think about it.