Groovy compilation and @CompileStatic

Hi, With https://github.com/apache/ofbiz-framework/commit/231650e1b6 I fixed few errors that would not happen if we were using @CompileStatic  in Groovy files as mentioned at https://stackoverflow.com/questions/57982247/groovy-compiler-and-non-existing-call-method I vaguely remember having

Re: Groovy integration tests

Hi Gil, Nicolas, I agree it was a good thing to do. We just missed some information and documentation. I have added some at OFBIZ-12320 I have also replaced all groovy-test-suite by junit-test-suite in OOTB code. I still wonder why Eclipse proposes but does not accept groovy-test-suite

Re: Groovy tests fails in trunk (OK in 18.12)

Sorry for the buzz (and multiple description editions), it seems easier than I thought... Le 01/04/2024 à 12:55, Jacques Le Roux a écrit : Hi, Please have a look at https://issues.apache.org/jira/browse/OFBIZ-12985 TIA Jacques

Groovy tests fails in trunk (OK in 18.12)

Hi, Please have a look at https://issues.apache.org/jira/browse/OFBIZ-12985 TIA Jacques

Re: Debugging Groovy in Eclipse with JDK 17

(why line between 489 and the return seems not executed). But that's not our real issue at this stage. Note: I understand it's a closure where return is inside, but that still don't explain the phenomenon to me. Why the rest of the closure is bypassed, maybe a Groovy bug or, more likely, an Eclips

Re: Debugging Groovy in Eclipse with JDK 17

environment.": > https://lists.apache.org/thread/yxmdxy81ywwhldg8ml4foqls5df0hy8s > I applied Leila's advice, I tried many things at the point that I can't > remember all. But here are the main ones. > > I use last versions of Eclipse (2023-03) and Groovy plugins (5.0) &g

Debugging Groovy in Eclipse with JDK 17

main ones. I use last versions of Eclipse (2023-03) and Groovy plugins (5.0) The issue I'm still fighting is not working breakpoints in Groovy files. To test, I put a breakpoint at CommunicationEventServices.groovy[489], and launchsendEmailDated service from Webtools As breakpoints in Groovy are n

Re: Calling groovy from a form field

gt; containing the button would have on-event-update-area configured to update > the Product Measures form following a submit event. > > Please let us know how you get on. > > Dan. > > On Sun, 22 Jan 2023 at 04:19, Ernest Hocking > wrote: > > > Hi everyone > >

Re: Calling groovy from a form field

on. Dan. On Sun, 22 Jan 2023 at 04:19, Ernest Hocking wrote: > Hi everyone > > I'd like to use groovy to implement some business logic and call that logic > from a button in a form. > > E.g Add a button on the product measures form to calculate the volume > given a product

Calling groovy from a form field

Hi everyone I'd like to use groovy to implement some business logic and call that logic from a button in a form. E.g Add a button on the product measures form to calculate the volume given a product's dimensions.. I've tried

Calling groovy from a form field

Hi everyone I'd like to use groovy to implement some business logic and call that logic from a button in a form. E.g Add a button on the product measures form to calculate the volume given a product's dimensions.. I've tried

Re: Groovy Sandboxing

that disable by default this function. Nicolas On 21/09/2021 08:06, Jacques Le Roux wrote: Hi, The security reporter 'thiscodecc" created OFBIZ-12305 about "Groovy Program sandbox bypass". He suggested to use one of "the very mature solutions on the groovy sandbox on the m

Re: Groovy Sandboxing

I agree with you Jacques. If some fear are present, as impersonate we can load a specific permission and add a property that disable by default this function. Nicolas On 21/09/2021 08:06, Jacques Le Roux wrote: > Hi, > > The security reporter 'thiscodecc" created OFBIZ-12305

Groovy Sandboxing

Hi, The security reporter 'thiscodecc" created OFBIZ-12305 about "Groovy Program sandbox bypass". He suggested to use one of "the very mature solutions on the groovy sandbox on the market. You can refer to it.". I had a look. The best article was from Cédric Champeau

Re: Groovy integration tests

is terminate to move the groovy-test-suite to junit-test-suite, so no reason to remove the possibility to write test as script. Nicolas On 08/09/2021 15:30, Gil Portenseigne wrote: > Hello, > > Currently using release 18.12 for some project we got the habit to > develop using integratio

Groovy integration tests

Hello, Currently using release 18.12 for some project we got the habit to develop using integration test while developing in groovy. For that usage we use mainly : groovy-test-suite That allow coding tests in groovy script that do not need to be compiled for their execution and executing

Re: [ofbiz-framework] branch trunk updated: Improved: Convert EntitySyncServices.xml mini-lang to groovy

repository. danwatford pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git The following commit(s) were added to refs/heads/trunk by this push: new c654d9b Improved: Convert EntitySyncServices.xml mini-lang to groovy c654d9b is described below

Re: [ofbiz-framework] branch trunk updated: Improved: Convert EntitySyncServices.xml mini-lang to groovy

ramework.git > > > The following commit(s) were added to refs/heads/trunk by this push: > new c654d9b Improved: Convert EntitySyncServices.xml mini-lang to > groovy > c654d9b is described below > > commit c654d9bbcc31f2b3ea218914a56a9569c21d0f8d > Author: Daniel Watford >

Re: XML to Groovy conversions

but I could not spot it. I guess I confused with your which is not really complaining :) Jacques Le 16/05/2020 à 09:30, Suraj Khurana a écrit : Hello team, Recently we are working on a major refactoring task of minilnag to groovy conversion, which is commendable. I would like to add following

Re: Behavior of Groovy vs JUnit tests with test data

are currently not covered by the test in XML. Similar for the transitions between custRequestStatusIds some are forbidden and some are not and the test cases did not cover either. +1 for improvement (did not review) The issue is really that in Groovy when starting from a given data load

Re: Behavior of Groovy vs JUnit tests with test data

between custRequestStatusIds some are forbidden and some are not and the test cases did not cover either. The issue is really that in Groovy when starting from a given data load, the data is not refreshed/reset after a test case is run and hence I decided to do the testing of services in full

Re: Behavior of Groovy vs JUnit tests with test data

the class with @RunWith(SpringRunner.class) - tag every method that manipulates the entity data with @DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD) This has NOT been successful, hence a strong indication that running the cases in Groovy will make entity data

Re: Behavior of Groovy vs JUnit tests with test data

NOT been successful, hence a strong indication that running the cases in Groovy will make entity data manipulations to be sticky and not reverted for the subsequent test case run. I am going to rework my cases to run as JUnit test cases in a Java class. Warm regards Carsten > Am 03.09.2020 um 13

Behavior of Groovy vs JUnit tests with test data

Hi everyone, Recently, I did find that test cases actually are much easier to write in Groovy and hence I started doing that, but now I stumble across the fact that some of the Groovy tests seem to find changes applied to entities from previous tests. The behavior is the following: - I load

XML to Groovy conversions

Hello team, Recently we are working on a major refactoring task of minilnag to groovy conversion, which is commendable. I would like to add following points to be taken into consideration while doing the exact changes in the service: - Check and think of possible conversion to entity-auto

Re: Upgrade Gradle and Groovy

Thanks Jacques. I have created OFBIZ-11661 for this. Correction: Groovy version used in OFBiz trunk is 2.5.8, not 2.5.4 On 2020/05/04 13:10:42, Jacques Le Roux wrote: > Hi James, > > I trust a Jira fits > > Thanks > > Jacques > > Le 04/05/2020 à 14:54, Jame

Re: Upgrade Gradle and Groovy

Hi James, I trust a Jira fits Thanks Jacques Le 04/05/2020 à 14:54, James Yong a écrit : Hi all, Current Gradle version used in OFBiz trunk is 5.0. Propose to update to Gradle 6.3 which is the current stable version. Gradle 6.3 requires groovy 2.5.10., but Groovy version used in OFBiz

Upgrade Gradle and Groovy

Hi all, Current Gradle version used in OFBiz trunk is 5.0. Propose to update to Gradle 6.3 which is the current stable version. Gradle 6.3 requires groovy 2.5.10., but Groovy version used in OFBiz trunk is 2.5.4 Suggest to upgrade Groovy to 2.5.11 which is the current stable version

Re: svn commit: r1867927 - in /ofbiz/ofbiz-framework/trunk/applications/order: minilang/test/OrderTests.xml src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy

gt;>> > >>> -- > >>> Best Regards, > >>> Suraj Khurana > >>> Senior Technical Consultant > >>> > >>> On Thu, Oct 3, 2019 at 5:00 PM wrote: > >>> > >>>> Author: jleroux > >>>> Date:

Re: svn commit: r1867927 - in /ofbiz/ofbiz-framework/trunk/applications/order: minilang/test/OrderTests.xml src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy

g? -- Best Regards, Suraj Khurana Senior Technical Consultant On Thu, Oct 3, 2019 at 5:00 PM wrote: Author: jleroux Date: Thu Oct 3 11:30:28 2019 New Revision: 1867927 URL: http://svn.apache.org/viewvc?rev=1867927=rev Log: Improved: Convert testSendOrderChangeNotification to Groovy (OFBIZ-11

Re: svn commit: r1867927 - in /ofbiz/ofbiz-framework/trunk/applications/order: minilang/test/OrderTests.xml src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy

na > > Senior Technical Consultant > > > > On Thu, Oct 3, 2019 at 5:00 PM wrote: > > > >> Author: jleroux > >> Date: Thu Oct 3 11:30:28 2019 > >> New Revision: 1867927 > >> > >> URL: http://svn.apache.org/viewvc?rev=1867927=rev &g

Re: svn commit: r1867927 - in /ofbiz/ofbiz-framework/trunk/applications/order: minilang/test/OrderTests.xml src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy

d: Convert testSendOrderChangeNotification to Groovy (OFBIZ-11233) Tests pass Modified: ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/OrderTests.xml ofbiz/ofbiz-framework/trunk/applications/order/src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy Modified: ofbiz/ofbiz-framework/trunk/ap

Re: svn commit: r1867927 - in /ofbiz/ofbiz-framework/trunk/applications/order: minilang/test/OrderTests.xml src/main/groovy/org/apache/ofbiz/order/OrderTests.groovy

> New Revision: 1867927 > > URL: http://svn.apache.org/viewvc?rev=1867927=rev > Log: > Improved: Convert testSendOrderChangeNotification to Groovy > (OFBIZ-11233) > > Tests pass > > Modified: > > ofbiz/ofbiz-framework/trunk/applications/order/minilang/test/Orde

Re: Groovy Migration : createRequirementFromItemATP

Le 07/03/2020 à 10:42, Jacopo Cappellato a écrit : On Fri, Mar 6, 2020 at 7:31 PM Pierre Smits wrote: Hi Gil, If that other function ( createATPRequirementsForOrder service) has been in play since 2007, we can, i would say safely, assume that the createRequirementFromItemATP function/service

Re: Groovy Migration : createRequirementFromItemATP

On Fri, Mar 6, 2020 at 7:31 PM Pierre Smits wrote: > Hi Gil, > > If that other function ( createATPRequirementsForOrder service) has been in > play since 2007, we can, i would say safely, assume that the > createRequirementFromItemATP function/service can be removed from the > codebase

Re: Groovy Migration : createRequirementFromItemATP

Hi Gil, If that other function ( createATPRequirementsForOrder service) has been in play since 2007, we can, i would say safely, assume that the createRequirementFromItemATP function/service can be removed from the codebase immediately and port its removal to the 18.11 branch. No need to slate it

Groovy Migration : createRequirementFromItemATP

Hello ! While migrating createRequirementFromItemATP, i stumbled upon a comment from David Jones : > NOTE DEJ20090902: this service is not called > anywhere, instead the createATPRequirementsForOrder service (written in > Java) is called; why this is the case I don't know... --> I investigate a

Re: [jira] [Commented] (OFBIZ-10231) Convert ProductServices.xml mini lang to groovy

Le 05/03/2020 à 14:26, Nicolas Malin a écrit : Kelvin it's the nickname for Elvis ? Ah(?), OK Jacques

Re: [jira] [Commented] (OFBIZ-10231) Convert ProductServices.xml mini lang to groovy

^^ Kelvin syntax. Kelvin it's the nickname for Elvis ? Nicolas On 28/02/2020 21:08, Jacques Le Roux wrote: > Le 28/02/2020 à 17:49, ASF subversion and git services (Jira) a écrit : >> use kelvin syntax > > Hi Nicolas, Gil, > > Could you explain why you refer to Kelvin Syntax? pEpkey.asc

Re: [jira] [Commented] (OFBIZ-10231) Convert ProductServices.xml mini lang to groovy

Le 28/02/2020 à 17:49, ASF subversion and git services (Jira) a écrit : use kelvin syntax Hi Nicolas, Gil, Could you explain why you refer to Kelvin Syntax? TIA Jacques

Re: [ofbiz-framework] branch trunk updated: Improved: Convert ProductServices.xml mini lang to groovy (OFBIZ-10231)

Hi Nicolas, great, thanks for reviewing and improving the code! Please go ahead and commit, thanks, Michael Brohl ecomify GmbH - www.ecomify.de Am 27.02.20 um 16:22 schrieb Nicolas Malin: Michael, I have lot of improvement to share with your commit (groovy syntax, code simplification) Do

Re: [ofbiz-framework] branch trunk updated: Improved: Convert ProductServices.xml mini lang to groovy (OFBIZ-10231)

Michael, I have lot of improvement to share with your commit (groovy syntax, code simplification) Do you prefer keep the hand, or I commit directly ? You can find some diff on my starting work here  [1] Cheers, Nicolas [1] https://github.com/nmalin/ApacheOFBiz/compare/ProductService.groovy

Re: [ofbiz-plugins] branch release18.12 updated: Fixed: Error when initialize billFromParty from groovy context in loadSalesOrderItemFact service

/ofbiz-plugins.git The following commit(s) were added to refs/heads/release18.12 by this push: new 6296ab4 Fixed: Error when initialize billFromParty from groovy context in loadSalesOrderItemFact service 6296ab4 is described below commit 6296ab40782fa56fb29f0e9b766da1dfb49fbe71 Author:

Re: [ofbiz-plugins] branch release18.12 updated: Fixed: Error when initialize billFromParty from groovy context in loadSalesOrderItemFact service

>> nmalin pushed a commit to branch release18.12 > >> in repository https://gitbox.apache.org/repos/asf/ofbiz-plugins.git > >> > >> > >> The following commit(s) were added to refs/heads/release18.12 by this > push: > >> new 6296ab4 F

Re: [ofbiz-plugins] branch release18.12 updated: Fixed: Error when initialize billFromParty from groovy context in loadSalesOrderItemFact service

ded to refs/heads/release18.12 by this push: new 6296ab4 Fixed: Error when initialize billFromParty from groovy context in loadSalesOrderItemFact service 6296ab4 is described below commit 6296ab40782fa56fb29f0e9b766da1dfb49fbe71 Author: Nicolas Malin AuthorDate: Thu Feb 6 13:03:18 2020

Re: [ofbiz-plugins] branch release18.12 updated: Fixed: Error when initialize billFromParty from groovy context in loadSalesOrderItemFact service

automated email from the ASF dual-hosted git repository. > > nmalin pushed a commit to branch release18.12 > in repository https://gitbox.apache.org/repos/asf/ofbiz-plugins.git > > > The following commit(s) were added to refs/heads/release18.12 by this push: > new 6296ab4

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

; Apache Incubator <https://incubator.apache.org>, committer > > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without > privileges) > > since 2008* > > Apache Steve <https://steve.apache.org>, committer > > > > > > On Fri, Jan 31, 2020

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

stumbled upon this topic again, inline... Am 20.09.19 um 17:39 schrieb Jacques Le Roux: In a 1st time I intend to do only what I wrote in OFBIZ-10226, OFBIZ-10205 and this thread, ie indeed mostly "move them to src/main/groovy". That's enough for my need. Using @CompileStatic is out of my sco

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

> OFBIZ-10205 and this thread, ie indeed mostly "move them to > > src/main/groovy". That's enough for my need. > > > > Using @CompileStatic is out of my scope because I want to keep Groovy > > scripts dynamic. > > I'd like to bring up this thead again and e

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

Hi Jacques, just stumbled upon this topic again, inline... Am 20.09.19 um 17:39 schrieb Jacques Le Roux: In a 1st time I intend to do only what I wrote in OFBIZ-10226, OFBIZ-10205 and this thread, ie indeed mostly "move them to src/main/groovy". That's enough for my nee

Re: Upgrading Groovy 2.4.16 → 2.5.8

o, >> >> I have open OFBIZ-11263 [1] to upgrade Groovy to its latest stable >> release on ‘trunk’. >> >> I did not detect any issue with the upgrade so I intend to commit the >> patch in the following days. If you are aware of an issue please jump >> in.

Re: Upgrading Groovy 2.4.16 → 2.5.8

Hello Mathieu, I've test the upgrade and saw no issue, so +1. Gil Le 18:19 - dimanche 27 oct., Mathieu Lirzin a écrit : > Hello, > > I have open OFBIZ-11263 [1] to upgrade Groovy to its latest stable > release on ‘trunk’. > > I did not detect any issue with the u

Upgrading Groovy 2.4.16 → 2.5.8

Hello, I have open OFBIZ-11263 [1] to upgrade Groovy to its latest stable release on ‘trunk’. I did not detect any issue with the upgrade so I intend to commit the patch in the following days. If you are aware of an issue please jump in. Thanks. [1] https://issues.apache.org/jira/browse/OFBIZ

Re: svn commit: r1867666 - in /ofbiz/ofbiz-framework/trunk/applications: accounting/src/main/groovy/org/apache/ofbiz/accounting/ accounting/testdef/data/ order/src/main/groovy/org/apache/ofbiz/order/

turn > - processReplaceImmediatelyReturn > - processRefundOnlyReturn > > (OFBIZ-8936)(OFBIZ-8874)(OFBIZ-8873)(OFBIZ-8872)(OFBIZ-8871)(OFBIZ-8870)(OFBIZ-8866) > > Thanks, Deepak Nigam, Avnindra Sharma and Anushi Gupta for your > contribution. > > Modified: > > ofbiz/ofbiz

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

cks on our code! The option to use `gradlew --continous classes` make me think about putting more things into jar (but this another discussion ) I still have one question: what about `commponent://` url in xml (screen, service,...) ? are you going to rewrite ComponentLocationResolver to load g

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

,...) ? are you going to rewrite ComponentLocationResolver to load groovy from compiled `.class` Samuel On 16/09/2019 12:28, Jacques Le Roux wrote: Hi Devs, While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" I discussed with Mathieu and we had some ideas.

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

gt; and this thread, ie indeed mostly "move them to src/main/groovy". That's > enough for my need. > > Using @CompileStatic is out of my scope because I want to keep Groovy scripts > dynamic. > > Le 20/09/2019 à 16:27, Taher Alkhateeb a écrit : > > I'm no

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

In a 1st time I intend to do only what I wrote in OFBIZ-10226, OFBIZ-10205 and this thread, ie indeed mostly "move them to src/main/groovy". That's enough for my need. Using @CompileStatic is out of my scope because I want to keep Groovy scripts dynamic. Le 20/09/2019 à 16:27, Taher

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

I'm not sure I understand the outcome from reading the JIRA and this thread. What will happen exactly? Are you going to make groovy scripts part of the call stack? Are you going to use @CompileStatic? Or are you just going to move them to src/main/groovy? On Fri, Sep 20, 2019 at 5:14 PM Jacques

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

ed to move Groovy scripts from /groovyScripts/ to/src/main/groovy/. I was initially reluctant because I love to be able to change things on the fly. That's why I liked Minilang and still like widgets, Freemarker templates and Groovy Scripts. We also know the advantages of compilation. But then

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

- lundi 16 sept., Jacques Le Roux a écrit : > Hi Devs, > > While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" I > discussed with Mathieu and we had some ideas. > > Mathieu suggested to move Groovy scripts from /groovyScripts/ > to/src/mai

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

Thanks Jacques, Yes, on the fly rebuild is very cool. This will encourage and accelerate moving Java services to Groovy, I think. Big +1 from me. Cheers Paul On Mon, 16 Sep 2019 at 20:29, Jacques Le Roux wrote: > Hi Devs, > > While working on OFBIZ-10226 "Adds groovyScripts

[DISCUSSION] Best of both Groovy worlds: compile and on the fly

Hi Devs, While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" I discussed with Mathieu and we had some ideas. Mathieu suggested to move Groovy scripts from /groovyScripts/ to/src/main/groovy/. I was initially reluctant because I love to be able to cha

Re: Using plain Groovy classes for services.

Hi Mathieu, On Wed, Nov 14, 2018 at 12:38 AM Mathieu Lirzin wrote: > > Basically what I have in mind, is to organize services in classes like > what is done in Java with the same method signature: > > (Map ⨯ Map) → Map > > where the maps parameters correspond respectively to the “dispatch >

Re: Code Improvement for Groovy

> wrote: > Thanks Scott, > > Quite helpful! > > Jacques > > Le 16/05/2019 à 10:12, Scott Gray a écrit : > > Hi Pawan > > > > Sounds good, just one point to be careful of: > > maxRetry = 0 > > if (!maxRetry) { > > // Not set, use a defa

Re: Code Improvement for Groovy

Thanks Scott, Quite helpful! Jacques Le 16/05/2019 à 10:12, Scott Gray a écrit : Hi Pawan Sounds good, just one point to be careful of: maxRetry = 0 if (!maxRetry) { // Not set, use a default maxRetry = -1 } Because groovy evaluates zero to be false, it wouldn't be possible to set

Re: Code Improvement for Groovy

Hi Pawan Sounds good, just one point to be careful of: maxRetry = 0 if (!maxRetry) { // Not set, use a default maxRetry = -1 } Because groovy evaluates zero to be false, it wouldn't be possible to set maxRetry to zero. So it's best not to use groovy truth for null-checks on numbers in some

Re: Code Improvement for Groovy

t; jacques.le.r...@les7arts.com> wrote: > Hi Pawan, > > Sure, we use that from start a lot. But some don't it seems. A Jira fits > with me > > Le 15/05/2019 à 14:29, Pawan Verma a écrit : > > Hello Devs, > > > > As we all know, Groovy is a powerful language wit

Re: Code Improvement for Groovy

Hi Pawan, Sure, we use that from start a lot. But some don't it seems. A Jira fits with me Le 15/05/2019 à 14:29, Pawan Verma a écrit : Hello Devs, As we all know, Groovy is a powerful language with great built-in functions. Groovy Truth[1] is one of them, which is not used properly in our

Code Improvement for Groovy

Hello Devs, As we all know, Groovy is a powerful language with great built-in functions. Groovy Truth[1] is one of them, which is not used properly in our code base. We have used UtilValidate Class to validate arguments for Empty or NotEmpty, which can easily be done in groovy with built

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

Hello, The difference with the documentation and Mathieu's example is the presence of String concatenation. Here lies the performance improvment. If there a simple String is used, the if is uneeded :) Regards Gil Le 19:58 - mardi 11 déc., Taher Alkhateeb a écrit : > The official documentation

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

The official documentation mentions that performance is hit [1] with metrics. [1] https://logging.apache.org/log4j/2.x/performance.html#asyncLoggingWithParams On Tue, Dec 11, 2018 at 7:19 PM Mathieu Lirzin wrote: > > Hello Michael, > > Michael Brohl writes: > > > Yes, right, but it's certainly

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

Hello Michael, Michael Brohl writes: > Yes, right, but it's certainly less costly than the direct execution > of Debug.logXxxx... And that's the point. You don't want to run these > statments thousands of times within a minute (in production systems), > which is the case in central

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

    <> I think Michael's point is perfectly valid. So I answered:   <  OK then we need to see things otherwise and rather enforce the checks to these 2 levels at least in all the source (Java and Groovy). That's what   I'll ask in the convo to come in dev ML.>> So what are yo

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

not be removed.>> I think Michael's point is perfectly valid. So I answered:   <any issue in production needing an info or debug level.   OK then we need to see things otherwise and rather enforce the checks to these 2 levels at least in all the source (Java and Groovy). That's wha

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

Because 1. The if condition has a cost (3 times more than nothing according to Mathieu's reference[1]) 2. and is not consistently used. 3. Using "Beautiful Logger" could be a better solution: https://github.com/forax/beautiful_logger drawbacks: *  needs Java 11 to build. But will we

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

"if > >> (Debug.verboseOn())">> > >> > >> To what Michael answered > >> > >> < >> run them on debug level info, verbose or debug. > >> In my view, at least these 3 debug levels should be checked. At > >

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

The question is quite simple. It's about always using or not the /if (Debug.levelOn()) {/ expression for the info and debug level as suggests Michael. Or only using /if/ /(Debug.verboseOn()) { /expression as I recommend for the reasons explained. I think we all agree the /if/

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

> < them on debug level info, verbose or debug. > In my view, at least these 3 debug levels should be checked. At least, > existing checks should not be removed.>> > > I think Michael's point is perfectly valid. So I answered: > > < production needing an in

[DISCUSSION] Checking debug levels in Java and Groovy files

Hi, After OFBIZ-10052, OFBIZ-10448, and OFBIZ-10697 I think it's time to have another discussion following https://markmail.org/message/mplvusuqn7oshl4v which was one year ago. In OFBIZ-10697 I wrote: : I'd be all for removing the

Re: Using plain Groovy classes for services.

Hello Jacques, Jacques Le Roux writes: > Le 21/11/2018 à 17:43, Jacques Le Roux a écrit : >> Le 17/11/2018 à 20:12, Mathieu Lirzin a écrit : >>> For services I think the business logic and validation of data contained >>> in services could often be extracted in separate unit testable methods

Re: Using plain Groovy classes for services.

Le 21/11/2018 à 17:43, Jacques Le Roux a écrit : Le 17/11/2018 à 20:12, Mathieu Lirzin a écrit : For services I think the business logic and validation of data contained in services could often be extracted in separate unit testable methods which would allow cheap better case coverage to

Re: Using plain Groovy classes for services.

Le 17/11/2018 à 20:12, Mathieu Lirzin a écrit : For services I think the business logic and validation of data contained in services could often be extracted in separate unit testable methods which would allow cheap better case coverage to complement the integration test which is about checking

Re: Using plain Groovy classes for services.

mespace > - the other benefits you mentioned > > Cons of your approach: > - less orientation towards business focused individuals The link between "business orientation" and the use of Groovy DSL is only theoric. > - more work on part of the developer. The DSL was a

Re: Using plain Groovy classes for services.

orientation towards business focused individuals - more work on part of the developer. The DSL was always historically a comfort point for OFBiz not just the groovy DSL but XML and everything else. - Major amount of work to refactor all the services. I'm also not sure the problems you're facing

Re: Using plain Groovy classes for services.

Hello Jacopo, Jacopo Cappellato writes: > thank you for starting this interesting conversation. > I think it is fine to implement services in plain Java or in plain Groovy > methods and you have highlighted some of the advantages over their > implementation using the Groovy DSL. >

Re: Using plain Groovy classes for services.

Hi Mathieu, thank you for starting this interesting conversation. I think it is fine to implement services in plain Java or in plain Groovy methods and you have highlighted some of the advantages over their implementation using the Groovy DSL. However in my opinion the Groovy DSL (even in its

Re: Using plain Groovy classes for services.

Hello Taher, Taher Alkhateeb writes: > Can you explain hat you want to do exactly? How do these services > access the delegator and whatnot? Basically what I have in mind, is to organize services in classes like what is done in Java with the same method signature: (Map ⨯ Map) → Map where

Re: Using plain Groovy classes for services.

Hi Mathieu, Can you explain hat you want to do exactly? How do these services access the delegator and whatnot? On Sun, Nov 11, 2018 at 5:32 PM Mathieu Lirzin wrote: > > Hello, > > While I think using Groovy for implementing services is a better choice > than Java, I a

答复: Using plain Groovy classes for services.

+1, We can also use groovy for other java classes 发件人: Mathieu Lirzin 发送时间: 2018年11月11日 23:32 收件人: OFBIZ Development Mailing List 主题: Using plain Groovy classes for services. Hello, While I think using Groovy for implementing services is a better choice than

Using plain Groovy classes for services.

Hello, While I think using Groovy for implementing services is a better choice than Java, I am not convinced by the rationale of using Groovy DSL features. Here are the various drawbacks I see: - The service DSL breaks the function/method local scoping goodness by introducing various

Re: Groovy DSL runService Exception Management ?

Thanks Jacopo and Taher for your answers. I understand now the goal of this and will try to use it to allow less verbosity in service error handling management in Groovy DSL. Indeed, in a way, each service using groovy should throw ExecutionServiceException that should be managed within

Re: Groovy DSL runService Exception Management ?

On Thu, Oct 18, 2018 at 10:45 AM Gil Portenseigne < gil.portensei...@nereide.fr> wrote: > Hello ! > > While we are working on Groovy migration at Nereide, we figured out that > using ‘run service’ DSL method instead of returning the errorMap, a > ‘ExecutionServiceException’

Re: Groovy DSL runService Exception Management ?

ssion here. On Thu, Oct 18, 2018 at 11:45 AM Gil Portenseigne wrote: > > Hello ! > > While we are working on Groovy migration at Nereide, we figured out that > using ‘run service’ DSL method instead of returning the errorMap, a > ‘ExecutionServiceException’ is thrown : > &

Groovy DSL runService Exception Management ?

Hello ! While we are working on Groovy migration at Nereide, we figured out that using ‘run service’ DSL method instead of returning the errorMap, a ‘ExecutionServiceException’ is thrown : if (ServiceUtil.isError(result)) { throw new ExecutionServiceException

Re: Error in groovy files only inside docker

creens and entities, not groovy at all), and in my local computer (Windows 10, jdk8_171) works prety fine, but when I build a docker image and deploy it (Linux), some screens have Exceptions, and also lookups show groovy errors. This screen is webTools -> Service Engine 2018-09-04 12:57:07,268 |http

Re: Error in groovy files only inside docker

mizing a plugin with ofbiz (new screens and entities, not groovy > at all), and in my local computer (Windows 10, jdk8_171) works prety fine, > but when I build a docker image and deploy it (Linux), some screens have > Exceptions, and also lookups show groovy errors. > > > This scr

Error in groovy files only inside docker

Hello everyone! I am customizing a plugin with ofbiz (new screens and entities, not groovy at all), and in my local computer (Windows 10, jdk8_171) works prety fine, but when I build a docker image and deploy it (Linux), some screens have Exceptions, and also lookups show groovy errors

Re: svn commit: r1827470 - /ofbiz/ofbiz-framework/trunk/framework/base/groovyScript/test/FileUtilTests .groovy

I guess you mean replace by .adoc files? Jacques Le 22/03/2018 à 10:32, Taher Alkhateeb a écrit : Just a note to all the documentation team, I think we should probably delete most README files anyway. The manual should be comprehensive and incorporate whatever is documented in these README

Re: svn commit: r1827457 - /ofbiz/ofbiz-framework/trunk/framework/base/groovyScript/test/FileUtilTests .groovy

You'r right, thanks Gil Jacques Le 22/03/2018 à 08:48, gil portenseigne a écrit : Indeed, thanks Jacques for the fix. I'll just complete it renaming the zipName to README.adoc.zip :), not a big deal but for consistency it's better. Gil On 22/03/2018 06:30, jler...@apache.org wrote:

  1   2   3   4   5   6   7   8   9   10   >