Bug 786807

Summary: RFE: Consolidate handling of the bound variables in the CLI sessions
Product: [Other] RHQ Project Reporter: Lukas Krejci <lkrejci>
Component: CLI, Core ServerAssignee: RHQ Project Maintainer <rhq-maint>
Status: NEW --- QA Contact: Mike Foley <mfoley>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 4.3CC: hrupp
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Lukas Krejci 2012-02-02 07:57:14 EST
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.
Comment 1 Mike Foley 2012-02-06 11:42:39 EST
per triage (loleary, ccrouch, asantos, mfoley)