Instrumentation of registered methods/script execution

[spinscale]

Hey,

I am currently reading into jactl and its sync/async execution. I am curious, if there are any means of instrumentation. On the one hand to track timing of custom functions (without calling this explicitely in a script), but on the other hand to also to enrich the result with information (for example sending a HTTP request and returning only a part of the request, while storing request and response in a context to save it for debugging purposes, but not expose it within the script). Maybe via the RuntimeState and its JaCtlContext instance? Or (mis)using the globals when calling jactlScript.eval()?

Thanks so much and have a nice week!

--Alex

[jaccomoc]

Interesting question. As you outline, there are two ways to achieve this at the moment:

1. Provide your own class that extends JactlContext and then cast the JactlContext object to your new class every time you want access to this additional information.
2. Hide your application context as a global variable in the Map of globals. If you use a name that is not a valid identifier as the key in the map (e.g. anything with '$' in it) then scripts won't be able to see it and it won't clash with any real global someone might want to use.

Do you want state that is per-invocation or shared across all script invocations that share the same JactlContext?
It would be trivial to add a method to JactlContext to allow you to add your own "ApplicationContext" instance and a getter that you could then use when needed, but obviously this would then be shared across all script invocations that use the same JactlContext which might not be what you want.

[spinscale]

Thanks for the tips, much appreciated, will play around with that. I think I probably need both states (track local execution per script, but also tracking all executions, i.e. how many scripts are running concurrently, even though I could probably wrap that around JactlScript.run() as well).

[jaccomoc]

I have committed changes that allow you to specify an "applicationContext" on the JactlContext:

MyApplicationContextClass ctx = new MyApplicationContextClass();
JactlContext jactlContext = JactlContext.create().applicationContext(ctx).build();

This can then be accessed when needed this way:

public static Object myFunction() {
  RuntimeState state = RuntimeState.getState();
  JactlContext jactlContext = state.getContext();
  MyApplicationContextClass ctx = (MyApplicationContextClass) jactlContext.getApplicationContext();
  ...
}

I have also committed changes that allow you to pass a per-invocation context object when invoking JactlScript.eval() or JactlScript.run(). There are multiple eval() and run() variations where this can be passed in. For example:

Map bindings = new HashMap();
MyInvocationContextClass invocationCtx = new MyInvocationContextClass();
JactlScript script = Jactl.compileScript(...);
Object result = script.eval(bindings, invocationCtx);

To access this context within your custom function:

public static Object myFunction() {
  RuntimeState state = RuntimeState.getState();
  MyInvocationContextClass invocationCtx = (MyInvocationContextClass) state.getInvocationContext();
  ...
}

I will release these changes with the next Jactl 2.8.0 release once I finish some other work I am in the middle of.

[jaccomoc]

I have published Jactl 2.8.0 that includes these changes.