Bug 786807 - RFE: Consolidate handling of the bound variables in the CLI sessions
RFE: Consolidate handling of the bound variables in the CLI sessions
Status: NEW
Product: RHQ Project
Classification: Other
Component: CLI, Core Server (Show other bugs)
Unspecified Unspecified
medium Severity unspecified (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2012-02-02 07:57 EST by Lukas Krejci
Modified: 2012-02-06 11:42 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
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)

Note You need to log in before you can comment on or make changes to this bug.