Re: Implementing JSR-223
Now that we have the basic framework working, we can explore this idea further. Right now we have ScriptHelper object available through the key ofbiz. The object is retrieved from a single ScriptHelperFactory instance. If we made the getInstance method of ScriptHelperFactory return a java.lang.Object, then any number of factories could be used to add any number of custom helper objects to the bindings. -Adrian On 3/6/2012 11:49 PM, Scott Gray wrote: I'm not sure I follow what you're saying. I'm sure a java based script helper class in the context could be useful but I don't think it should preclude the ability to include classes in the context that assist with language specific features. I don't really see how giving users the ability to write their own helper classes and make them available via configuration (similar to Freemarker Transforms) would be anything other than a huge bonus, regardless of your scripting language of choice. I would argue that attempting to constrain users to a single generic set of methods that we have deemed useful would not be what most people would consider accommodating. Rather than try to consider what everyone might want, I would rather see us give users the power to do whatever they need. Regards Scott On 7/03/2012, at 12:33 PM, Adrian Crum wrote: The EntityConditionBuilder class is a good example of how we can make scripting more convenient. Different scripting languages will have varying support for Java classes. It was my hope that we could come up with a Java-based script helper class that can be used by a variety of scripting languages that can access Java objects. I understand that there is an interest in Groovy in this community, but other communities might prefer a different language. For example, Jython and Ruby have sizable communities. My motivation in in implementing JSR-223 is the same as my motivation to implement internationalization/globalization years ago - to open up the project to more users. So, let's try to keep the big picture in mind. If we come up with a scripting convenience, let's try to accommodate the most users with it. -Adrian On 3/6/2012 10:23 AM, Scott Gray wrote: The EntityConditionBuilder class I wrote a while back is a good example of a groovy specific utility class, it takes advantage of groovy's language syntax features and couldn't be used in any other scripting language (well, not in the intended manner anyway). A possible solution could be to have some sort of configuration file per scripting language where classes to be instantiated could be assigned to specific context variables: conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder Or maybe xml if we needed greater configuration control such as passing specific context variables into the utility class's constructor, perhaps similar in structure to minilang's call-class-method tag. Regards Scott On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote: This could work but I was thinking to something more like having some core packages (like entity and service) always imported in groovy scripts/services; or having the delegator and dispatcher objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc... But I don't have a clear list at the moment so please do not consider my notes a blocker. I am working at a POC for a best practice Groovy service implementation and this should end up with a wish list of features I would like to have. Then we can discuss the best way to achieve this. Jacopo On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote: If you don't mind, I would like to get all of the issues resolved during the design phase. I will wait for the private email to understand what you mean by a secure scripting package. What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like: // Groovy, JavaScript partyValue = script.entityOne(Party); if (partyValue)... In other words, have an object in the context that gives us the convenience of mini-language. -Adrian On 3/5/2012 8:01 AM, Jacopo Cappellato wrote: On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote: It seems to me if there is a security issue using Groovy, then there would be an issue using any scripting language. Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy scripts in a secure way and already packaged with hundreds of scripts. If the user will add a new jar to support a different script (and the user will also have to implement the custom scripts) then this will be less secure but there isn't much we could do as we delegate to JSR-223 the implementation of security. Why can't we put the friendly methods in the context, so all scripting languages can use them? I am
Re: Implementing JSR-223
I finished my work on this integration in rev 1299924. We now have a basic scripting framework that developers can extend by adding scripting language engines. The framework includes a script helper class that is based on Jacopo's DSL idea. Scripts can access the helper class using the ofbiz variable. There is still some work left to do to complete this task - various bits of framework code that invoke scripts need to use the new ScriptUtil class instead of whatever they are using now. Also, the JavaDocs are incomplete. I will leave those tasks for others to complete. As I mentioned previously, there is a name clash with the context variable that might cause problems. I added a widget variable to take its place, so scripts that reference context need to be changed to reference widget instead. By the way, BSH uses the script variable name for its own helper class - that's why we use the ofbiz variable name. I'm sure we will encounter other surprises as this is built out. -Adrian On 3/11/2012 4:32 PM, Adrian Crum wrote: Since the context binding (variable) is used only in scripts run from screen widgets, I was thinking we could rename it widget - which has the added benefit of making operations on it more meaningful. To summarize: service and event scripts return values via the results binding, and screen widget scripts return values via the widget binding. What do you think? -Adrian On 3/6/2012 9:17 AM, Adrian Crum wrote: I was thinking of using _context. I know we try to stay away from leading underscores as a general practice, but in this case I thought it would make the replacement (and learning curve) easier. -Adrian On 3/6/2012 8:57 AM, Jacopo Cappellato wrote: I would be in favor of bulk renaming all the context variables in our scripts... maybe we could wait after the creation of the 12.04 release branch... but I would be in favor even if we do this earlier. Jacopo On Mar 6, 2012, at 9:47 AM, Adrian Crum wrote: Update: I added a generic ScriptEngine to the service engine in rev 1297323. I haven't updated screen widgets and mini-lang to use JSR-223 because there is a compatibility problem. In JSR-223, the context binding is reserved for the ScriptContext object, so any script code that uses the variable context will be using the ScriptContext object - not the context Map. I'm not sure how to proceed from here. -Adrian On 3/6/2012 7:58 AM, Jacopo Cappellato wrote: This could work but I was thinking to something more like having some core packages (like entity and service) always imported in groovy scripts/services; or having the delegator and dispatcher objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc... But I don't have a clear list at the moment so please do not consider my notes a blocker. I am working at a POC for a best practice Groovy service implementation and this should end up with a wish list of features I would like to have. Then we can discuss the best way to achieve this. Jacopo On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote: If you don't mind, I would like to get all of the issues resolved during the design phase. I will wait for the private email to understand what you mean by a secure scripting package. What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like: // Groovy, JavaScript partyValue = script.entityOne(Party); if (partyValue)... In other words, have an object in the context that gives us the convenience of mini-language. -Adrian On 3/5/2012 8:01 AM, Jacopo Cappellato wrote: On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote: It seems to me if there is a security issue using Groovy, then there would be an issue using any scripting language. Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy scripts in a secure way and already packaged with hundreds of scripts. If the user will add a new jar to support a different script (and the user will also have to implement the custom scripts) then this will be less secure but there isn't much we could do as we delegate to JSR-223 the implementation of security. Why can't we put the friendly methods in the context, so all scripting languages can use them? I am not sure I understand what you are proposing (the method would be language specific) but for now we can postpone this discussion at when (if it will ever happen) we will discuss about this approach. Jacopo -Adrian On 3/5/2012 6:46 AM, Jacopo Cappellato wrote: On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote: The code changes tested fine. I noticed in your code comments that Groovy should be handled independently from other scripting languages. Why do you think that? First of all, I apologize for having added my
Re: Implementing JSR-223
Since the context binding (variable) is used only in scripts run from
screen widgets, I was thinking we could rename it widget - which has
the added benefit of making operations on it more meaningful.
To summarize: service and event scripts return values via the results
binding, and screen widget scripts return values via the widget binding.
What do you think?
-Adrian
On 3/6/2012 9:17 AM, Adrian Crum wrote:
I was thinking of using _context. I know we try to stay away from
leading underscores as a general practice, but in this case I thought
it would make the replacement (and learning curve) easier.
-Adrian
On 3/6/2012 8:57 AM, Jacopo Cappellato wrote:
I would be in favor of bulk renaming all the context variables in
our scripts... maybe we could wait after the creation of the 12.04
release branch... but I would be in favor even if we do this earlier.
Jacopo
On Mar 6, 2012, at 9:47 AM, Adrian Crum wrote:
Update: I added a generic ScriptEngine to the service engine in rev
1297323.
I haven't updated screen widgets and mini-lang to use JSR-223
because there is a compatibility problem. In JSR-223, the context
binding is reserved for the ScriptContext object, so any script code
that uses the variable context will be using the ScriptContext
object - not the context Map. I'm not sure how to proceed from here.
-Adrian
On 3/6/2012 7:58 AM, Jacopo Cappellato wrote:
This could work but I was thinking to something more like having
some core packages (like entity and service) always imported in
groovy scripts/services; or having the delegator and dispatcher
objects properly casted to their interfaces (to take advantage of
IDE autocompletion features); etc...
But I don't have a clear list at the moment so please do not
consider my notes a blocker.
I am working at a POC for a best practice Groovy service
implementation and this should end up with a wish list of
features I would like to have. Then we can discuss the best way to
achieve this.
Jacopo
On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
If you don't mind, I would like to get all of the issues resolved
during the design phase.
I will wait for the private email to understand what you mean by a
secure scripting package.
What I was suggesting is a script utility object that can be put
in the context so that all scripting languages can use it.
Whatever methods you have in mind could be implemented in a
generic way and reused. Personally, I would like to use something
like:
// Groovy, JavaScript
partyValue = script.entityOne(Party);
if (partyValue)...
In other words, have an object in the context that gives us the
convenience of mini-language.
-Adrian
On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
It seems to me if there is a security issue using Groovy, then
there would be an issue using any scripting language.
Yes, but what we would bundle ootb would be a secured packaged
ready to run Groovy scripts in a secure way and already
packaged with hundreds of scripts.
If the user will add a new jar to support a different script (and
the user will also have to implement the custom scripts) then
this will be less secure but there isn't much we could do as we
delegate to JSR-223 the implementation of security.
Why can't we put the friendly methods in the context, so all
scripting languages can use them?
I am not sure I understand what you are proposing (the method
would be language specific) but for now we can postpone this
discussion at when (if it will ever happen) we will discuss about
this approach.
Jacopo
-Adrian
On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
The code changes tested fine.
I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you think
that?
First of all, I apologize for having added my personal opinion
to those comments :-) but I thought that in this way it was
easier to exchange design ideas; the comments can actually be
removed.
The reasons I think we could treat Groovy in a special way (but
I don't have a strong opinion on this) are:
* ootb OFBiz will still be packaged with Groovy jars (they are
required by all the existing scripts and by some other code
like the implementation of Groovy service engine and Groovy
event handler) and so the dependency on Groovy will still be
there even if we run it with JSR-223
* the code to run Groovy in the special way is now all
contained in the ScriptUtil class and there are actually a few
lines of code to maintain for it
* keeping a custom way for Groovy has two main advantages that
are not currently used but I would like to consider in the
short term (and I don't think they are supported thru
JSR-223... but I am not sure):
** security: I would like to restrict the JVM security settings
for dynamic Groovy snippets like ${groovy: ...}; I have some
concerns in this
Re: Implementing JSR-223
Update: I added a generic ScriptEngine to the service engine in rev 1297323.
I haven't updated screen widgets and mini-lang to use JSR-223 because
there is a compatibility problem. In JSR-223, the context binding is
reserved for the ScriptContext object, so any script code that uses the
variable context will be using the ScriptContext object - not the
context Map. I'm not sure how to proceed from here.
-Adrian
On 3/6/2012 7:58 AM, Jacopo Cappellato wrote:
This could work but I was thinking to something more like having some core packages (like entity
and service) always imported in groovy scripts/services; or having the delegator and
dispatcher objects properly casted to their interfaces (to take advantage of IDE autocompletion
features); etc...
But I don't have a clear list at the moment so please do not consider my notes
a blocker.
I am working at a POC for a best practice Groovy service implementation and this should
end up with a wish list of features I would like to have. Then we can discuss the best
way to achieve this.
Jacopo
On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
If you don't mind, I would like to get all of the issues resolved during the
design phase.
I will wait for the private email to understand what you mean by a secure
scripting package.
What I was suggesting is a script utility object that can be put in the context
so that all scripting languages can use it. Whatever methods you have in mind
could be implemented in a generic way and reused. Personally, I would like to
use something like:
// Groovy, JavaScript
partyValue = script.entityOne(Party);
if (partyValue)...
In other words, have an object in the context that gives us the convenience of
mini-language.
-Adrian
On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
It seems to me if there is a security issue using Groovy, then there would be
an issue using any scripting language.
Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy
scripts in a secure way and already packaged with hundreds of scripts.
If the user will add a new jar to support a different script (and the user will
also have to implement the custom scripts) then this will be less secure but
there isn't much we could do as we delegate to JSR-223 the implementation of
security.
Why can't we put the friendly methods in the context, so all scripting
languages can use them?
I am not sure I understand what you are proposing (the method would be language
specific) but for now we can postpone this discussion at when (if it will ever
happen) we will discuss about this approach.
Jacopo
-Adrian
On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
The code changes tested fine.
I noticed in your code comments that Groovy should be handled independently
from other scripting languages. Why do you think that?
First of all, I apologize for having added my personal opinion to those
comments :-) but I thought that in this way it was easier to exchange design
ideas; the comments can actually be removed.
The reasons I think we could treat Groovy in a special way (but I don't have a
strong opinion on this) are:
* ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts
and by some other code like the implementation of Groovy service engine and
Groovy event handler) and so the dependency on Groovy will still be there even if we
run it with JSR-223
* the code to run Groovy in the special way is now all contained in the
ScriptUtil class and there are actually a few lines of code to maintain for it
* keeping a custom way for Groovy has two main advantages that are not
currently used but I would like to consider in the short term (and I don't
think they are supported thru JSR-223... but I am not sure):
** security: I would like to restrict the JVM security settings for dynamic Groovy
snippets like ${groovy: ...}; I have some concerns in this area that I will address in a
separate email soon; in this way we will secure the ootb system (packaged
with several groovy scripts and the groovy jars) but of course if the user will add to it
jars files for a new scripting language (executed using JSR-223) then the security issue
will still be there, but at least the user will know about it
** I would like to inject some OFBiz friendly methods to all Groovy scripts, so
that they can be used by Groovy scripts to run services, use the delegator
etc...
We should also consider the impact on performance, even if the best way to go
is probably to run some performance tests on the system running Groovy with
current code and with the system running Groovy using a custom method and then
compare the results.
Jacopo
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3,
Re: Implementing JSR-223
I would be in favor of bulk renaming all the context variables in our
scripts... maybe we could wait after the creation of the 12.04 release
branch... but I would be in favor even if we do this earlier.
Jacopo
On Mar 6, 2012, at 9:47 AM, Adrian Crum wrote:
Update: I added a generic ScriptEngine to the service engine in rev 1297323.
I haven't updated screen widgets and mini-lang to use JSR-223 because there
is a compatibility problem. In JSR-223, the context binding is reserved for
the ScriptContext object, so any script code that uses the variable context
will be using the ScriptContext object - not the context Map. I'm not sure
how to proceed from here.
-Adrian
On 3/6/2012 7:58 AM, Jacopo Cappellato wrote:
This could work but I was thinking to something more like having some core
packages (like entity and service) always imported in groovy
scripts/services; or having the delegator and dispatcher objects
properly casted to their interfaces (to take advantage of IDE autocompletion
features); etc...
But I don't have a clear list at the moment so please do not consider my
notes a blocker.
I am working at a POC for a best practice Groovy service implementation
and this should end up with a wish list of features I would like to have.
Then we can discuss the best way to achieve this.
Jacopo
On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
If you don't mind, I would like to get all of the issues resolved during
the design phase.
I will wait for the private email to understand what you mean by a secure
scripting package.
What I was suggesting is a script utility object that can be put in the
context so that all scripting languages can use it. Whatever methods you
have in mind could be implemented in a generic way and reused. Personally,
I would like to use something like:
// Groovy, JavaScript
partyValue = script.entityOne(Party);
if (partyValue)...
In other words, have an object in the context that gives us the convenience
of mini-language.
-Adrian
On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
It seems to me if there is a security issue using Groovy, then there
would be an issue using any scripting language.
Yes, but what we would bundle ootb would be a secured packaged ready to
run Groovy scripts in a secure way and already packaged with hundreds of
scripts.
If the user will add a new jar to support a different script (and the user
will also have to implement the custom scripts) then this will be less
secure but there isn't much we could do as we delegate to JSR-223 the
implementation of security.
Why can't we put the friendly methods in the context, so all scripting
languages can use them?
I am not sure I understand what you are proposing (the method would be
language specific) but for now we can postpone this discussion at when (if
it will ever happen) we will discuss about this approach.
Jacopo
-Adrian
On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
The code changes tested fine.
I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you think that?
First of all, I apologize for having added my personal opinion to those
comments :-) but I thought that in this way it was easier to exchange
design ideas; the comments can actually be removed.
The reasons I think we could treat Groovy in a special way (but I don't
have a strong opinion on this) are:
* ootb OFBiz will still be packaged with Groovy jars (they are required
by all the existing scripts and by some other code like the
implementation of Groovy service engine and Groovy event handler)
and so the dependency on Groovy will still be there even if we run it
with JSR-223
* the code to run Groovy in the special way is now all contained in the
ScriptUtil class and there are actually a few lines of code to maintain
for it
* keeping a custom way for Groovy has two main advantages that are not
currently used but I would like to consider in the short term (and I
don't think they are supported thru JSR-223... but I am not sure):
** security: I would like to restrict the JVM security settings for
dynamic Groovy snippets like ${groovy: ...}; I have some concerns in
this area that I will address in a separate email soon; in this way we
will secure the ootb system (packaged with several groovy scripts and
the groovy jars) but of course if the user will add to it jars files for
a new scripting language (executed using JSR-223) then the security
issue will still be there, but at least the user will know about it
** I would like to inject some OFBiz friendly methods to all Groovy
scripts, so that they can be used by Groovy scripts to run services, use
the delegator etc...
We should also consider the impact on performance, even if the best way
to
Re: Implementing JSR-223
I was thinking of using _context. I know we try to stay away from
leading underscores as a general practice, but in this case I thought it
would make the replacement (and learning curve) easier.
-Adrian
On 3/6/2012 8:57 AM, Jacopo Cappellato wrote:
I would be in favor of bulk renaming all the context variables in our
scripts... maybe we could wait after the creation of the 12.04 release branch... but I
would be in favor even if we do this earlier.
Jacopo
On Mar 6, 2012, at 9:47 AM, Adrian Crum wrote:
Update: I added a generic ScriptEngine to the service engine in rev 1297323.
I haven't updated screen widgets and mini-lang to use JSR-223 because there is a compatibility
problem. In JSR-223, the context binding is reserved for the ScriptContext object, so
any script code that uses the variable context will be using the ScriptContext object -
not the context Map. I'm not sure how to proceed from here.
-Adrian
On 3/6/2012 7:58 AM, Jacopo Cappellato wrote:
This could work but I was thinking to something more like having some core packages (like entity
and service) always imported in groovy scripts/services; or having the delegator and
dispatcher objects properly casted to their interfaces (to take advantage of IDE autocompletion
features); etc...
But I don't have a clear list at the moment so please do not consider my notes
a blocker.
I am working at a POC for a best practice Groovy service implementation and this should
end up with a wish list of features I would like to have. Then we can discuss the best
way to achieve this.
Jacopo
On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
If you don't mind, I would like to get all of the issues resolved during the
design phase.
I will wait for the private email to understand what you mean by a secure
scripting package.
What I was suggesting is a script utility object that can be put in the context
so that all scripting languages can use it. Whatever methods you have in mind
could be implemented in a generic way and reused. Personally, I would like to
use something like:
// Groovy, JavaScript
partyValue = script.entityOne(Party);
if (partyValue)...
In other words, have an object in the context that gives us the convenience of
mini-language.
-Adrian
On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
It seems to me if there is a security issue using Groovy, then there would be
an issue using any scripting language.
Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy
scripts in a secure way and already packaged with hundreds of scripts.
If the user will add a new jar to support a different script (and the user will
also have to implement the custom scripts) then this will be less secure but
there isn't much we could do as we delegate to JSR-223 the implementation of
security.
Why can't we put the friendly methods in the context, so all scripting
languages can use them?
I am not sure I understand what you are proposing (the method would be language
specific) but for now we can postpone this discussion at when (if it will ever
happen) we will discuss about this approach.
Jacopo
-Adrian
On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
The code changes tested fine.
I noticed in your code comments that Groovy should be handled independently
from other scripting languages. Why do you think that?
First of all, I apologize for having added my personal opinion to those
comments :-) but I thought that in this way it was easier to exchange design
ideas; the comments can actually be removed.
The reasons I think we could treat Groovy in a special way (but I don't have a
strong opinion on this) are:
* ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts
and by some other code like the implementation of Groovy service engine and
Groovy event handler) and so the dependency on Groovy will still be there even if we
run it with JSR-223
* the code to run Groovy in the special way is now all contained in the
ScriptUtil class and there are actually a few lines of code to maintain for it
* keeping a custom way for Groovy has two main advantages that are not
currently used but I would like to consider in the short term (and I don't
think they are supported thru JSR-223... but I am not sure):
** security: I would like to restrict the JVM security settings for dynamic Groovy
snippets like ${groovy: ...}; I have some concerns in this area that I will address in a
separate email soon; in this way we will secure the ootb system (packaged
with several groovy scripts and the groovy jars) but of course if the user will add to it
jars files for a new scripting language (executed using JSR-223) then the security issue
will still be there, but at least the user will know about it
** I would like to inject some OFBiz friendly methods to all Groovy scripts, so
that
Re: Implementing JSR-223
The EntityConditionBuilder class I wrote a while back is a good example of a
groovy specific utility class, it takes advantage of groovy's language syntax
features and couldn't be used in any other scripting language (well, not in the
intended manner anyway).
A possible solution could be to have some sort of configuration file per
scripting language where classes to be instantiated could be assigned to
specific context variables:
conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder
Or maybe xml if we needed greater configuration control such as passing
specific context variables into the utility class's constructor, perhaps
similar in structure to minilang's call-class-method tag.
Regards
Scott
On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote:
This could work but I was thinking to something more like having some core
packages (like entity and service) always imported in groovy
scripts/services; or having the delegator and dispatcher objects properly
casted to their interfaces (to take advantage of IDE autocompletion
features); etc...
But I don't have a clear list at the moment so please do not consider my
notes a blocker.
I am working at a POC for a best practice Groovy service implementation and
this should end up with a wish list of features I would like to have. Then
we can discuss the best way to achieve this.
Jacopo
On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
If you don't mind, I would like to get all of the issues resolved during the
design phase.
I will wait for the private email to understand what you mean by a secure
scripting package.
What I was suggesting is a script utility object that can be put in the
context so that all scripting languages can use it. Whatever methods you
have in mind could be implemented in a generic way and reused. Personally, I
would like to use something like:
// Groovy, JavaScript
partyValue = script.entityOne(Party);
if (partyValue)...
In other words, have an object in the context that gives us the convenience
of mini-language.
-Adrian
On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
It seems to me if there is a security issue using Groovy, then there would
be an issue using any scripting language.
Yes, but what we would bundle ootb would be a secured packaged ready to run
Groovy scripts in a secure way and already packaged with hundreds of
scripts.
If the user will add a new jar to support a different script (and the user
will also have to implement the custom scripts) then this will be less
secure but there isn't much we could do as we delegate to JSR-223 the
implementation of security.
Why can't we put the friendly methods in the context, so all scripting
languages can use them?
I am not sure I understand what you are proposing (the method would be
language specific) but for now we can postpone this discussion at when (if
it will ever happen) we will discuss about this approach.
Jacopo
-Adrian
On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
The code changes tested fine.
I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you think that?
First of all, I apologize for having added my personal opinion to those
comments :-) but I thought that in this way it was easier to exchange
design ideas; the comments can actually be removed.
The reasons I think we could treat Groovy in a special way (but I don't
have a strong opinion on this) are:
* ootb OFBiz will still be packaged with Groovy jars (they are required
by all the existing scripts and by some other code like the
implementation of Groovy service engine and Groovy event handler) and
so the dependency on Groovy will still be there even if we run it with
JSR-223
* the code to run Groovy in the special way is now all contained in the
ScriptUtil class and there are actually a few lines of code to maintain
for it
* keeping a custom way for Groovy has two main advantages that are not
currently used but I would like to consider in the short term (and I
don't think they are supported thru JSR-223... but I am not sure):
** security: I would like to restrict the JVM security settings for
dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this
area that I will address in a separate email soon; in this way we will
secure the ootb system (packaged with several groovy scripts and the
groovy jars) but of course if the user will add to it jars files for a
new scripting language (executed using JSR-223) then the security issue
will still be there, but at least the user will know about it
** I would like to inject some OFBiz friendly methods to all Groovy
scripts, so that they can be used by Groovy scripts to run services, use
the delegator etc...
We should also consider the impact
Re: Implementing JSR-223
The EntityConditionBuilder class is a good example of how we can make scripting more convenient. Different scripting languages will have varying support for Java classes. It was my hope that we could come up with a Java-based script helper class that can be used by a variety of scripting languages that can access Java objects. I understand that there is an interest in Groovy in this community, but other communities might prefer a different language. For example, Jython and Ruby have sizable communities. My motivation in in implementing JSR-223 is the same as my motivation to implement internationalization/globalization years ago - to open up the project to more users. So, let's try to keep the big picture in mind. If we come up with a scripting convenience, let's try to accommodate the most users with it. -Adrian On 3/6/2012 10:23 AM, Scott Gray wrote: The EntityConditionBuilder class I wrote a while back is a good example of a groovy specific utility class, it takes advantage of groovy's language syntax features and couldn't be used in any other scripting language (well, not in the intended manner anyway). A possible solution could be to have some sort of configuration file per scripting language where classes to be instantiated could be assigned to specific context variables: conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder Or maybe xml if we needed greater configuration control such as passing specific context variables into the utility class's constructor, perhaps similar in structure to minilang's call-class-method tag. Regards Scott On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote: This could work but I was thinking to something more like having some core packages (like entity and service) always imported in groovy scripts/services; or having the delegator and dispatcher objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc... But I don't have a clear list at the moment so please do not consider my notes a blocker. I am working at a POC for a best practice Groovy service implementation and this should end up with a wish list of features I would like to have. Then we can discuss the best way to achieve this. Jacopo On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote: If you don't mind, I would like to get all of the issues resolved during the design phase. I will wait for the private email to understand what you mean by a secure scripting package. What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like: // Groovy, JavaScript partyValue = script.entityOne(Party); if (partyValue)... In other words, have an object in the context that gives us the convenience of mini-language. -Adrian On 3/5/2012 8:01 AM, Jacopo Cappellato wrote: On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote: It seems to me if there is a security issue using Groovy, then there would be an issue using any scripting language. Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy scripts in a secure way and already packaged with hundreds of scripts. If the user will add a new jar to support a different script (and the user will also have to implement the custom scripts) then this will be less secure but there isn't much we could do as we delegate to JSR-223 the implementation of security. Why can't we put the friendly methods in the context, so all scripting languages can use them? I am not sure I understand what you are proposing (the method would be language specific) but for now we can postpone this discussion at when (if it will ever happen) we will discuss about this approach. Jacopo -Adrian On 3/5/2012 6:46 AM, Jacopo Cappellato wrote: On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote: The code changes tested fine. I noticed in your code comments that Groovy should be handled independently from other scripting languages. Why do you think that? First of all, I apologize for having added my personal opinion to those comments :-) but I thought that in this way it was easier to exchange design ideas; the comments can actually be removed. The reasons I think we could treat Groovy in a special way (but I don't have a strong opinion on this) are: * ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts and by some other code like the implementation of Groovy service engine and Groovy event handler) and so the dependency on Groovy will still be there even if we run it with JSR-223 * the code to run Groovy in the special way is now all contained in the ScriptUtil class and there are actually a few lines of code to maintain for it * keeping a custom way for Groovy has two main advantages that are not currently used but I would like
Re: Implementing JSR-223
I'm not sure I follow what you're saying. I'm sure a java based script helper class in the context could be useful but I don't think it should preclude the ability to include classes in the context that assist with language specific features. I don't really see how giving users the ability to write their own helper classes and make them available via configuration (similar to Freemarker Transforms) would be anything other than a huge bonus, regardless of your scripting language of choice. I would argue that attempting to constrain users to a single generic set of methods that we have deemed useful would not be what most people would consider accommodating. Rather than try to consider what everyone might want, I would rather see us give users the power to do whatever they need. Regards Scott On 7/03/2012, at 12:33 PM, Adrian Crum wrote: The EntityConditionBuilder class is a good example of how we can make scripting more convenient. Different scripting languages will have varying support for Java classes. It was my hope that we could come up with a Java-based script helper class that can be used by a variety of scripting languages that can access Java objects. I understand that there is an interest in Groovy in this community, but other communities might prefer a different language. For example, Jython and Ruby have sizable communities. My motivation in in implementing JSR-223 is the same as my motivation to implement internationalization/globalization years ago - to open up the project to more users. So, let's try to keep the big picture in mind. If we come up with a scripting convenience, let's try to accommodate the most users with it. -Adrian On 3/6/2012 10:23 AM, Scott Gray wrote: The EntityConditionBuilder class I wrote a while back is a good example of a groovy specific utility class, it takes advantage of groovy's language syntax features and couldn't be used in any other scripting language (well, not in the intended manner anyway). A possible solution could be to have some sort of configuration file per scripting language where classes to be instantiated could be assigned to specific context variables: conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder Or maybe xml if we needed greater configuration control such as passing specific context variables into the utility class's constructor, perhaps similar in structure to minilang's call-class-method tag. Regards Scott On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote: This could work but I was thinking to something more like having some core packages (like entity and service) always imported in groovy scripts/services; or having the delegator and dispatcher objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc... But I don't have a clear list at the moment so please do not consider my notes a blocker. I am working at a POC for a best practice Groovy service implementation and this should end up with a wish list of features I would like to have. Then we can discuss the best way to achieve this. Jacopo On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote: If you don't mind, I would like to get all of the issues resolved during the design phase. I will wait for the private email to understand what you mean by a secure scripting package. What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like: // Groovy, JavaScript partyValue = script.entityOne(Party); if (partyValue)... In other words, have an object in the context that gives us the convenience of mini-language. -Adrian On 3/5/2012 8:01 AM, Jacopo Cappellato wrote: On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote: It seems to me if there is a security issue using Groovy, then there would be an issue using any scripting language. Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy scripts in a secure way and already packaged with hundreds of scripts. If the user will add a new jar to support a different script (and the user will also have to implement the custom scripts) then this will be less secure but there isn't much we could do as we delegate to JSR-223 the implementation of security. Why can't we put the friendly methods in the context, so all scripting languages can use them? I am not sure I understand what you are proposing (the method would be language specific) but for now we can postpone this discussion at when (if it will ever happen) we will discuss about this approach. Jacopo -Adrian On 3/5/2012 6:46 AM, Jacopo Cappellato wrote: On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote: The code changes tested fine. I noticed in your code
Re: Implementing JSR-223
Fair enough. Users of other scripting languages can adapt the code to suit their language. -Adrian On 3/6/2012 11:49 PM, Scott Gray wrote: I'm not sure I follow what you're saying. I'm sure a java based script helper class in the context could be useful but I don't think it should preclude the ability to include classes in the context that assist with language specific features. I don't really see how giving users the ability to write their own helper classes and make them available via configuration (similar to Freemarker Transforms) would be anything other than a huge bonus, regardless of your scripting language of choice. I would argue that attempting to constrain users to a single generic set of methods that we have deemed useful would not be what most people would consider accommodating. Rather than try to consider what everyone might want, I would rather see us give users the power to do whatever they need. Regards Scott On 7/03/2012, at 12:33 PM, Adrian Crum wrote: The EntityConditionBuilder class is a good example of how we can make scripting more convenient. Different scripting languages will have varying support for Java classes. It was my hope that we could come up with a Java-based script helper class that can be used by a variety of scripting languages that can access Java objects. I understand that there is an interest in Groovy in this community, but other communities might prefer a different language. For example, Jython and Ruby have sizable communities. My motivation in in implementing JSR-223 is the same as my motivation to implement internationalization/globalization years ago - to open up the project to more users. So, let's try to keep the big picture in mind. If we come up with a scripting convenience, let's try to accommodate the most users with it. -Adrian On 3/6/2012 10:23 AM, Scott Gray wrote: The EntityConditionBuilder class I wrote a while back is a good example of a groovy specific utility class, it takes advantage of groovy's language syntax features and couldn't be used in any other scripting language (well, not in the intended manner anyway). A possible solution could be to have some sort of configuration file per scripting language where classes to be instantiated could be assigned to specific context variables: conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder Or maybe xml if we needed greater configuration control such as passing specific context variables into the utility class's constructor, perhaps similar in structure to minilang's call-class-method tag. Regards Scott On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote: This could work but I was thinking to something more like having some core packages (like entity and service) always imported in groovy scripts/services; or having the delegator and dispatcher objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc... But I don't have a clear list at the moment so please do not consider my notes a blocker. I am working at a POC for a best practice Groovy service implementation and this should end up with a wish list of features I would like to have. Then we can discuss the best way to achieve this. Jacopo On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote: If you don't mind, I would like to get all of the issues resolved during the design phase. I will wait for the private email to understand what you mean by a secure scripting package. What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in mind could be implemented in a generic way and reused. Personally, I would like to use something like: // Groovy, JavaScript partyValue = script.entityOne(Party); if (partyValue)... In other words, have an object in the context that gives us the convenience of mini-language. -Adrian On 3/5/2012 8:01 AM, Jacopo Cappellato wrote: On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote: It seems to me if there is a security issue using Groovy, then there would be an issue using any scripting language. Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy scripts in a secure way and already packaged with hundreds of scripts. If the user will add a new jar to support a different script (and the user will also have to implement the custom scripts) then this will be less secure but there isn't much we could do as we delegate to JSR-223 the implementation of security. Why can't we put the friendly methods in the context, so all scripting languages can use them? I am not sure I understand what you are proposing (the method would be language specific) but for now we can postpone this discussion at when (if it will ever happen) we will discuss about this approach. Jacopo -Adrian On 3/5/2012 6:46 AM, Jacopo Cappellato wrote: On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote: The code
Re: Implementing JSR-223
Yes, I agree with the general strategy: OFBiz will be (or it is) flexible and ready to be used with alternative tools; our effort as a community will be that of opening it up and slimming it down instead of trying to include all the possible alternative tools in our package; and the work that Adrian is doing to enable OFBiz to JSR-223 is a good example in this direction because it provides a flexible mechanism to plug in different scripting languages by just dropping the (JSR-223 compliant) jar files of the language of preference in the classpath; of course this will be a generic/basic support (i.e. the generic/basic one provided by JSR-223) and if the user will want to implement a library of custom objects to better structure the work in the new script then it will be fine, but these classes will not find a way to OFBiz because they will be custom and because they will be useless if you don't plan to use that specific language. In a similar way the community has chosen for the OFBiz applications a scripting language of choice (currently Groovy) and this is the reason we have some Groovy friendly classes (shipped ootb) that are used by our Groovy scripts. Jacopo On Mar 7, 2012, at 12:58 AM, Adrian Crum wrote: Fair enough. Users of other scripting languages can adapt the code to suit their language. -Adrian On 3/6/2012 11:49 PM, Scott Gray wrote: I'm not sure I follow what you're saying. I'm sure a java based script helper class in the context could be useful but I don't think it should preclude the ability to include classes in the context that assist with language specific features. I don't really see how giving users the ability to write their own helper classes and make them available via configuration (similar to Freemarker Transforms) would be anything other than a huge bonus, regardless of your scripting language of choice. I would argue that attempting to constrain users to a single generic set of methods that we have deemed useful would not be what most people would consider accommodating. Rather than try to consider what everyone might want, I would rather see us give users the power to do whatever they need. Regards Scott On 7/03/2012, at 12:33 PM, Adrian Crum wrote: The EntityConditionBuilder class is a good example of how we can make scripting more convenient. Different scripting languages will have varying support for Java classes. It was my hope that we could come up with a Java-based script helper class that can be used by a variety of scripting languages that can access Java objects. I understand that there is an interest in Groovy in this community, but other communities might prefer a different language. For example, Jython and Ruby have sizable communities. My motivation in in implementing JSR-223 is the same as my motivation to implement internationalization/globalization years ago - to open up the project to more users. So, let's try to keep the big picture in mind. If we come up with a scripting convenience, let's try to accommodate the most users with it. -Adrian On 3/6/2012 10:23 AM, Scott Gray wrote: The EntityConditionBuilder class I wrote a while back is a good example of a groovy specific utility class, it takes advantage of groovy's language syntax features and couldn't be used in any other scripting language (well, not in the intended manner anyway). A possible solution could be to have some sort of configuration file per scripting language where classes to be instantiated could be assigned to specific context variables: conditionBuilder=org.ofbiz.entity.condition.EntityConditionBuilder Or maybe xml if we needed greater configuration control such as passing specific context variables into the utility class's constructor, perhaps similar in structure to minilang's call-class-method tag. Regards Scott On 6/03/2012, at 8:58 PM, Jacopo Cappellato wrote: This could work but I was thinking to something more like having some core packages (like entity and service) always imported in groovy scripts/services; or having the delegator and dispatcher objects properly casted to their interfaces (to take advantage of IDE autocompletion features); etc... But I don't have a clear list at the moment so please do not consider my notes a blocker. I am working at a POC for a best practice Groovy service implementation and this should end up with a wish list of features I would like to have. Then we can discuss the best way to achieve this. Jacopo On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote: If you don't mind, I would like to get all of the issues resolved during the design phase. I will wait for the private email to understand what you mean by a secure scripting package. What I was suggesting is a script utility object that can be put in the context so that all scripting languages can use it. Whatever methods you have in
Re: Implementing JSR-223
On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
It seems to me if there is a security issue using Groovy, then there would be
an issue using any scripting language.
Yes, but what we would bundle ootb would be a secured packaged ready to run
Groovy scripts in a secure way and already packaged with hundreds of scripts.
If the user will add a new jar to support a different script (and the user will
also have to implement the custom scripts) then this will be less secure but
there isn't much we could do as we delegate to JSR-223 the implementation of
security.
Why can't we put the friendly methods in the context, so all scripting
languages can use them?
I am not sure I understand what you are proposing (the method would be language
specific) but for now we can postpone this discussion at when (if it will ever
happen) we will discuss about this approach.
Jacopo
-Adrian
On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
The code changes tested fine.
I noticed in your code comments that Groovy should be handled independently
from other scripting languages. Why do you think that?
First of all, I apologize for having added my personal opinion to those
comments :-) but I thought that in this way it was easier to exchange design
ideas; the comments can actually be removed.
The reasons I think we could treat Groovy in a special way (but I don't have
a strong opinion on this) are:
* ootb OFBiz will still be packaged with Groovy jars (they are required by
all the existing scripts and by some other code like the implementation of
Groovy service engine and Groovy event handler) and so the dependency on
Groovy will still be there even if we run it with JSR-223
* the code to run Groovy in the special way is now all contained in the
ScriptUtil class and there are actually a few lines of code to maintain for
it
* keeping a custom way for Groovy has two main advantages that are not
currently used but I would like to consider in the short term (and I don't
think they are supported thru JSR-223... but I am not sure):
** security: I would like to restrict the JVM security settings for dynamic
Groovy snippets like ${groovy: ...}; I have some concerns in this area that
I will address in a separate email soon; in this way we will secure the
ootb system (packaged with several groovy scripts and the groovy jars) but
of course if the user will add to it jars files for a new scripting language
(executed using JSR-223) then the security issue will still be there, but at
least the user will know about it
** I would like to inject some OFBiz friendly methods to all Groovy scripts,
so that they can be used by Groovy scripts to run services, use the
delegator etc...
We should also consider the impact on performance, even if the best way to
go is probably to run some performance tests on the system running Groovy
with current code and with the system running Groovy using a custom method
and then compare the results.
Jacopo
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
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.
Adrian, FYI I am enhancing some of the existing framework code that uses
the GroovyUtil class to simplify this task.
I will commit my code changes today.
Regards,
Jacopo
Re: Implementing JSR-223
On Mar 5, 2012, at 8:57 AM, Adrian Crum wrote:
Btw, expressions should go in the from-field attribute, not the value
attribute.
Well, the mechanism value=${groovy: ...} is actually used a lot currently;
and in the from-field attribute the ${groovy: is not required.
Jacopo
Re: Implementing JSR-223
If you don't mind, I would like to get all of the issues resolved during
the design phase.
I will wait for the private email to understand what you mean by a
secure scripting package.
What I was suggesting is a script utility object that can be put in the
context so that all scripting languages can use it. Whatever methods you
have in mind could be implemented in a generic way and reused.
Personally, I would like to use something like:
// Groovy, JavaScript
partyValue = script.entityOne(Party);
if (partyValue)...
In other words, have an object in the context that gives us the
convenience of mini-language.
-Adrian
On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
It seems to me if there is a security issue using Groovy, then there would be
an issue using any scripting language.
Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy
scripts in a secure way and already packaged with hundreds of scripts.
If the user will add a new jar to support a different script (and the user will
also have to implement the custom scripts) then this will be less secure but
there isn't much we could do as we delegate to JSR-223 the implementation of
security.
Why can't we put the friendly methods in the context, so all scripting
languages can use them?
I am not sure I understand what you are proposing (the method would be language
specific) but for now we can postpone this discussion at when (if it will ever
happen) we will discuss about this approach.
Jacopo
-Adrian
On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
The code changes tested fine.
I noticed in your code comments that Groovy should be handled independently
from other scripting languages. Why do you think that?
First of all, I apologize for having added my personal opinion to those
comments :-) but I thought that in this way it was easier to exchange design
ideas; the comments can actually be removed.
The reasons I think we could treat Groovy in a special way (but I don't have a
strong opinion on this) are:
* ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts
and by some other code like the implementation of Groovy service engine and
Groovy event handler) and so the dependency on Groovy will still be there even if we
run it with JSR-223
* the code to run Groovy in the special way is now all contained in the
ScriptUtil class and there are actually a few lines of code to maintain for it
* keeping a custom way for Groovy has two main advantages that are not
currently used but I would like to consider in the short term (and I don't
think they are supported thru JSR-223... but I am not sure):
** security: I would like to restrict the JVM security settings for dynamic Groovy
snippets like ${groovy: ...}; I have some concerns in this area that I will address in a
separate email soon; in this way we will secure the ootb system (packaged
with several groovy scripts and the groovy jars) but of course if the user will add to it
jars files for a new scripting language (executed using JSR-223) then the security issue
will still be there, but at least the user will know about it
** I would like to inject some OFBiz friendly methods to all Groovy scripts, so
that they can be used by Groovy scripts to run services, use the delegator
etc...
We should also consider the impact on performance, even if the best way to go
is probably to run some performance tests on the system running Groovy with
current code and with the system running Groovy using a custom method and then
compare the results.
Jacopo
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
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.
Adrian, FYI I am enhancing some of the existing framework code that uses the
GroovyUtil class to simplify this task.
I will commit my code changes today.
Regards,
Jacopo
Re: Implementing JSR-223
From: Adrian Crum adrian.c...@sandglass-software.com
Okay, we can give it a try and see if we run into any problems.
Btw, expressions should go in the from-field attribute, not the value attribute.
Why? I'd prefer to stay the same than now. I agree it's a convention, but from-field makes less sense to me for evaluated
expressions (being in a script or inlined)
Jacques
-Adrian
On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
Yes, this is fine and I was thinking about a similar solution; however I would
like to find a simpler convention because
[script:groovy] is a lot of typing and could be difficult to read when the code in buried in the
value attribute of a set
element.
Something like:
${script:jython code_here}
${script:groovy code_here}
${script: code_here} this could use the default language set in some properties file
(i.e. groovy); this follows the
configuration by exception pattern (specify the script only if you want to
use a non default one).
But we should also consider a shortcut where the script word is abbreviated, for
example by the s word:
${s:jython code_here}
${s:groovy code_here}
${s: code_here}
Jacopo
On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
I was thinking we could use something like ${[script:groovy]...}
${[script:jython]...} etc. I'm concerned that looking for a
string followed by a colon can lead to errors.
-Adrian
On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
I would like to clarify that in this first pass I focused on moving code
around keeping the same exact behavior currently
implemented: now all the code that had a dependency on Groovy or Beanshell
packages has been converted to be only dependent on
ScriptUtil class.
In order to implement JSR-223 we may have to change some of the current
behavior (the different way Beanshell and Groovy are
preparsed/executed) and also check if we can always assume that if the code
inside of ${...} starts with a string (no spaces)
followed by a colon (and a blank character?) then the string is the scripting
language: I didn't check the impact on existing
scripts but it should be easy to write a reg exp to find all of them (I expect
that the number will be small) and modify them
to be compatible with the convention. I intentionally didn't focus on this
second step.
Jacopo
On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
I must says I only cursorily reviewed the code Jacopo committed and did not
look into JSR-223 details.
So I thought at some point you have to check which language wich is used?
Like in
+if (groovy.equals(language)) {
+if (scriptClass == null) {
+scriptClass = ScriptUtil.parseScript(language, script);
+}
+if (scriptClass != null) {
+result = InvokerHelper.createScript(scriptClass,
GroovyUtil.getBinding(inputMap)).run();
+}
+} else if (bsh.equals(language)) {
+result = BshUtil.eval(script, UtilMisc.makeMapWritable(inputMap));
+}
In other words from Jacopo's code here, it seems you have to differentiate how
scritps are parsed?
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Groovy supports JSR-223, so there is no reason to treat it differently. My
question has nothing to do with which scripting
engine
is supplied with OFBiz.
-Adrian
On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess it's because Groovy
will be implemented OOTB. The others could be
but
Groovy is already part of the framework (the inital subject from Erwan was to
completely remove BeanShell OOTB usage), I
mean
it's the idea and what Jacopo said already.
I second this idea. Everybody can use her/his preferred scripting language in
custom projects. But using only one language
OOTB
seems to be common sense. We chose groovy...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
The code changes tested fine.
I noticed in your code comments that Groovy should be handled independently
from other scripting languages. Why do you
think
that?
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
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.
Adrian, FYI I am enhancing some of the existing framework code that uses the
GroovyUtil class to simplify this task.
I will commit my code changes today.
Regards,
Jacopo
Re: Implementing JSR-223
Because the value attribute is supposed to represent a string constant
(that can be converted to another type via the type attribute), and the
from-field attribute is supposed to represent a variable.
My preference is to have a from-expression attribute to make things clearer.
From my perspective, the main reason mini-language has such strange and
quirky behavior is because the syntax has not been clearly expressed or
implemented.
-Adrian
On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
From: Adrian Crum adrian.c...@sandglass-software.com
Okay, we can give it a try and see if we run into any problems.
Btw, expressions should go in the from-field attribute, not the value
attribute.
Why? I'd prefer to stay the same than now. I agree it's a convention,
but from-field makes less sense to me for evaluated expressions (being
in a script or inlined)
Jacques
-Adrian
On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
Yes, this is fine and I was thinking about a similar solution;
however I would like to find a simpler convention because
[script:groovy] is a lot of typing and could be difficult to read
when the code in buried in the value attribute of a set
element.
Something like:
${script:jython code_here}
${script:groovy code_here}
${script: code_here} this could use the default language set in
some properties file (i.e. groovy); this follows the
configuration by exception pattern (specify the script only if you
want to use a non default one).
But we should also consider a shortcut where the script word is
abbreviated, for example by the s word:
${s:jython code_here}
${s:groovy code_here}
${s: code_here}
Jacopo
On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
I was thinking we could use something like ${[script:groovy]...}
${[script:jython]...} etc. I'm concerned that looking for a
string followed by a colon can lead to errors.
-Adrian
On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
I would like to clarify that in this first pass I focused on
moving code around keeping the same exact behavior currently
implemented: now all the code that had a dependency on Groovy or
Beanshell packages has been converted to be only dependent on
ScriptUtil class.
In order to implement JSR-223 we may have to change some of the
current behavior (the different way Beanshell and Groovy are
preparsed/executed) and also check if we can always assume that if
the code inside of ${...} starts with a string (no spaces)
followed by a colon (and a blank character?) then the string is
the scripting language: I didn't check the impact on existing
scripts but it should be easy to write a reg exp to find all of
them (I expect that the number will be small) and modify them
to be compatible with the convention. I intentionally didn't focus
on this second step.
Jacopo
On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
I must says I only cursorily reviewed the code Jacopo committed
and did not look into JSR-223 details.
So I thought at some point you have to check which language wich
is used?
Like in
+if (groovy.equals(language)) {
+if (scriptClass == null) {
+scriptClass = ScriptUtil.parseScript(language,
script);
+}
+if (scriptClass != null) {
+result = InvokerHelper.createScript(scriptClass,
GroovyUtil.getBinding(inputMap)).run();
+}
+} else if (bsh.equals(language)) {
+result = BshUtil.eval(script,
UtilMisc.makeMapWritable(inputMap));
+}
In other words from Jacopo's code here, it seems you have to
differentiate how scritps are parsed?
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Groovy supports JSR-223, so there is no reason to treat it
differently. My question has nothing to do with which scripting
engine
is supplied with OFBiz.
-Adrian
On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess it's
because Groovy will be implemented OOTB. The others could be
but
Groovy is already part of the framework (the inital subject
from Erwan was to completely remove BeanShell OOTB usage), I
mean
it's the idea and what Jacopo said already.
I second this idea. Everybody can use her/his preferred
scripting language in custom projects. But using only one language
OOTB
seems to be common sense. We chose groovy...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
The code changes tested fine.
I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you
think
that?
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
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
Re: Implementing JSR-223
Le 05/03/2012 10:08, Adrian Crum a écrit :
Because the value attribute is supposed to represent a string constant
(that can be converted to another type via the type attribute), and
the from-field attribute is supposed to represent a variable.
My preference is to have a from-expression attribute to make things
clearer.
Same opinion, the from-expression miss to separate the value origin:
* from-field : provide only from existent context field
* value : only given value (Parsing by the given type)
* from-expression : calling script interface to resolve value.
From my perspective, the main reason mini-language has such strange
and quirky behavior is because the syntax has not been clearly
expressed or implemented.
-Adrian
On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
From: Adrian Crum adrian.c...@sandglass-software.com
Okay, we can give it a try and see if we run into any problems.
Btw, expressions should go in the from-field attribute, not the
value attribute.
Why? I'd prefer to stay the same than now. I agree it's a convention,
but from-field makes less sense to me for evaluated expressions
(being in a script or inlined)
Jacques
-Adrian
On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
Yes, this is fine and I was thinking about a similar solution;
however I would like to find a simpler convention because
[script:groovy] is a lot of typing and could be difficult to read
when the code in buried in the value attribute of a set
element.
Something like:
${script:jython code_here}
${script:groovy code_here}
${script: code_here} this could use the default language set in
some properties file (i.e. groovy); this follows the
configuration by exception pattern (specify the script only if
you want to use a non default one).
But we should also consider a shortcut where the script word is
abbreviated, for example by the s word:
${s:jython code_here}
${s:groovy code_here}
${s: code_here}
Jacopo
On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
I was thinking we could use something like ${[script:groovy]...}
${[script:jython]...} etc. I'm concerned that looking for a
string followed by a colon can lead to errors.
-Adrian
On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
I would like to clarify that in this first pass I focused on
moving code around keeping the same exact behavior currently
implemented: now all the code that had a dependency on Groovy or
Beanshell packages has been converted to be only dependent on
ScriptUtil class.
In order to implement JSR-223 we may have to change some of the
current behavior (the different way Beanshell and Groovy are
preparsed/executed) and also check if we can always assume that
if the code inside of ${...} starts with a string (no spaces)
followed by a colon (and a blank character?) then the string is
the scripting language: I didn't check the impact on existing
scripts but it should be easy to write a reg exp to find all of
them (I expect that the number will be small) and modify them
to be compatible with the convention. I intentionally didn't
focus on this second step.
Jacopo
On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
I must says I only cursorily reviewed the code Jacopo committed
and did not look into JSR-223 details.
So I thought at some point you have to check which language wich
is used?
Like in
+if (groovy.equals(language)) {
+if (scriptClass == null) {
+scriptClass = ScriptUtil.parseScript(language,
script);
+}
+if (scriptClass != null) {
+result =
InvokerHelper.createScript(scriptClass,
GroovyUtil.getBinding(inputMap)).run();
+}
+} else if (bsh.equals(language)) {
+result = BshUtil.eval(script,
UtilMisc.makeMapWritable(inputMap));
+}
In other words from Jacopo's code here, it seems you have to
differentiate how scritps are parsed?
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Groovy supports JSR-223, so there is no reason to treat it
differently. My question has nothing to do with which scripting
engine
is supplied with OFBiz.
-Adrian
On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess
it's because Groovy will be implemented OOTB. The others could be
but
Groovy is already part of the framework (the inital subject
from Erwan was to completely remove BeanShell OOTB usage), I
mean
it's the idea and what Jacopo said already.
I second this idea. Everybody can use her/his preferred
scripting language in custom projects. But using only one
language
OOTB
seems to be common sense. We chose groovy...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
The code changes tested fine.
I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you
think
that?
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help
Re: Implementing JSR-223
Mmm... from-expression indeed This remembered me a discussion we had already
http://markmail.org/message/dzljmdhg2c3i52aq
No time to re-read at the moment, but yes from-expression sounds good to me and
not that hard to change in current code.
Jacques
From: Adrian Crum adrian.c...@sandglass-software.com
Because the value attribute is supposed to represent a string constant
(that can be converted to another type via the type attribute), and the
from-field attribute is supposed to represent a variable.
My preference is to have a from-expression attribute to make things clearer.
From my perspective, the main reason mini-language has such strange and
quirky behavior is because the syntax has not been clearly expressed or
implemented.
-Adrian
On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
From: Adrian Crum adrian.c...@sandglass-software.com
Okay, we can give it a try and see if we run into any problems.
Btw, expressions should go in the from-field attribute, not the value
attribute.
Why? I'd prefer to stay the same than now. I agree it's a convention,
but from-field makes less sense to me for evaluated expressions (being
in a script or inlined)
Jacques
-Adrian
On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
Yes, this is fine and I was thinking about a similar solution;
however I would like to find a simpler convention because
[script:groovy] is a lot of typing and could be difficult to read
when the code in buried in the value attribute of a set
element.
Something like:
${script:jython code_here}
${script:groovy code_here}
${script: code_here} this could use the default language set in
some properties file (i.e. groovy); this follows the
configuration by exception pattern (specify the script only if you
want to use a non default one).
But we should also consider a shortcut where the script word is
abbreviated, for example by the s word:
${s:jython code_here}
${s:groovy code_here}
${s: code_here}
Jacopo
On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
I was thinking we could use something like ${[script:groovy]...}
${[script:jython]...} etc. I'm concerned that looking for a
string followed by a colon can lead to errors.
-Adrian
On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
I would like to clarify that in this first pass I focused on
moving code around keeping the same exact behavior currently
implemented: now all the code that had a dependency on Groovy or
Beanshell packages has been converted to be only dependent on
ScriptUtil class.
In order to implement JSR-223 we may have to change some of the
current behavior (the different way Beanshell and Groovy are
preparsed/executed) and also check if we can always assume that if
the code inside of ${...} starts with a string (no spaces)
followed by a colon (and a blank character?) then the string is
the scripting language: I didn't check the impact on existing
scripts but it should be easy to write a reg exp to find all of
them (I expect that the number will be small) and modify them
to be compatible with the convention. I intentionally didn't focus
on this second step.
Jacopo
On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
I must says I only cursorily reviewed the code Jacopo committed
and did not look into JSR-223 details.
So I thought at some point you have to check which language wich
is used?
Like in
+if (groovy.equals(language)) {
+if (scriptClass == null) {
+scriptClass = ScriptUtil.parseScript(language,
script);
+}
+if (scriptClass != null) {
+result = InvokerHelper.createScript(scriptClass,
GroovyUtil.getBinding(inputMap)).run();
+}
+} else if (bsh.equals(language)) {
+result = BshUtil.eval(script,
UtilMisc.makeMapWritable(inputMap));
+}
In other words from Jacopo's code here, it seems you have to
differentiate how scritps are parsed?
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Groovy supports JSR-223, so there is no reason to treat it
differently. My question has nothing to do with which scripting
engine
is supplied with OFBiz.
-Adrian
On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess it's
because Groovy will be implemented OOTB. The others could be
but
Groovy is already part of the framework (the inital subject
from Erwan was to completely remove BeanShell OOTB usage), I
mean
it's the idea and what Jacopo said already.
I second this idea. Everybody can use her/his preferred
scripting language in custom projects. But using only one language
OOTB
seems to be common sense. We chose groovy...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
The code changes tested fine.
I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you
think
that?
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit
Re: Implementing JSR-223
From: Nicolas Malin malin.nico...@librenberry.net
Le 05/03/2012 10:08, Adrian Crum a écrit :
Because the value attribute is supposed to represent a string constant (that can be converted to another type via the type
attribute), and the from-field attribute is supposed to represent a variable.
My preference is to have a from-expression attribute to make things clearer.
Same opinion, the from-expression miss to separate the value origin:
I guess you meant from-field above ;o)
Jacques
* from-field : provide only from existent context field
* value : only given value (Parsing by the given type)
* from-expression : calling script interface to resolve value.
From my perspective, the main reason mini-language has such strange and quirky behavior is because the syntax has not been
clearly expressed or implemented.
-Adrian
On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
From: Adrian Crum adrian.c...@sandglass-software.com
Okay, we can give it a try and see if we run into any problems.
Btw, expressions should go in the from-field attribute, not the value attribute.
Why? I'd prefer to stay the same than now. I agree it's a convention, but from-field makes less sense to me for evaluated
expressions (being in a script or inlined)
Jacques
-Adrian
On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
Yes, this is fine and I was thinking about a similar solution; however I would
like to find a simpler convention because
[script:groovy] is a lot of typing and could be difficult to read when the code in buried in the
value attribute of a set
element.
Something like:
${script:jython code_here}
${script:groovy code_here}
${script: code_here} this could use the default language set in some properties file
(i.e. groovy); this follows the
configuration by exception pattern (specify the script only if you want to
use a non default one).
But we should also consider a shortcut where the script word is abbreviated, for
example by the s word:
${s:jython code_here}
${s:groovy code_here}
${s: code_here}
Jacopo
On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
I was thinking we could use something like ${[script:groovy]...}
${[script:jython]...} etc. I'm concerned that looking for a
string followed by a colon can lead to errors.
-Adrian
On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
I would like to clarify that in this first pass I focused on moving code
around keeping the same exact behavior currently
implemented: now all the code that had a dependency on Groovy or Beanshell packages has been converted to be only dependent
on
ScriptUtil class.
In order to implement JSR-223 we may have to change some of the current
behavior (the different way Beanshell and Groovy are
preparsed/executed) and also check if we can always assume that if the code inside of ${...} starts with a string (no
spaces)
followed by a colon (and a blank character?) then the string is the scripting language: I didn't check the impact on
existing
scripts but it should be easy to write a reg exp to find all of them (I expect that the number will be small) and modify
them
to be compatible with the convention. I intentionally didn't focus on this
second step.
Jacopo
On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
I must says I only cursorily reviewed the code Jacopo committed and did not
look into JSR-223 details.
So I thought at some point you have to check which language wich is used?
Like in
+if (groovy.equals(language)) {
+if (scriptClass == null) {
+scriptClass = ScriptUtil.parseScript(language, script);
+}
+if (scriptClass != null) {
+result = InvokerHelper.createScript(scriptClass,
GroovyUtil.getBinding(inputMap)).run();
+}
+} else if (bsh.equals(language)) {
+result = BshUtil.eval(script, UtilMisc.makeMapWritable(inputMap));
+}
In other words from Jacopo's code here, it seems you have to differentiate how
scritps are parsed?
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Groovy supports JSR-223, so there is no reason to treat it differently. My
question has nothing to do with which scripting
engine
is supplied with OFBiz.
-Adrian
On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess it's because Groovy will be implemented OOTB. The others could
be
but
Groovy is already part of the framework (the inital subject from Erwan was to
completely remove BeanShell OOTB usage), I
mean
it's the idea and what Jacopo said already.
I second this idea. Everybody can use her/his preferred scripting language in custom projects. But using only one
language
OOTB
seems to be common sense. We chose groovy...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
The code changes tested fine.
I noticed in your code comments that Groovy should be handled independently
from other scripting languages. Why do you
think
that?
-Adrian
On
Re: Implementing JSR-223
This could work but I was thinking to something more like having some core
packages (like entity and service) always imported in groovy scripts/services;
or having the delegator and dispatcher objects properly casted to their
interfaces (to take advantage of IDE autocompletion features); etc...
But I don't have a clear list at the moment so please do not consider my notes
a blocker.
I am working at a POC for a best practice Groovy service implementation and
this should end up with a wish list of features I would like to have. Then we
can discuss the best way to achieve this.
Jacopo
On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
If you don't mind, I would like to get all of the issues resolved during the
design phase.
I will wait for the private email to understand what you mean by a secure
scripting package.
What I was suggesting is a script utility object that can be put in the
context so that all scripting languages can use it. Whatever methods you have
in mind could be implemented in a generic way and reused. Personally, I would
like to use something like:
// Groovy, JavaScript
partyValue = script.entityOne(Party);
if (partyValue)...
In other words, have an object in the context that gives us the convenience
of mini-language.
-Adrian
On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
It seems to me if there is a security issue using Groovy, then there would
be an issue using any scripting language.
Yes, but what we would bundle ootb would be a secured packaged ready to run
Groovy scripts in a secure way and already packaged with hundreds of
scripts.
If the user will add a new jar to support a different script (and the user
will also have to implement the custom scripts) then this will be less
secure but there isn't much we could do as we delegate to JSR-223 the
implementation of security.
Why can't we put the friendly methods in the context, so all scripting
languages can use them?
I am not sure I understand what you are proposing (the method would be
language specific) but for now we can postpone this discussion at when (if
it will ever happen) we will discuss about this approach.
Jacopo
-Adrian
On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
The code changes tested fine.
I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you think that?
First of all, I apologize for having added my personal opinion to those
comments :-) but I thought that in this way it was easier to exchange
design ideas; the comments can actually be removed.
The reasons I think we could treat Groovy in a special way (but I don't
have a strong opinion on this) are:
* ootb OFBiz will still be packaged with Groovy jars (they are required by
all the existing scripts and by some other code like the implementation of
Groovy service engine and Groovy event handler) and so the dependency
on Groovy will still be there even if we run it with JSR-223
* the code to run Groovy in the special way is now all contained in the
ScriptUtil class and there are actually a few lines of code to maintain
for it
* keeping a custom way for Groovy has two main advantages that are not
currently used but I would like to consider in the short term (and I don't
think they are supported thru JSR-223... but I am not sure):
** security: I would like to restrict the JVM security settings for
dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this
area that I will address in a separate email soon; in this way we will
secure the ootb system (packaged with several groovy scripts and the
groovy jars) but of course if the user will add to it jars files for a new
scripting language (executed using JSR-223) then the security issue will
still be there, but at least the user will know about it
** I would like to inject some OFBiz friendly methods to all Groovy
scripts, so that they can be used by Groovy scripts to run services, use
the delegator etc...
We should also consider the impact on performance, even if the best way to
go is probably to run some performance tests on the system running Groovy
with current code and with the system running Groovy using a custom method
and then compare the results.
Jacopo
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
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
Re: Implementing JSR-223 (Was: Definitively remove beanshell from OFBiz)
I don't want to interfer with Jacopo's answer, but I guess it's because Groovy will be implemented OOTB. The others could be but Groovy is already part of the framework (the inital subject from Erwan was to completely remove BeanShell OOTB usage), I mean it's the idea and what Jacopo said already. I second this idea. Everybody can use her/his preferred scripting language in custom projects. But using only one language OOTB seems to be common sense. We chose groovy... Jacques From: Adrian Crum adrian.c...@sandglass-software.com The code changes tested fine. I noticed in your code comments that Groovy should be handled independently from other scripting languages. Why do you think that? -Adrian On 3/4/2012 7:27 AM, Jacopo Cappellato wrote: My changes are in commit 1296762 Help with reviews and tests will be very much appreciated. Jacopo On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote: On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote: 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. Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task. I will commit my code changes today. Regards, Jacopo
Re: Implementing JSR-223 (Was: Definitively remove beanshell from OFBiz)
Groovy supports JSR-223, so there is no reason to treat it differently. My question has nothing to do with which scripting engine is supplied with OFBiz. -Adrian On 3/4/2012 8:43 PM, Jacques Le Roux wrote: I don't want to interfer with Jacopo's answer, but I guess it's because Groovy will be implemented OOTB. The others could be but Groovy is already part of the framework (the inital subject from Erwan was to completely remove BeanShell OOTB usage), I mean it's the idea and what Jacopo said already. I second this idea. Everybody can use her/his preferred scripting language in custom projects. But using only one language OOTB seems to be common sense. We chose groovy... Jacques From: Adrian Crum adrian.c...@sandglass-software.com The code changes tested fine. I noticed in your code comments that Groovy should be handled independently from other scripting languages. Why do you think that? -Adrian On 3/4/2012 7:27 AM, Jacopo Cappellato wrote: My changes are in commit 1296762 Help with reviews and tests will be very much appreciated. Jacopo On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote: On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote: 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. Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task. I will commit my code changes today. Regards, Jacopo
Re: Implementing JSR-223 (Was: Definitively remove beanshell from OFBiz)
I must says I only cursorily reviewed the code Jacopo committed and did not
look into JSR-223 details.
So I thought at some point you have to check which language wich is used?
Like in
+if (groovy.equals(language)) {
+if (scriptClass == null) {
+scriptClass = ScriptUtil.parseScript(language, script);
+}
+if (scriptClass != null) {
+result = InvokerHelper.createScript(scriptClass,
GroovyUtil.getBinding(inputMap)).run();
+}
+} else if (bsh.equals(language)) {
+result = BshUtil.eval(script, UtilMisc.makeMapWritable(inputMap));
+}
In other words from Jacopo's code here, it seems you have to differentiate how
scritps are parsed?
Jacques
From: Adrian Crum adrian.c...@sandglass-software.com
Groovy supports JSR-223, so there is no reason to treat it differently. My
question has nothing to do with which scripting engine
is supplied with OFBiz.
-Adrian
On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess it's because Groovy
will be implemented OOTB. The others could be but
Groovy is already part of the framework (the inital subject from Erwan was to
completely remove BeanShell OOTB usage), I mean
it's the idea and what Jacopo said already.
I second this idea. Everybody can use her/his preferred scripting language in
custom projects. But using only one language OOTB
seems to be common sense. We chose groovy...
Jacques
From: Adrian Crum adrian.c...@sandglass-software.com
The code changes tested fine.
I noticed in your code comments that Groovy should be handled independently
from other scripting languages. Why do you think
that?
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
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.
Adrian, FYI I am enhancing some of the existing framework code that uses the
GroovyUtil class to simplify this task.
I will commit my code changes today.
Regards,
Jacopo
Re: Implementing JSR-223 (Was: Definitively remove beanshell from OFBiz)
No, the whole idea is to delegate that decision making to the
javax.script package.
-Adrian
On 3/4/2012 9:27 PM, Jacques Le Roux wrote:
I must says I only cursorily reviewed the code Jacopo committed and
did not look into JSR-223 details.
So I thought at some point you have to check which language wich is used?
Like in
+if (groovy.equals(language)) {
+if (scriptClass == null) {
+scriptClass = ScriptUtil.parseScript(language, script);
+}
+if (scriptClass != null) {
+result = InvokerHelper.createScript(scriptClass,
GroovyUtil.getBinding(inputMap)).run();
+}
+} else if (bsh.equals(language)) {
+result = BshUtil.eval(script,
UtilMisc.makeMapWritable(inputMap));
+}
In other words from Jacopo's code here, it seems you have to
differentiate how scritps are parsed?
Jacques
From: Adrian Crum adrian.c...@sandglass-software.com
Groovy supports JSR-223, so there is no reason to treat it
differently. My question has nothing to do with which scripting engine
is supplied with OFBiz.
-Adrian
On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess it's
because Groovy will be implemented OOTB. The others could be but
Groovy is already part of the framework (the inital subject from
Erwan was to completely remove BeanShell OOTB usage), I mean
it's the idea and what Jacopo said already.
I second this idea. Everybody can use her/his preferred scripting
language in custom projects. But using only one language OOTB
seems to be common sense. We chose groovy...
Jacques
From: Adrian Crum adrian.c...@sandglass-software.com
The code changes tested fine.
I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you think
that?
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
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.
Adrian, FYI I am enhancing some of the existing framework code
that uses the GroovyUtil class to simplify this task.
I will commit my code changes today.
Regards,
Jacopo
Re: Implementing JSR-223 (Was: Definitively remove beanshell from OFBiz)
I would like to clarify that in this first pass I focused on moving code
around keeping the same exact behavior currently implemented: now all the code
that had a dependency on Groovy or Beanshell packages has been converted to be
only dependent on ScriptUtil class.
In order to implement JSR-223 we may have to change some of the current
behavior (the different way Beanshell and Groovy are preparsed/executed) and
also check if we can always assume that if the code inside of ${...} starts
with a string (no spaces) followed by a colon (and a blank character?) then the
string is the scripting language: I didn't check the impact on existing scripts
but it should be easy to write a reg exp to find all of them (I expect that the
number will be small) and modify them to be compatible with the convention. I
intentionally didn't focus on this second step.
Jacopo
On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
I must says I only cursorily reviewed the code Jacopo committed and did not
look into JSR-223 details.
So I thought at some point you have to check which language wich is used?
Like in
+if (groovy.equals(language)) {
+if (scriptClass == null) {
+scriptClass = ScriptUtil.parseScript(language, script);
+}
+if (scriptClass != null) {
+result = InvokerHelper.createScript(scriptClass,
GroovyUtil.getBinding(inputMap)).run();
+}
+} else if (bsh.equals(language)) {
+result = BshUtil.eval(script,
UtilMisc.makeMapWritable(inputMap));
+}
In other words from Jacopo's code here, it seems you have to differentiate
how scritps are parsed?
Jacques
From: Adrian Crum adrian.c...@sandglass-software.com
Groovy supports JSR-223, so there is no reason to treat it differently. My
question has nothing to do with which scripting engine
is supplied with OFBiz.
-Adrian
On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess it's because
Groovy will be implemented OOTB. The others could be but
Groovy is already part of the framework (the inital subject from Erwan was
to completely remove BeanShell OOTB usage), I mean
it's the idea and what Jacopo said already.
I second this idea. Everybody can use her/his preferred scripting language
in custom projects. But using only one language OOTB
seems to be common sense. We chose groovy...
Jacques
From: Adrian Crum adrian.c...@sandglass-software.com
The code changes tested fine.
I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you think
that?
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
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.
Adrian, FYI I am enhancing some of the existing framework code that uses
the GroovyUtil class to simplify this task.
I will commit my code changes today.
Regards,
Jacopo
Re: Implementing JSR-223 (Was: Definitively remove beanshell from OFBiz)
On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
The code changes tested fine.
I noticed in your code comments that Groovy should be handled independently
from other scripting languages. Why do you think that?
First of all, I apologize for having added my personal opinion to those
comments :-) but I thought that in this way it was easier to exchange design
ideas; the comments can actually be removed.
The reasons I think we could treat Groovy in a special way (but I don't have a
strong opinion on this) are:
* ootb OFBiz will still be packaged with Groovy jars (they are required by all
the existing scripts and by some other code like the implementation of Groovy
service engine and Groovy event handler) and so the dependency on Groovy
will still be there even if we run it with JSR-223
* the code to run Groovy in the special way is now all contained in the
ScriptUtil class and there are actually a few lines of code to maintain for it
* keeping a custom way for Groovy has two main advantages that are not
currently used but I would like to consider in the short term (and I don't
think they are supported thru JSR-223... but I am not sure):
** security: I would like to restrict the JVM security settings for dynamic
Groovy snippets like ${groovy: ...}; I have some concerns in this area that I
will address in a separate email soon; in this way we will secure the ootb
system (packaged with several groovy scripts and the groovy jars) but of course
if the user will add to it jars files for a new scripting language (executed
using JSR-223) then the security issue will still be there, but at least the
user will know about it
** I would like to inject some OFBiz friendly methods to all Groovy scripts, so
that they can be used by Groovy scripts to run services, use the delegator
etc...
We should also consider the impact on performance, even if the best way to go
is probably to run some performance tests on the system running Groovy with
current code and with the system running Groovy using a custom method and then
compare the results.
Jacopo
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
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.
Adrian, FYI I am enhancing some of the existing framework code that uses
the GroovyUtil class to simplify this task.
I will commit my code changes today.
Regards,
Jacopo
Re: Implementing JSR-223
I was thinking we could use something like ${[script:groovy]...}
${[script:jython]...} etc. I'm concerned that looking for a string
followed by a colon can lead to errors.
-Adrian
On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
I would like to clarify that in this first pass I focused on moving code
around keeping the same exact behavior currently implemented: now all the code that
had a dependency on Groovy or Beanshell packages has been converted to be only dependent
on ScriptUtil class.
In order to implement JSR-223 we may have to change some of the current
behavior (the different way Beanshell and Groovy are preparsed/executed) and
also check if we can always assume that if the code inside of ${...} starts
with a string (no spaces) followed by a colon (and a blank character?) then the
string is the scripting language: I didn't check the impact on existing scripts
but it should be easy to write a reg exp to find all of them (I expect that the
number will be small) and modify them to be compatible with the convention. I
intentionally didn't focus on this second step.
Jacopo
On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
I must says I only cursorily reviewed the code Jacopo committed and did not
look into JSR-223 details.
So I thought at some point you have to check which language wich is used?
Like in
+if (groovy.equals(language)) {
+if (scriptClass == null) {
+scriptClass = ScriptUtil.parseScript(language, script);
+}
+if (scriptClass != null) {
+result = InvokerHelper.createScript(scriptClass,
GroovyUtil.getBinding(inputMap)).run();
+}
+} else if (bsh.equals(language)) {
+result = BshUtil.eval(script, UtilMisc.makeMapWritable(inputMap));
+}
In other words from Jacopo's code here, it seems you have to differentiate how
scritps are parsed?
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Groovy supports JSR-223, so there is no reason to treat it differently. My
question has nothing to do with which scripting engine
is supplied with OFBiz.
-Adrian
On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess it's because Groovy
will be implemented OOTB. The others could be but
Groovy is already part of the framework (the inital subject from Erwan was to
completely remove BeanShell OOTB usage), I mean
it's the idea and what Jacopo said already.
I second this idea. Everybody can use her/his preferred scripting language in
custom projects. But using only one language OOTB
seems to be common sense. We chose groovy...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
The code changes tested fine.
I noticed in your code comments that Groovy should be handled independently
from other scripting languages. Why do you think
that?
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
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.
Adrian, FYI I am enhancing some of the existing framework code that uses the
GroovyUtil class to simplify this task.
I will commit my code changes today.
Regards,
Jacopo
Re: Implementing JSR-223
It seems to me if there is a security issue using Groovy, then there
would be an issue using any scripting language.
Why can't we put the friendly methods in the context, so all scripting
languages can use them?
-Adrian
On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
The code changes tested fine.
I noticed in your code comments that Groovy should be handled independently
from other scripting languages. Why do you think that?
First of all, I apologize for having added my personal opinion to those
comments :-) but I thought that in this way it was easier to exchange design
ideas; the comments can actually be removed.
The reasons I think we could treat Groovy in a special way (but I don't have a
strong opinion on this) are:
* ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts
and by some other code like the implementation of Groovy service engine and
Groovy event handler) and so the dependency on Groovy will still be there even if we
run it with JSR-223
* the code to run Groovy in the special way is now all contained in the
ScriptUtil class and there are actually a few lines of code to maintain for it
* keeping a custom way for Groovy has two main advantages that are not
currently used but I would like to consider in the short term (and I don't
think they are supported thru JSR-223... but I am not sure):
** security: I would like to restrict the JVM security settings for dynamic Groovy
snippets like ${groovy: ...}; I have some concerns in this area that I will address in a
separate email soon; in this way we will secure the ootb system (packaged
with several groovy scripts and the groovy jars) but of course if the user will add to it
jars files for a new scripting language (executed using JSR-223) then the security issue
will still be there, but at least the user will know about it
** I would like to inject some OFBiz friendly methods to all Groovy scripts, so
that they can be used by Groovy scripts to run services, use the delegator
etc...
We should also consider the impact on performance, even if the best way to go
is probably to run some performance tests on the system running Groovy with
current code and with the system running Groovy using a custom method and then
compare the results.
Jacopo
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
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.
Adrian, FYI I am enhancing some of the existing framework code that uses the
GroovyUtil class to simplify this task.
I will commit my code changes today.
Regards,
Jacopo
Re: Implementing JSR-223
Yes, this is fine and I was thinking about a similar solution; however I would
like to find a simpler convention because [script:groovy] is a lot of typing
and could be difficult to read when the code in buried in the value attribute
of a set element.
Something like:
${script:jython code_here}
${script:groovy code_here}
${script: code_here} this could use the default language set in some
properties file (i.e. groovy); this follows the configuration by exception
pattern (specify the script only if you want to use a non default one).
But we should also consider a shortcut where the script word is abbreviated,
for example by the s word:
${s:jython code_here}
${s:groovy code_here}
${s: code_here}
Jacopo
On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
I was thinking we could use something like ${[script:groovy]...}
${[script:jython]...} etc. I'm concerned that looking for a string followed
by a colon can lead to errors.
-Adrian
On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
I would like to clarify that in this first pass I focused on moving code
around keeping the same exact behavior currently implemented: now all the
code that had a dependency on Groovy or Beanshell packages has been
converted to be only dependent on ScriptUtil class.
In order to implement JSR-223 we may have to change some of the current
behavior (the different way Beanshell and Groovy are preparsed/executed) and
also check if we can always assume that if the code inside of ${...} starts
with a string (no spaces) followed by a colon (and a blank character?) then
the string is the scripting language: I didn't check the impact on existing
scripts but it should be easy to write a reg exp to find all of them (I
expect that the number will be small) and modify them to be compatible with
the convention. I intentionally didn't focus on this second step.
Jacopo
On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
I must says I only cursorily reviewed the code Jacopo committed and did not
look into JSR-223 details.
So I thought at some point you have to check which language wich is used?
Like in
+if (groovy.equals(language)) {
+if (scriptClass == null) {
+scriptClass = ScriptUtil.parseScript(language, script);
+}
+if (scriptClass != null) {
+result = InvokerHelper.createScript(scriptClass,
GroovyUtil.getBinding(inputMap)).run();
+}
+} else if (bsh.equals(language)) {
+result = BshUtil.eval(script,
UtilMisc.makeMapWritable(inputMap));
+}
In other words from Jacopo's code here, it seems you have to differentiate
how scritps are parsed?
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Groovy supports JSR-223, so there is no reason to treat it differently. My
question has nothing to do with which scripting engine
is supplied with OFBiz.
-Adrian
On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess it's because
Groovy will be implemented OOTB. The others could be but
Groovy is already part of the framework (the inital subject from Erwan
was to completely remove BeanShell OOTB usage), I mean
it's the idea and what Jacopo said already.
I second this idea. Everybody can use her/his preferred scripting
language in custom projects. But using only one language OOTB
seems to be common sense. We chose groovy...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
The code changes tested fine.
I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you think
that?
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
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.
Adrian, FYI I am enhancing some of the existing framework code that
uses the GroovyUtil class to simplify this task.
I will commit my code changes today.
Regards,
Jacopo
Re: Implementing JSR-223
Okay, we can give it a try and see if we run into any problems.
Btw, expressions should go in the from-field attribute, not the value
attribute.
-Adrian
On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
Yes, this is fine and I was thinking about a similar solution; however I would like to find a
simpler convention because [script:groovy] is a lot of typing and could be difficult to read when
the code in buried in the value attribute of a set element.
Something like:
${script:jython code_here}
${script:groovy code_here}
${script: code_here} this could use the default language set in some properties file (i.e.
groovy); this follows the configuration by exception pattern (specify the script only
if you want to use a non default one).
But we should also consider a shortcut where the script word is abbreviated, for
example by the s word:
${s:jython code_here}
${s:groovy code_here}
${s: code_here}
Jacopo
On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
I was thinking we could use something like ${[script:groovy]...}
${[script:jython]...} etc. I'm concerned that looking for a string followed by
a colon can lead to errors.
-Adrian
On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
I would like to clarify that in this first pass I focused on moving code
around keeping the same exact behavior currently implemented: now all the code that
had a dependency on Groovy or Beanshell packages has been converted to be only dependent
on ScriptUtil class.
In order to implement JSR-223 we may have to change some of the current
behavior (the different way Beanshell and Groovy are preparsed/executed) and
also check if we can always assume that if the code inside of ${...} starts
with a string (no spaces) followed by a colon (and a blank character?) then the
string is the scripting language: I didn't check the impact on existing scripts
but it should be easy to write a reg exp to find all of them (I expect that the
number will be small) and modify them to be compatible with the convention. I
intentionally didn't focus on this second step.
Jacopo
On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
I must says I only cursorily reviewed the code Jacopo committed and did not
look into JSR-223 details.
So I thought at some point you have to check which language wich is used?
Like in
+if (groovy.equals(language)) {
+if (scriptClass == null) {
+scriptClass = ScriptUtil.parseScript(language, script);
+}
+if (scriptClass != null) {
+result = InvokerHelper.createScript(scriptClass,
GroovyUtil.getBinding(inputMap)).run();
+}
+} else if (bsh.equals(language)) {
+result = BshUtil.eval(script, UtilMisc.makeMapWritable(inputMap));
+}
In other words from Jacopo's code here, it seems you have to differentiate how
scritps are parsed?
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Groovy supports JSR-223, so there is no reason to treat it differently. My
question has nothing to do with which scripting engine
is supplied with OFBiz.
-Adrian
On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess it's because Groovy
will be implemented OOTB. The others could be but
Groovy is already part of the framework (the inital subject from Erwan was to
completely remove BeanShell OOTB usage), I mean
it's the idea and what Jacopo said already.
I second this idea. Everybody can use her/his preferred scripting language in
custom projects. But using only one language OOTB
seems to be common sense. We chose groovy...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
The code changes tested fine.
I noticed in your code comments that Groovy should be handled independently
from other scripting languages. Why do you think
that?
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
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.
Adrian, FYI I am enhancing some of the existing framework code that uses the
GroovyUtil class to simplify this task.
I will commit my code changes today.
Regards,
Jacopo
