-
Bug
-
Resolution: Done
-
Minor
-
6.0.1.Final
-
None
-
None
When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0 text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]] at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260) at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400) at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.
This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :
if ( num - Math.round( num ) != 0 )
I don't understand why we use the formatted value when this test is not passed.
I think the end users should have the possibility to keep the same formatter for the same column, with integers or not.
[DROOLS-450] Cannot use decimal formatters for integers in an excel decision table
Marek Winkler <mwinkler@redhat.com> changed the Status of bug 1077228 from ON_QA to VERIFIED
Ryan Zhang <rzhang@redhat.com> changed the Status of bug 1077228 from MODIFIED to ON_QA
Edson Tirelli <etirelli@redhat.com> changed the Status of bug 1077228 from NEW to MODIFIED
Maxime Falaize (Inactive)
added a comment - I added a test case to my PR. You can test it with and without the patch.
Maxime Falaize (Inactive)
added a comment - I added a test case to my PR. You can test it with and without the patch. Maxime Falaize (Inactive)
added a comment - My values in the XLS are numerics and the display is wrong because my excel uses comma as decimal separator for the french locale.
I will make a unit test and include it to the PR.
Maxime Falaize (Inactive)
added a comment - My values in the XLS are numerics and the display is wrong because my excel uses comma as decimal separator for the french locale.
I will make a unit test and include it to the PR. Hello,
Perhaps you can guide me here.
If your JRE locale is FRENCH then would parsing of numeric values expect them to be formatted "1,000" (instead of "1.000" that the PNG seems to show)? AFAIK using a period as a decimal separator is reserved for other Locales (Spain, Norway and othersd). Are the values in the XLS in fact numeric or Strings? Can you can include a couple of Unit Tests in your PR with both FR and EN locales - and suitable XLS files?
Maxime Falaize (Inactive)
added a comment - Hi Michael,
I think the problem is not the locale of the XLS file but the locale of the JRE. The DataFormatter is created with no relation to the xls workbook. I tested to reproduce the error with a different configuration in excel (settings to english locale) and the problem is still here. However, when I set the JRE default locale to English when I start my app (with Locale.setDefault(Locale.ENGLISH)), it works.
I am on a French Windows 7 (so french JRE). If you set your JRE Locale to FRENCH I think you could reproduce the error.
Maybe we can force the locale of the DateFormatter to English only for the numbers ? It would reduce the possibility of regressions.
Maxime Falaize (Inactive)
added a comment - Hi Michael,
I think the problem is not the locale of the XLS file but the locale of the JRE. The DataFormatter is created with no relation to the xls workbook. I tested to reproduce the error with a different configuration in excel (settings to english locale) and the problem is still here. However, when I set the JRE default locale to English when I start my app (with Locale.setDefault(Locale.ENGLISH)), it works.
I am on a French Windows 7 (so french JRE). If you set your JRE Locale to FRENCH I think you could reproduce the error.
Maybe we can force the locale of the DateFormatter to English only for the numbers ? It would reduce the possibility of regressions. What is the locale settings of the computer on which you produced the error? What is the locale of he XLS workbook you produced the error with?
I'm reluctant to merge your pull request until we better understand your scenario: forcing the DataFormatter(Locale.ENGLISH) might work in your scenario but IDK ATM whether it's sufficiently generic and will not cause other users with different locale settings more problems without understanding a few more things first.
Rajesh Rajasekaran <rrajasek@redhat.com> changed the Status of bug 1077228 from VERIFIED to CLOSED