This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
As the API of the integrated freemarker isn't public, the usage of FM data wrappers isn't possible. Thus even simple case (can be executed by running class Main, will be attached right after submission) that works fine when freemarker used directly with correct data wrappers, doesn't work with integrated freemarker. A way to reproduce: - make package "pack" from attachment classpath-accessible to unit tests of openide/templates module - apply patch IndentEngineIntTest.java.diff to openide/templates/test/unit/src/org/netbeans/modules/templates/IndentEngineIntTest.java - run the unit test BUG: the following error will be the result (of course it is also reproducible if the wrapper isn't used with non-integrated freemarker ) Expected hash. classInfo.getMethods() evaluated instead to freemarker.template.SimpleSequence on line 1, column 7 in simpleObject.txt. The problematic instruction: ---------- ==> if (classInfo.getMethods().size() > 0) [on line 1, column 1 in simpleObject.txt] ---------- Java backtrace for programmers: ---------- freemarker.template.TemplateException: Expected hash. classInfo.getMethods() evaluated instead to freemarker.template.SimpleSequence on line 1, column 7 in simpleObject.txt. at freemarker.core.TemplateObject.invalidTypeException(TemplateObject.java:135) at freemarker.core.Dot._getAsTemplateModel(Dot.java:78) ...........
Created attachment 40384 [details] patch to the unit test reproducing the case
Created attachment 40385 [details] successfully running non-integrated case
I managed to integrate your test and you are right, it fails. With a little trick I made that work, so workaround exists -> P2. I can see that your standalone example works, but guess why? Because you are using BeansWrapper and we are very likely just using some simpler object wrapper. /shared/data/ccvs/repository/libs/freemarker/test/unit/src/org/netbeans/api/templates/ProcessorTest.java,v <-- ProcessorTest.java new revision: 1.4; previous revision: 1.3 done RCS file: /shared/data/ccvs/repository/libs/freemarker/test/unit/src/org/netbeans/api/templates/ClassInfo.java,v done Checking in ClassInfo.java; /shared/data/ccvs/repository/libs/freemarker/test/unit/src/org/netbeans/api/templates/ClassInfo.java,v <-- ClassInfo.java initial revision: 1.1 done RCS file: /shared/data/ccvs/repository/libs/freemarker/test/unit/src/org/netbeans/api/templates/MethodInfo.java,v done Checking in MethodInfo.java; /shared/data/ccvs/repository/libs/freemarker/test/unit/src/org/netbeans/api/templates/MethodInfo.java,v <-- MethodInfo.java initial revision: 1.1 done
i'd agree to P2 if it the problem were scoped only to this specific case. Unfortunately, the workaround can't be usefull for generic case. We intend to expose users to the possibility to modify/create templates on their own. I.e users would be supposed to be able to traverse and make calls to our data model in their templates. In the same time the users willn't be able to modify the data model by, for example, adding new method(s) like you did in the workaround.
If I modify your Main.java to use ObjectWrapper.DEFAULT_WRAPPER it fails in standalone mode as well. So I would not call this a defect at all. Btw. see: /shared/data/ccvs/repository/libs/freemarker/test/unit/src/org/netbeans/api/templates/ProcessorTest.java,v <-- ProcessorTest.java new revision: 1.5; previous revision: 1.4 it shows how to make your test pass. If you have another ideas to make freemarker integration better, feel free to write a test or even the impl.
Here is an example how to write freemarker templates that work with arrays in the default object wrapper: libs/freemarker/test/unit/src/org/netbeans/api/templates/ProcessorTest.java,v <-- ProcessorTest.java new revision: 1.6; previous revision: 1.5
>If I modify your Main.java to use ObjectWrapper.DEFAULT_WRAPPER it fails in standalone mode as well. So I would not call this a defect at all. This is the defect - i _can_ (and do) use necessary wrapper in my implementation (where freemarker API is available inside my module) and _can't_ do it in the integrated. This defect of the freemarker integration is clearly stated in the summary. >If you have another ideas to make freemarker integration better, it is clear from the summary&description - to make freemarker API available (and wrappers in particular) >feel free to write a test or even the impl. we kind of must to migrate to your impl. thus these bugs filed. While i agree that the workaround for the particular test case is provided, the issue, as it was originally stated, isn't fixed. (i guess, playing ping-pong with re-opening of the issues would obviously be pointless until at least necessary good will appear on you side).
I'll do as much as I can to not open freemarker packages to public consumption. I think we should use javax.script only, possibly enhance the binding in FreemarkerEngine (although I'd like to keep the bindings consistent with http://scripting.dev.java.net). Also please note that for the last added test so far shows how to fix your template to work in standalone as well as internal mode.