Groovy make methods visible from one script to another - java

I have a script with utility methods I would like to access from my other script.
I load my script like this in my java code
static {
GroovyShell shell = new GroovyShell();
//This is the script that has the utility
groovyUtils = shell.parse(new InputStreamReader(MyJavaClass.class.getResourceAsStream("scripts/json/MyUtils.groovy")));
//This is the script that does thing
groovyScript = shell.parse(new InputStreamReader(MyJavaClass.class.getResourceAsStream("scripts/json/MyScript.groovy")));
}
I would like to expose the methods from MyUtils.groovy to be usable in MyScript.groovy (and also other scripts in the future)

There is a number of ways how you can achieve this.
You're talking about methods, so I guess you have a class in MyUtils.groovy.
In this case you can specify a Binding, e.g.
def myUtils = new MyUtils()
def binding= new Binding([ method1: myUtils.&method1 ])
def shell= new GroovyShell(binding)
shell.evaluate(new File("scripts/json/MyScript.groovy"))
In the above you can reference method1 in your script and you will end up invoking it on myUtils instance.
Another solution is to specify a script base-class, e.g.
def configuration = new CompilerConfiguration()
configuration.setScriptBaseClass('MyUtils.groovy')
def shell = new GroovyShell(this.class.classLoader, new Binding(), configuration)
MyUtils class must extend Script then; all its methods are available in scripts you parse using shell.
There are essentially multiple ways how to embed / run Groovy. These are quite often discussed while designing DSLs. You can take a look e.g. here, if you haven't searched for it before.

Related

Better way to load custom DSL config from Java application

For a Java application, is there a better way to support configuration files based on a custom DSL (such as relying on Groovy or Kotlin) than using JSR223 ScriptEngine's eval or compile methods?
Loading script's content as String and then using it in a code like that is working but maybe there are better and more efficient ways of doing it.
String type = "groovy"; // or "kts"
String script = "..."; // code of DSL script
ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByExtension(type);
Compilable compiler = (Compilable) engine;
CompiledScript code = compiler.compile(script);
Object result = code.eval();
Actually as JMeter, you should save your compiled script in cache and use it:
CompiledScript compiledScript = compiledScriptsCache.get(newCacheKey);
Same for ScriptEngine
You can share a ScriptEngine and CompiledScript objects across threads. They are threadsafe. Actually, you should share them, as a single engine instance is a holder for a class cache and for JavaScript objects' hidden classes, so by having only one you cut down on repeated compilation.

Run tests programmatically with junit5

(disclaimer: I know there is plenty of good tutorial about it, but I cant find exactly what I want).
I am building a Java app that test a Docker infrastructure every X minutes, it parse docker-compose and test every container with dedicated tester class. I want to use junit as a framework (to generate report etc...).
The test part is running via a picocli command.
I tried to use org.junit.platform.launcher.Launcher but it seems we cant specify class instance only selectors patterns:
LauncherDiscoveryRequest request = LauncherDiscoveryRequestBuilder.request()
.selectors(
selectPackage("X.tester.runners"),
selectClass("MyTestFactory")
)
.build();
whereas I have already the class instance to test (via Google Guice), I would like something:
class Test {
#Inject stuff....
void execute() {
Assertions.assertEquals(....);
}
}
List tests = Arrays.asList(injector.getInstance(Test.class).setPath("toto.yml")); // From Files.walk
new JupiterTestEngine().execute(tests);

How do I pass java objects to an embedded JRuby container in a servlet enviornment?

I need a way to execute a jruby script in a multi-threaded environment, where each execution of the script is passed a different java object.
Currently, I am able to run self-contained scripts using code like:
public class Executor {
public Executor() {
this.container = new ScriptingContainer(LocalContextScope.THREADSAFE, LocalVariableBehavior.TRANSIENT);
this.evalUnit = this.container.parse(getScriptContent());
}
public execute(HttpServletRequest request) {
this.evalUnit.run()
}
}
Which appears to perform well since the ruby script is parsed once in the constructor into the evalUnit and does not need to be re-parsed on each execution.
However, I want to be able to pass the request object to the script, but I cannot find the correct way to do that. There will be multiple simultaneous requests, so I don't think I can use this.container.put("$request", request), correct?
UPDATE
In JRuby 1.6 there is now a LocalContextScope.CONCURRENT which appears to be what I am looking for. From what I can tell, if I construct ScriptingContainer as new ScriptingContainer(LocalContextScope.CONCURRENT, LocalVariableBehavior.TRANSIENT) then I can call
container.getProvider().getVarMap().put("#request", request);
service.getEvalUnit().run();
and each thread will have its own #request value.
Am I understanding this usage correctly?

Sensible unit test possible?

Could a sensible unit test be written for this code which extracts a rar archive by delegating it to a capable tool on the host system if one exists?
I can write a test case based on the fact that my machine runs linux and the unrar tool is installed, but if another developer who runs windows would check out the code the test would fail, although there would be nothing wrong with the extractor code.
I need to find a way to write a meaningful test which is not binded to the system and unrar tool installed.
How would you tackle this?
public class Extractor {
private EventBus eventBus;
private ExtractCommand[] linuxExtractCommands = new ExtractCommand[]{new LinuxUnrarCommand()};
private ExtractCommand[] windowsExtractCommands = new ExtractCommand[]{};
private ExtractCommand[] macExtractCommands = new ExtractCommand[]{};
#Inject
public Extractor(EventBus eventBus) {
this.eventBus = eventBus;
}
public boolean extract(DownloadCandidate downloadCandidate) {
for (ExtractCommand command : getSystemSpecificExtractCommands()) {
if (command.extract(downloadCandidate)) {
eventBus.fireEvent(this, new ExtractCompletedEvent());
return true;
}
}
eventBus.fireEvent(this, new ExtractFailedEvent());
return false;
}
private ExtractCommand[] getSystemSpecificExtractCommands() {
String os = System.getProperty("os.name");
if (Pattern.compile("linux", Pattern.CASE_INSENSITIVE).matcher(os).find()) {
return linuxExtractCommands;
} else if (Pattern.compile("windows", Pattern.CASE_INSENSITIVE).matcher(os).find()) {
return windowsExtractCommands;
} else if (Pattern.compile("mac os x", Pattern.CASE_INSENSITIVE).matcher(os).find()) {
return macExtractCommands;
}
return null;
}
}
Could you not pass the class a Map<String,ExtractCommand[]> instances and then make an abstract method, say GetOsName, for getting the string to match. then you could look up the match string in the map to get the extract command in getSystemSpecificExtractCommands method. This would allow you to inject a list containing a mock ExtractCommand and override the GetOsName method to return the key of your mock command, so you could test that when the extract worked, the eventBus is fired etc.
private Map<String,EvenetCommand[]> eventMap;
#Inject
public Extractor(EventBus eventBus, Map<String,EventCommand[]> eventMap) {
this.eventBus = eventBus;
this.eventMap = eventMap;
}
private ExtractCommand[] getSystemSpecificExtractCommands() {
String os = GetOsName();
return eventMap.Get(os);
}
protected GetOsName();
{
return System.getProperty("os.name");
}
I would look for some pure java APIs for manipulating rar files. This way the code will not be system dependent.
A quick search on google returned this:
http://www.example-code.com/java/rar_unrar.asp
Start with a mock framework. You'll need to refactor a bit, as you will need to ensure that some of those private and local scope properties/variables can be overridden if need be.
Then when you are testing Extract, you make sure you've mocked out the commands, and ensure that the Extract method is called on your mocked objects. You'll also want to ensure that your event got fired too.
Now to make it more testable you can use constructor or property injection. Either way, you'll need to make the private ExtractCommand arrays overriddable.
Sorry, don't have time to recode it, and post, but that should just about get you started nicely.
Good luck.
EDIT. It does sound like you are more after a functional test anyway if you want to test that it is actually extracted correctly.
Testing can be tricky, especially getting the divides right between the different types of tests and when they should be run and what their responsibilities are. This is even more so with cross-platform code.
While it's possible to think of this as 1 code base you are testing, it's really multiple code bases, the generic java code and code for each target platform, so you will need multiple tests.
To begin with unit testing, you will not be exercising the external command. Rather, each platform specific class is tested to see that it generates the correct command line, without actually executing it.
Your java class that hides all the platform specifics (which command to use) has a unit test to verify that it instantiates the correct platform specific class for a given platform. The platform can be a parameter to the core test, so multiple platforms can be "emulated". To take the unit test further, you could mock out the command implementation (e.g. having a RAR file and it's uncompressed form as part of your test data, and the command is a simple copy of the uncompressed data.)
Once these unit tests are in place and green, you then can move on to functional tests, where the real platform specific commands are executed. Of course, these functional tests have to be run on the actual platform. Each functional test corresponds to a platform specific class that knows how to create the correct commandline to unrar.
Your build is configured to exclude tests for classes that don't apply to the current platform, for example, so LinuxUnrarer is not tested on Windows. The platform independent java class is always tested, and it will instantiate the appropriate platform specific test. This gives you a integration test to see that the system works end to end.
As to cross platform UNRAR, there is a java RAR scanner, but it doesn't decompress.

How can I convince GroovyShell to maintain state over eval() calls?

I'm trying to use Groovy to create an interactive scripting / macro mode for my application. The application is OSGi and much of the information the scripts may need is not know up front. I figured I could use GroovyShell and call eval() multiple times continually appending to the namespace as OSGi bundles are loaded. GroovyShell maintains variable state over multiple eval calls, but not class definitions or methods.
goal: Create a base class during startup. As OSGi bundles load, create derived classes as needed.
I am not sure about what you mean about declared classes not existing between evals, the following two scripts work as expected when evaled one after another:
class C {{println 'hi'}}
new C()
...
new C()
However methods become bound to the class that declared them, and GroovyShell creates a new class for each instance. If you do not need the return value of any of the scripts and they are truly scripts (not classes with main methods) you can attach the following to the end of every evaluated scrips.
Class klass = this.getClass()
this.getMetaClass().getMethods().each {
if (it.declaringClass.cachedClass == klass) {
binding[it.name] = this.&"$it.name"
}
}
If you depend on the return value you can hand-manage the evaluation and run the script as part of your parsing (warning, untested code follows, for illustrative uses only)...
String scriptText = ...
Script script = shell.parse(scriptText)
def returnValue = script.run()
Class klass = script.getClass()
script.getMetaClass().getMethods().each {
if (it.declaringClass.cachedClass == klass) {
shell.context[it.name] = this.&"$it.name"
}
}
// do whatever with returnValue...
There is one last caveat I am sure you are aware of. Statically typed variables are not kept between evals as they are not stored in the binding. So in the previous script the variable 'klass' will not be kept between script invocations and will disappear. To rectify that simply remove the type declarations on the first use of all variables, that means they will be read and written to the binding.
Ended up injecting code before each script compilation. End goal is that the user written script has a domain-specific-language available for use.
This might be what you are looking for?
From Groovy in Action
def binding = new Binding(x: 6, y: 4)
def shell = new GroovyShell(binding)
def expression = '''f = x * y'''
shell.evaluate(expression)
assert binding.getVariable("f") == 24
An appropriate use of Binding will allow you to maintain state?

Categories

Resources