Since Groovy easily allows external Java libraries to be accessed, I assume that can also be done from within Quantrix scripts – but what does one need to do about setting path variables and such like. I’m sure I could figure it out by a process of elimination, but it would be much easier if someone else has already done it And an example of using an Import statement within a Script would be just perfect…
I’m not sure if the default one should expect for a Quantrix script is the same level of sandbox that one would have for an applet – after all the Quantrix model is a local application.
But I’d have no problem with that being the default if there was some way to change it. At a minimum I’d expect a script to be able to access the local file system if it needed to.
However, relating this back to the original issue with loading external classes – it would be better to resolve that by making the script environment recognize the CLASSPATH.
Ah, a tight security policy would indeed prevent this. Actually, this is a very sensible default as otherwise it could end up like typical Microsoft products that have files that could contain malicious code.
Perhaps the solution is to add script/model signing, as with applets, and prompt for explicit user approval to access restricted features?
My jython plug-in I refer to does not have these constraints as plug-ins run directly in the JVM I believe.
Having poked around a bit more it seems all scripts run under the default security manager – and thus are treated like applets in a browser, with no permissions to access the file system, system properties, etc. That doesn’t seem like what one would expect/want. It should be easy to set an alternate security policy that enables full access.
This issue is much wider than accessing external jar files – currently scripts would not be able to access any resources external to the Quantrix environment.
I did try that previously (based on somewhat simpler info on FAQ: [url=http://groovy.codehaus.org/Class+Loading:3us95lya]http://groovy.codehaus.org/Class+Loading[/url:3us95lya]), but it throws a security error:
[INDENT][font=”Courier New”]java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader)
which I took to be due to Quantrix disabling the class loader to create a sandbox environment. (Sorry I forgot to mention that branch of exploration in my initial post)
Are you able to access the classloader within a Quantrix script?
Just read that article further… the instantiation syntax isn’t particularly nice in Groovy though as you need to do eg:
jaxbContext = Class.forName(‘javax.xml.bind.JAXBContext’).newInstance()
whereas in jython this would be:
jaxbContext = javax.xml.bind.JAXBContext()
The article also claims Groovy can’t subclass classes imported from external libraries when loaded at runtime this way (but this may be old as the article is from February 2007).
You definitely can do this in jython though and is most useful – the standard syntax works:
This shouldn’t be too difficult as I have been doing this for years with my Jython plug-in. To add to the runtime classpath all I do is:
where jarfile is a string and then I can import the libraries.
For Groovy, a quick search turns up [url:35b3kppj]http://groovy.codehaus.org/Influencing+class+loading+at+runtime[/url:35b3kppj] which seems to indicate you do something along the lines of:
where jarfile is a File.
You are correct. I had only tried a quick experiment in response to your earlier post and it looks like I was a little hasty in drawing my conclusion.
Upon further investigation: There is a possibility of providing hooks for this, but it will need to wait for a future release. I have logged it as a feature request.
Ben, that is great – and the example is itself very useful, because it gives a way to provide input to scripts (using JOptionPane) without having to create matrices just to provide input fields.
However – after much messing about with classpaths etc, think I can definitely say that the reason it works is because Quantrix is already aware of rt.jar, in its own rjelib directory. So when you perform the import Quantrix can find the relevant swing class. Quantrix is not using the standard classpath variable.
If I have some other jar file, not known to Quantrix, then putting it on the classpath doesn’t enable Quantrix scripting to find it. I have however used an identical import in the Groovy console, with the jar file on classpath, and it works fine.
Conclusion – Quantrix scripting needs to recognize classpath (as Groovy does), or I need some way to configure Quantrix to add a new jar file. The latter exists for Quantrix plug-ins – but I guess I’d have to take the new Java library through the plug-in process to build a suitable manifest to get Quantrix to recognize it – which seems like more work than should be necessary…
The Quantrix scripting environment doesn’t deviate too much from the default Groovy environment, so most things that you can do in standalone Groovy should also work in Quantrix. This goes for imports: if the library you want is on the Java classpath, you can import and use it as you would expect. The following works on the Quantrix scripting console and displays a Swing message dialog:
Or as an action:
The following groovy documentation page has a segment near the bottom that addresses how to include libraries that are not already on the Java classpath. I haven’t tried any of their alternative methods, but I suspect they would work with Quantrix too.
Hopefully this is a start. Let me know if you need more information in any particular area.