Hide Forgot
Date of First Response: 2009-09-10 00:57:03 Help Desk Ticket Reference: https://jira.jboss.org/jira/browse/JBRULES-1970 securitylevel_name: Public In Drools 4.0.7 and 5.0.0M5 it was possible to generate linebreaks using \n in an dsl-File. Since 5.0.0 CR1 this is no longer possible: the \n is simply converted to the letter n which leads to compile-errors concerning the replaced code. Example DSL: # Test linebreak-bug since 5.0.0 CR1 [*][]only a simple test = System.out.println \n ("Did it generate a line break?"); Example DSLR: #created on: 12.03.2009 package linebreak expander linebreakbug.dsl rule "line break bugtest" when #conditions then only a simple test end This leads to the line System.out.println n ("Did it generate a line break?"); Maybe this bug is related to https://jira.jboss.org/jira/browse/JBRULES-1970 where the handling of #-Characters in DSL-Files had been fixed. In my special case I'v got an workaround, but that's no workaround for anyone: Using one DSLR I generate 2 Outputs: a) using DSLR with dsl-file-A leads to "DLR"-Code: I don't need line breaks here (today, but maybe next month?) I don't care if the generated Code is nice or not and if the line is long or not. The code works and is executed by the rules-engine. Everything fine here. b) using DSLR with dsl-file-B leads to programming-code in another programming-language. This Code is never executed in Drools, it is simply generated. The result is taken an copied into the target-system. For that task I have written an own plugin that does that stuff and works like a little post-processor. So my workaround is to use my own "keyword" $CRLF in an DSL-File and - after the generation that Drools does - replaced that with "\n". Not where nice but simple...
Link: Added: This issue is related to JBRULES-2000
Fix in place.
For documenting this in the Release Notes, can you please confirm the following and fill in the missing information. Dot point explanations are fine: The CAUSE (what was actually broken) * Escape code was ignored so that \n became n. CONSEQUENCES of the bug (how it impacts users.) * Line breaks coded in DSL were not being generated correctly upon compilation in Drools The FIX (what was changed to eliminate this bug) and * RESULTS of the fix (what now happens for users.) *
Repeating request for feedback.
The CAUSE (what was actually broken) * The new DSL grammar parsing was ignoring \n escape codes. CONSEQUENCES of the bug (how it impacts users.) * Line breaks coded in DSL were not being generated correctly upon compilation in Drools The FIX (what was changed to eliminate this bug) and * The DSL grammar parsing was changed to support the \n escape code again. RESULTS of the fix (what now happens for users.) * \n escapes are now correctly replaced by line breaks.
added to 5.0.CP01 release notes as resolved: Line breaks coded in a DSL were not being generated correctly. This was caused by the new DSL grammar parser ignoring the \n escape character. The parser has been updated to correctly interpret these characters.