we need to ensure it is the best solution).
Because system properties are by definition system wide. So even if in your
it, you can be pretty sure that people will abuse it. By abuse it, I mean
for 2 different kind of scripts. And the Groovy script engine documentation
configuration file which path is defined through the xxx system property".
Imagine that you do this in 2 distinct threads and bad things will happen.
so avoid, IMHO, promoting situations which are unsafe. A system property
should IMHO always be considered as a last resort workaround. Last but not
least, each call to System.getProperty() is blocking. That means that if
for example one script in each thread, then you have a race condition.
Post by Maarten Boekhold2. if yes, then do we want to build an inherently unsafe script engine to
be able to workaround JSR limitations?
Apart from your comment on multiple applications inside the same
appserver, I still don't really see how "unsafe" this is. The 3 ASTs that I
*all* your compiled scripts. It's just a feature you provide to the users
who write the scripts to say "you have automatic access to a variable
called LOG that has methods info/debug/warn/error".
- SecureASTCustomizer: as the administrator of the application, I want to
prevent my "script writing users" from doing stuff like System.exit()
- Import Customizer: as the administrator of the app, I want to tell users
"you can access anything under my.custom.package without having to add any
imports to the script"
None of that is unsafe in my view.
Unsafe as described in the system property case: we have to think about
the general case, where bad things will happen.
Post by Maarten BoekholdMaarten
Ok let me be clear why I think using a Groovy specific API is better in
this case. First of all, JSR-223 was born with Groovy, so the the script
engines are pretty similar. But Groovy has evolved a lot, and JSR-223 is
far behind in terms of what you can do to configure the engine (in short,
nothing). The advantage of JSR-223 is if you want to switch from one engine
(Groovy) to another (Nashorn) or if you want to support multiple scripting
languages for the same application. So far so good, but as you noticed
Groovy unleashes its full potential when you configure the engine, allowing
you to have much better DSLs. Otherwise integration is pretty ridiculous.
So, naturally, you want to configure the engine and JSR-223 does not let
you do this. So if you really need to leverage JSR-223 (which IMHO is not
the case for 95% of integration cases), you have a problem. There are two
1. find *workarounds* in the Groovy JSR 223 engine to be able to fetch
configuration magically
2. work on an improved JSR 223 allowing to pass at least a map for
configuration data of the engine (I don't think we need more than that).
Of course as a user, you can't do 2, but you can submit the idea. So
what's left is 1. Unfortunately, as you noticed, "magically" has a lot of
drawbacks. It forces the Groovy JSR-223 engine to be inherently unsafe
*and* limited. Getting the configuration "magically" implies that the
1. system properties. Easiest to implement, but global, so impossible to
have two distinct configurations for two kind of scripts. Can be very
problematic if you use Groovy in two applications hosted in the same app
server for example, because it could just break one application. And as
Jochen said, it's not thread-safe.
2. Thread locals. You can store the configuration local inside the current
thread, used to compile the script. The "Safest" approach, as long as you
take care of removing the configuration data from the thread after the
script is compiled, otherwise you create a memory leak.
3. Files. The script engine could search for configuration data in the
file system, in a specific place. Not any better than 1, and not thread
safe.
4. Classpath. It is a variant of 1 and 3, where you could push on
classpath a resource file that would be picked by the script engine. Is has
the advantage of isolating one application from the other, but still,
configuration is global in a single application.
1. do you *really* need to rely on JSR 223
2. if yes, then do we want to build an inherently unsafe script engine to
be able to workaround JSR limitations?
Ah, yes I see. Very nice.
I have a minor stylistic suggestion to make the naming more like the
COMPILER_CONFIG_SYSTEM_PROPERTY = "groovy.jsr223.option.configscript"
BASE_SCRIPT_SYSTEM_PROPERTY = "groovy.jsr223.option.basescript"
Not sure when I'll be able to give this a whirl. No hurry on getting
the JIRA and such set up but if you get stuck then I can help you out with
that.
Good work!
Jim
Post by Maarten BoekholdHi Jim,
--configscript is already taken care of by my
"groovy.jsr223.compiler.configurator" System property. This one takes the
name of a file, which has the same syntax as what you would provide to the
--configscript option.
Good point about --basescript. I've added this to my patch now, will push
soon after gradlew test completes. I can't work on the documentation part
from here. Due to a corporate firewall I've got big trouble getting gradlew
asciidoc to run, and I can't access my home computer at the moment (port
forwarding screwed up). Will see if I can do anything about documentation
later today/tomorrow.
https://github.com/boekhold/groovy-core/compare/feature/JSR-223-CompilerConfig
Maarten
This excellent Maarten! I haven't done any JSR-223 in a long while and
didn't realize the ability to specify the CompilerConfiguration wasn't
supported (I did the original JSR-223 implementation for Groovy, Scala,
Jython, and a couple other languages as part of the development for IFCX
Wings <http://www.ifcx.org/wiki/Wings.html>).
Using a system property is indeed the correct design (you can see it
used elsewhere <https://github.com/jruby/jruby/wiki/RedBridge> the same
way with JRuby for example). Other options that would be useful to specify
would be the base script (--basescript) and configuration script
(--configscript).
As for folks trying to persuade you to "use a Groovy specific API", I'm
sure you understand what they don't which is that where JSR-223 is used (a
standard Java API used in thousands of systems) that is a non-option.
You need to set up a JIRA issue to track this work.
Jim
Post by Maarten BoekholdHi,
If you want something concrete to look at, here's the link to a feature
https://github.com/boekhold/groovy-core/compare/groovy:master...feature/JSR-223-CompilerConfig
No test cases/docs added yet, but existing test cases all pass. I also
know that the code I inserted in the default constructor /in theory/ works
because I've used almost the same code in another project (and I stole it
from the groovyc source :)).
Maarten
Post by Maarten BoekholdHmmm,
thinking about this a bit more, I think that option 2 (using
ScriptContext) is a dead-end: it would prevent any existing/closed
application that relies on the javax.script API from using the proposed
functionality. So I guess this would have to work based on a System
property (groovy.jsr223.compiler.configurator=XXXX).
Maarten
Post by Maarten BoekholdHi all,
For a while now I've had this idea that it would be useful if we could
instruct the GroovyScriptEngineImpl to use a CompilerConfiguration similar
to the -configfile option to groovyc.
1. Use a system property that you set before requesting your
ScriptEngine instance
2. Use the 'default ScriptContext' to set a special context variable
containing the configuration script name, and to do a lazy initialization
of the GroovyClassLoader.
Downside of (1) is that the specified config file would apply to each
separate instance of GroovyScriptEngineImpl, which might not be what you
want. Downside to (2) is that this seems to be 'misusing' the ScriptContext
a bit. In addition, if there is an error in your config script, you would
get an exception the first time you try to eval/compile something, and not
on instantiation of the ScriptEngine.
I wonder what others think of this? I'm willing to create a pull
request for this functionality, provided I get some direction on which
approach would be acceptable to the core team.
Maarten
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
--
Cédric Champeau
Groovy language developerhttp://twitter.com/CedricChampeauhttp://melix.github.io/blog