A couple of additional comments:
* now that the commit has fixed all occurrencies, I would suggest that we do
not use Debug.log(...) anymore: it internally uses the ALWAYS level and so it
always prints the log, and this may not be obvious to the developer
* I agree that this should be backported
Hello,
I am thinking to backport similar changes that I did in this commit to
release branch 10.04 and 11.04. Such commit will not harm anyone on
production systems but can have better control on Debug.* message.
This is kind of bug fix because few Debug.log( statements exists in the
code base th
Okay, I lied - the bindings are preserved between evaluations.
So go ahead and make whatever changes you need to make.
-Adrian
On 3/14/2012 5:28 AM, Adrian Crum wrote:
The main reason is to supply a function/method argument if
modelService.invoke is not empty.
A script containing a function/
The main reason is to supply a function/method argument if
modelService.invoke is not empty.
A script containing a function/method is evaluated twice - once to
evaluate the script as a whole and then again to invoke the
function/method. Any bindings that were created/used in the first
evaluat
Adrian,
is there a reason for invoking the script from ScriptEngine and
ScriptEventHandler using:
Object resultObj =
ScriptUtil.executeScript(getLocation(modelService), modelService.invoke,
scriptContext, new Object[] { context });
rather than
Object resultObj =
Scri
Thanks Adrian!
Regards
Scott
On 14/03/2012, at 5:21 PM, Adrian Crum wrote:
> Oops. Good catch - will do!
>
> -Adrian
>
> On 3/14/2012 2:09 AM, Scott Gray wrote:
>> Hi Adrian,
>>
>> Your test references an application entity, could you switch it to using one
>> of the example entities?
>>
>>
Oops. Good catch - will do!
-Adrian
On 3/14/2012 2:09 AM, Scott Gray wrote:
Hi Adrian,
Your test references an application entity, could you switch it to using one of
the example entities?
Thanks
Scott
On 13/03/2012, at 12:20 PM, adri...@apache.org wrote:
Author: adrianc
Date: Mon Mar 12
Hi Adrian,
Your test references an application entity, could you switch it to using one of
the example entities?
Thanks
Scott
On 13/03/2012, at 12:20 PM, adri...@apache.org wrote:
> Author: adrianc
> Date: Mon Mar 12 23:20:55 2012
> New Revision: 1299924
>
> URL: http://svn.apache.org/viewvc?
Cool - thanks! My apologies - I had not given much thought to the object
construction sequence in that section of code.
I'm pretty sure I followed good concurrency practices overall, but there
is always a chance I missed something.
-Adrian
On 3/13/2012 3:49 PM, Jacopo Cappellato wrote:
This
This is now fixed in rev. 1300202
By the way: we will need to carefully review the way ScriptHelper/ContextHelper
are built (and especially how the context is passed) in order to make sure the
code is thread safe.
Jacopo
On Mar 13, 2012, at 11:42 AM, Jacopo Cappellato wrote:
> Ok thanks... it
[
https://issues.apache.org/jira/browse/OFBIZ-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13228452#comment-13228452
]
Olivier Heintz commented on OFBIZ-4688:
---
this modification was present in the first
oops... please ignore my last one (doesn't make much sense)
Jacopo
On Mar 13, 2012, at 4:34 PM, Jacopo Cappellato wrote:
> Adrian,
>
> are you sure it is ok to create a ScriptHelper in this way:
>
>public static ScriptHelper createScriptHelper(ScriptContext context) {
>if (helperF
Adrian,
are you sure it is ok to create a ScriptHelper in this way:
public static ScriptHelper createScriptHelper(ScriptContext context) {
if (helperFactory != null) {
return helperFactory.getInstance(context);
}
return null;
}
?
I think you need a ne
Yes, but I really think that, if we define what is part of the "core OFBiz
framework" we could even go with merging the "core code" into one component.
That would be even easier... but this is food for another day, I can survive
even if makeValue returns a Map for now.
Jacopo
On Mar 13, 2012,
On Mar 13, 2012, at 8:58 AM, Adrian Crum wrote:
>>> Could you share with the rest of us the limitations caused by the
>>> refactoring?
>
One annoying limitation is that, after switching from GroovyEngine to
ScriptEngine my IDE (I am using Idea) is no more able to debug my Groovy
services; thi
Yes, the arch-nemesis of innovation - component cross-dependency.
That's why the script helper needs a factory.
I was thinking we can insert a script component in between the service
and common component dependency. Move all of the script classes there -
*Util.java, event handlers, services en
Is there a reason for not returning a GenericValue from:
Map makeValue(String entityName)
?
Well, the good reason is probably the dependency issue between framework
components... in my opinion it would be a good time to start thinking to drop
it and consider the "core framework components"
I think that this is because of the way it is initialized:
ScriptContext scriptContext = new SimpleScriptContext();
ScriptHelper helper = createScriptHelper(scriptContext);
Jacopo
On Mar 13, 2012, at 11:42 AM, Jacopo Cappellato wrote:
> Ok thanks... it doesn't work for me becaus
Ok thanks... it doesn't work for me because the scriptType is set to UNKNOWN
instead of SERVICE... I am debugging it now.
Jacopo
On Mar 13, 2012, at 11:16 AM, Adrian Crum wrote:
> org.ofbiz.service.engine.ScriptEngine.java, line 85 and below.
>
> -Adrian
>
> On 3/13/2012 10:11 AM, Jacopo Capp
org.ofbiz.service.engine.ScriptEngine.java, line 85 and below.
-Adrian
On 3/13/2012 10:11 AM, Jacopo Cappellato wrote:
Hey Adrian,
a quick question before I dig into the details.
I am using the success(..)/error(...) methods to get a result Map (for
services) or result String (for Events) and
Hey Adrian,
a quick question before I dig into the details.
I am using the success(..)/error(...) methods to get a result Map (for
services) or result String (for Events) and I have noticed that in the new
implementation they are saved using the ContextHelper.putResults method.
Who is supposed t
On 3/13/2012 7:46 AM, Jacopo Cappellato wrote:
On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
Jacopo,
Could you share with the rest of us the limitations caused by the refactoring?
Definitely: I will review, study and use the new code and I will provide
feedback about the gaps I see.
Oh.
On Mar 13, 2012, at 7:59 AM, Adrian Crum wrote:
> Jacopo,
>
> Could you share with the rest of us the limitations caused by the refactoring?
>
Definitely: I will review, study and use the new code and I will provide
feedback about the gaps I see.
One thing that I am not sure I like is the fact
23 matches
Mail list logo
