Bug 724218 (BRMS-161)

Summary: Line break in DSL isnot generated anymore since Drools 5.0.0 CR1
Product: [JBoss] JBoss Enterprise BRMS Platform 5 Reporter: nwallace <nwallace>
Component: unspecifiedAssignee: Edson Tirelli <ed.tirelli>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: high    
Version: unspecified   
Target Milestone: ---   
Target Release: 5.0.1   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/BRMS-161
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
jre6u12 eclipse 3.4 win xp
Last Closed: 2009-09-01 12:21:26 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description nwallace 2009-07-07 13:34:14 UTC
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...

Comment 1 nwallace 2009-07-07 13:35:40 UTC
Link: Added: This issue is related to JBRULES-2000


Comment 2 nwallace 2009-09-01 12:21:26 UTC
Fix in place.

Comment 3 David Le Sage 2009-09-10 04:57:03 UTC
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.)
 * 

Comment 4 David Le Sage 2009-10-02 06:33:55 UTC
Repeating request for feedback.

Comment 5 Edson Tirelli 2009-10-02 12:34:19 UTC
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.

Comment 6 Dana Mison 2009-10-05 04:01:41 UTC
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.