As far as I know, most scripting engines have some sort of embedded
cache. The problem will be that we can't clear the embedded cache like
we can with our own cache implementation. I don't see that as a show
stopper - it's mostly inconvenient.
I can help out with the conversion. I don't think the task will be that
hard.
Regarding a slimmed down framework, I proposed one some time ago:
https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision
and that document was in response to David's proposal to base OFBiz on
Moqui (another option).
-Adrian
On 3/1/2012 8:53 AM, Jacopo Cappellato wrote:
Implementing JSR-223 should be rather easy but if I am not wrong it would
prevent the ability to cache the scripts (task that is currently done in
org.ofbiz.base.util.GroovyUtil, that is using the the more flexible
GroovyClassLoader mechanism); we could probably use the javax.script.Compilable
interface but I am not sure...
One advantage of JSR-223 would be that we could dynamically select the script
engine based on the (for example) file extension without the need to maintain
several classes like GroovyUtil, BsfUtil etc...
The idea would be that, instead of having a GroovyUtil class we could have a
generic ScriptUtil class with code like the following:
ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine scriptEngine =
manager.getEngineByExtension(fileExtension);
Object result = scriptEngine.eval(scriptFileReader, scriptContext);
and this code would be generic and could be used to plug in all the scripting
engines that support JSR-223.
However doing this in OFBiz would mean that we have to refactor all the code that is
currently using the various<script>Util classes and in my opinion a simpler
path (that is inline with Erwan's proposal to convert all remaining beanshell
snippets to Groovy and then deprecate or remove BshUtil) would be:
1) migrate the remaining Beanshell snippets to Groovy
2) deprecate or remove (I see a lot of value in having lighter framework [*])
Beashell support (and other artifacts related to old/unused script engines)
3) (optional, something for the future) refactor the GroovyUtil class (and code
that is using it) to be generic (ScriptUtil) and convert all the calling code
to use it in a Groovy unaware way; this will implement the JSR-223
In this way, when we will work on #3 we could concentrate only on migration of
groovy classes rather than having to cope with several other technologies
(removed at #2)
Kind regards,
Jacopo
[*] In my opinion one of the main big steps that the OFBiz project should
consider is to greatly slim down the framework and only support the technology
we really need (picking the best for each task); then with a much smaller
codebase, we will be able to quickly improve the framework (less code to
maintain etc...) to be compliant with new standards etc.. (e.g. JSR-223). For
example in this context: ideally the OFBiz project should have all the scripts
implemented in Groovy (one technology) and a simple way to integrate other
scripting languages; we could achieve this implementing JSR-223 so that even
the OFBiz code would be using javax.script.* rather than groovy.* packages OR
it would be also fine if we would still be using groovy.* packages but in a
clean way (e.g. all calling code could use interfaces to hide Groovy specific
code) so that adding a new script engine would be easy (but the support of the
new script engine will not be included in the project to keep it light and
focused)
On Feb 27, 2012, at 3:53 PM, Erwan de FERRIERES wrote:
Le 12/02/2012 20:43, Adrian Crum a écrit :
It would be nice if we could come up with a way to use JSR 223 in screen
widgets and mini-language.
Adrian,
would this mean that we'll be moving from
groovy.lang.Script
to
ScriptEngineManager and ScriptEngine ?
Do you think this would be a big task to accomplish this migration ?
Regards,
-Adrian
On 2/9/2012 6:31 AM, Jacques Le Roux wrote:
After almost 4 years, I can see no problems with that
Jacques
From: "Erwan de FERRIERES"<[email protected]>
Hi all,
in may 2008, we decided to move from beanshell to groovy
(http://ofbiz.markmail.org/message/5p33dhfnuh7gnfby?q=groovy+beanshell#query:groovy%20beanshell).
Since this time a lot of migration has been done, but still some
snippets are remaining in the code (mostly in screens).
What do you think of removing all the remaining bsh code, as well as
its support in OFBiz ?
Regards,
--
Erwan de FERRIERES
--
Erwan de FERRIERES
www.nereide.biz
