I did some testing and I have found the first release that causes the error: it's 2.3.0 (it works until the 2.2.2 release).
Jacopo On Aug 26, 2015, at 12:34 PM, Jacques Le Roux <[email protected]> wrote: > I will try a dichotomous approach indeed. It worked in 2.2.1 not 2.4.4, let's > see... > > Jacques > > Le 26/08/2015 02:31, Keegan Witt a écrit : >> I don't have any other ideas at the moment. Other than maybe trying other >> versions of Groovy to see which version made the changes. >> >> -Keegan >> >> On Tue, Aug 25, 2015 at 4:02 AM, Jacques Le Roux >> <[email protected]> wrote: >> Hi, >> >> Yes I did (of course ;)) I did not get a chance to have another look yet, >> still planned... >> >> Jacques >> >> >> Le 25/08/2015 05:47, Keegan Witt a écrit : >>> OK, so we've ruled out an AST I think. Dumb question, but did you >>> recompile GroovyUtil.java after changing the Groovy versions? Because it >>> is compiled against Groovy and maybe something was changed between versions. >>> >>> -Keegan >>> >>> On Thu, Aug 20, 2015 at 12:11 PM, Jacques Le Roux >>> <[email protected]> wrote: >>> You are welcome Jacopo, >>> >>> Being (almost) in vacation, I did not find the time to explain how we use >>> Groovy, thanks! >>> >>> I hope to have another look before Monday... >>> >>> Jacques >>> >>> >>> Le 20/08/2015 16:52, Jacopo Cappellato a écrit : >>> Jacques, Cédric, Keegan. >>> >>> I apologize if I jump in this conversation but I am interested in this >>> issue reported by Jacques and I would like to share more information about >>> how the code is used in OFBiz. >>> >>> The GroovyBaseScript.groovy [*] is in the classpath, and here is how we use >>> it (I have simplified the code for readability): >>> >>> CompilerConfiguration conf = new CompilerConfiguration(); >>> conf.setScriptBaseClass("org.ofbiz.service.engine.GroovyBaseScript"); >>> GroovyClassLoader groovyClassLoader = new >>> GroovyClassLoader(GroovyUtil.class.getClassLoader(), conf); >>> >>> Then we use "groovyClassLoader" to parse our scripts with something like >>> this: >>> >>> groovyClassLoader.parseClass(UtilIO.readString(in), location); >>> >>> Kind regards, >>> >>> Jacopo >>> >>> >>> [*] You can review the content of GroovyBaseScript.groovy here: >>> >>> http://svn.apache.org/repos/asf/ofbiz/trunk/framework/service/src/org/ofbiz/service/engine/GroovyBaseScript.groovy >>> >>> On Aug 14, 2015, at 2:32 PM, Keegan Witt <[email protected]> wrote: >>> >>> FYI, it is possible to apply ASTs to scripts. Remember that at the end of >>> the day, scripts are compiled too (just compiled on the fly). How are you >>> extending org.ofbiz.service.engine.GroovyBaseScript? Is it in a jar on the >>> classpath? And are you sure there are no ASTs in it? >>> >>> -Keegan >>> >>> On Fri, Aug 14, 2015 at 6:19 AM, Jacques Le Roux >>> <[email protected]> wrote: >>> Since we don't compile groovy code I think we don't do AST transformations. >>> https://glaforge.appspot.com/article/groovy-ast-transformations-tutorials >>> >>> Jacques >>> >>> >>> >>> Le 14/08/2015 11:02, Cédric Champeau a écrit : >>> Are you writing your own AST transformations? If so, it is likely a bug in >>> one of them, and the error message is there to tell you something is wrong >>> with it. >>> >>> 2015-08-14 10:52 GMT+02:00 Jacques Le Roux <[email protected]>: >>> Hi, >>> >>> We heavily rely on Groovy in Apache OFBiz where it replaced BeanShell 7 >>> years ago. We only use it for scripts, we don't use the compiler. >>> >>> I thought upgrading from 2.2.1 to 2.4.4 would be a breeze. So I simply >>> deleted groovy-all-2.2.1.jar and added groovy-all-2.4.4.jar locally before >>> committing. But I was surprised to get this error, which exists in all our >>> scripts. >>> >>> [java] Caused by: >>> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup >>> failed: >>> [java] >>> component://commonext/webapp/ofbizsetup/organization/changeOrgPartyId.groovy: >>> 23: A transform used a generics containing ClassNode >>> org.ofbiz.service.engine.GroovyBaseScript for the super class cha >>> ngeOrgPartyId directly. You are not supposed to do this. Please create a >>> new ClassNode referring to the old ClassNode and use the new ClassNode >>> instead of the old one. Otherwise the compiler will create wrong >>> descriptors and a potential NullPointerException in TypeResolver in the >>> OpenJDK. If this is not your own doing, please report this bug to the >>> writer of the transform. >>> [java] @ line 23, column 1. >>> [java] partyAcctgPrefAndGroupList = []; >>> [java] ^ >>> [java] >>> [java] 1 error >>> [java] >>> [java] at >>> org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310) >>> ~[groovy-all-2.4.4.jar:2.4.4] >>> [java] at >>> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1075) >>> ~[groovy-all-2.4.4.jar:2.4.4] >>> [java] at >>> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:591) >>> ~[groovy-all-2.4.4.jar:2.4.4] >>> [java] at >>> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:569) >>> ~[groovy-all-2.4.4.jar:2.4.4] >>> [java] at >>> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:546) >>> ~[groovy-all-2.4.4.jar:2.4.4] >>> [java] at >>> groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298) >>> ~[groovy-all-2.4.4.jar:2.4.4] >>> [java] at >>> groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268) >>> ~[groovy-all-2.4.4.jar:2.4.4] >>> [java] at >>> groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:254) >>> ~[groovy-all-2.4.4.jar:2.4.4] >>> [java] at >>> groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:212) >>> ~[groovy-all-2.4.4.jar:2.4.4] >>> [java] at >>> org.ofbiz.base.util.GroovyUtil.parseClass(GroovyUtil.java:162) >>> ~[ofbiz-base.jar:?] >>> [java] at >>> org.ofbiz.base.util.GroovyUtil.getScriptClassFromLocation(GroovyUtil.java:134) >>> ~[ofbiz-base.jar:?] >>> [java] at >>> org.ofbiz.base.util.GroovyUtil.runScriptAtLocation(GroovyUtil.java:170) >>> ~[ofbiz-base.jar:?] >>> [java] at >>> org.ofbiz.base.util.ScriptUtil.executeScript(ScriptUtil.java:342) >>> ~[ofbiz-base.jar:?] >>> [java] at >>> org.ofbiz.base.util.ScriptUtil.executeScript(ScriptUtil.java:324) >>> ~[ofbiz-base.jar:?] >>> [java] at >>> org.ofbiz.widget.model.AbstractModelAction$Script.runAction(AbstractModelAction.java:632) >>> ~[ofbiz-widget.jar:?] >>> [java] at >>> org.ofbiz.widget.model.AbstractModelAction.runSubActions(AbstractModelAction.java:141) >>> ~[ofbiz-widget.jar:?] >>> [java] at >>> org.ofbiz.widget.model.ModelScreenWidget$Section.renderWidgetString(ModelScreenWidget.java:273) >>> ~[ofbiz-widget.jar:?] >>> [java] at >>> org.ofbiz.widget.model.ModelScreen.renderScreenString(ModelScreen.java:164) >>> ~[ofbiz-widget.jar:?] >>> [java] at >>> org.ofbiz.widget.model.ScreenFactory.renderReferencedScreen(ScreenFactory.java:211) >>> ~[ofbiz-widget.jar:?] >>> [java] at >>> org.ofbiz.widget.model.ModelScreenWidget$IncludeScreen.renderWidgetString(ModelScreenWidget.java:780) >>> ~[ofbiz-widget.jar:?] >>> [java] at >>> org.ofbiz.widget.model.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:98) >>> ~[ofbiz-widget.jar:?] >>> [java] at >>> org.ofbiz.widget.model.ModelScreenWidget$Section.renderWidgetString(ModelScreenWidget.java:280) >>> ~[ofbiz-widget.jar:?] >>> [java] at >>> org.ofbiz.widget.model.ModelScreen.renderScreenString(ModelScreen.java:164) >>> ~[ofbiz-widget.jar:?] >>> [java] at >>> org.ofbiz.widget.model.ScreenFactory.renderReferencedScreen(ScreenFactory.java:211) >>> ~[ofbiz-widget.jar:?] >>> [java] at >>> org.ofbiz.widget.model.ModelScreenWidget$DecoratorScreen.renderWidgetString(ModelScreenWidget.java:860) >>> ~[ofbiz-widget.jar:?] >>> [java] at >>> org.ofbiz.widget.model.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:98) >>> ~[ofbiz-widget.jar:?] >>> [java] at >>> org.ofbiz.widget.model.ModelScreenWidget$Section.renderWidgetString(ModelScreenWidget.java:280) >>> ~[ofbiz-widget.jar:?] >>> [java] at >>> org.ofbiz.widget.model.ModelScreen.renderScreenString(ModelScreen.java:164) >>> ~[ofbiz-widget.jar:?] >>> [java] ... 28 more >>> >>> I looked for similar cases on the Internet and found >>> https://issues.apache.org/jira/browse/GROOVY-5112 >>> https://issues.apache.org/jira/browse/GROOVY-6691 >>> >>> So do you think this could be a bug in Groovy or should we rather dive in >>> in our code? >>> >>> Thanks >>> >>> Jacques >>> >>> >>> >>> >>> >> >> >
