Bug 738992 - XLS decision tables does not support utf-8 in rule names
Summary: XLS decision tables does not support utf-8 in rule names
Alias: None
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: BRE (Expert, Fusion)
Version: BRMS 5.2.0.GA
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: BRMS 5.3.0.GA
Assignee: Ryan Zhang
QA Contact: Marek Baluch
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-16 09:39 UTC by Jiri Svitak
Modified: 2020-04-27 01:11 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed:
Type: ---

Attachments (Terms of Use)
Class to reproduce bug (4.08 KB, application/x-zip-compressed)
2011-09-16 09:53 UTC, Jiri Svitak
no flags Details
unicode1.xls (7.50 KB, application/vnd.ms-excel)
2012-03-05 07:37 UTC, Ryan Zhang
no flags Details

Description Jiri Svitak 2011-09-16 09:39:11 UTC
Description of problem:
XLS decision table does not support utf-8 in rule names. Rule name with utf-8 is broken and parser throws errors. Utf-8 in conditions, actions and imports works fine. Also CSV decision table with utf-8 works fine. Possible bug with jxl parser for xls.

Version-Release number of selected component (if applicable):
BRMS 5.2.0 ER3

How reproducible:
Create decision table with rule name containing utf-8 characters.

Steps to Reproduce:
1. Download atteched java class and unzip it.
2. Run it to reproduce bug.

Actual results:
Utf-8 does not work in XLS decision table rule names.

Expected results:
Utf-8 should work everywhere.

Additional info:

Comment 1 Jiri Svitak 2011-09-16 09:53:18 UTC
Created attachment 523532 [details]
Class to reproduce bug

Comment 2 Lukáš Petrovický 2011-09-23 10:28:05 UTC
Proposing for 5.3.0.

Comment 3 Jiri Svitak 2012-01-31 10:47:48 UTC
Added pull request with test case:

Comment 4 Geoffrey De Smet 2012-01-31 15:59:15 UTC
Jiri's test worked today on master and on 5.3.x without modifications in the code. Whatever it was, it works now (at least on my machine with the latest master and latest 5.3.x branch).

Comment 5 Ryan Zhang 2012-02-15 09:12:39 UTC
Please verify the issue on 5.3 ER4.

Comment 6 Jiri Svitak 2012-02-21 10:25:29 UTC
Not fixed in BRMS 5.3 ER4. I have checked community master and 5.3.x branches and it works. So the problem appears during productization. Perhaps bad locale or XLS library. Reassigning to Ryan and setting status to ASSIGNED.

Comment 7 Ryan Zhang 2012-03-05 07:36:41 UTC
Emm. The testcase mentioned at comment 3 have no problem with product source too.
I have checked the attached testcase.

It seems to me that there are some difference between the two version unicode.xls.

After changing the package name to "com.sample" and using the unicode.xls in comment 3(not the attachement), the testcase passed.

I attached the passed unicode.xls.

Btw, The line in main need also update to fit the unicode.xls
assertNotNull(kbase.getRule("com.sample", "pokusné pravidlo rozhodovací tabulky"));
 assertNotNull(kbase.getRule("com.sample", "přidej k dospělým"));

Jiri, could you have a look on this?

Comment 8 Ryan Zhang 2012-03-05 07:37:52 UTC
Created attachment 567499 [details]

Comment 9 Jiri Svitak 2012-03-05 11:29:32 UTC
Thanks Ryan, I have checked your unicode1.xls with BRMS 5.3 ER4 binaries and it passes. After some additional checking I have found out that this is not a problem of some specific utf-8 characters, but this is a problem of corrupted .xls files. Some .xls files can be build with a KnowledgeBuilder, some others cannot, even if they contain the same characters. I have used LibreOffice, sometimes it saved files correctly (were buildable), sometimes it didn't (unable to build).

So, this is not a problem of BRMS. If you experience problems with building your .xls files with utf-8, just make sure that you have no error in a decision table and if not, try to modify it and save it in different version of LibreOffice/Excel and make sure that you have correct version of .xls file too.
If you use Eclipse and you have Drools Builder enabled, then corrupted .xls files are marked with a small red cross, which indicates a build error. Also you can try saving your decision table as a .csv file and this should always work without any problems.

Note You need to log in before you can comment on or make changes to this bug.