[JBoss JIRA] (DROOLS-454) Support pluggable resource types in the KieBuilder
by Davide Sottara (JIRA)
Davide Sottara created DROOLS-454:
-------------------------------------
Summary: Support pluggable resource types in the KieBuilder
Key: DROOLS-454
URL: https://issues.jboss.org/browse/DROOLS-454
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Davide Sottara
Assignee: Mark Proctor
A user should be able to register custom resource types and the associated processor.
Custom resources would be recognized by file extension and processed by the registered processor.
The processor will generate one or more "native" resources (e.g. DRL, BPMN) from each custom resource found in the KieFileSystem: the generated resources will eventually be added to the KieBase.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (DROOLS-450) Cannot use decimal formatters for integers in an excel decision table
by Maxime Falaize (JIRA)
[ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin... ]
Maxime Falaize commented on DROOLS-450:
---------------------------------------
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.
> Cannot use decimal formatters for integers in an excel decision table
> ---------------------------------------------------------------------
>
> Key: DROOLS-450
> URL: https://issues.jboss.org/browse/DROOLS-450
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Maxime Falaize
> Assignee: Mark Proctor
> Priority: Minor
> Attachments: issue_example.png
>
>
> When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
> {noformat}
> 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)
> {noformat}
> 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 :
> {code:java}
> if ( num - Math.round( num ) != 0 )
> {code}
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (DROOLS-450) Cannot use decimal formatters for integers in an excel decision table
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin... ]
Michael Anstis commented on DROOLS-450:
---------------------------------------
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.
> Cannot use decimal formatters for integers in an excel decision table
> ---------------------------------------------------------------------
>
> Key: DROOLS-450
> URL: https://issues.jboss.org/browse/DROOLS-450
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Maxime Falaize
> Assignee: Mark Proctor
> Priority: Minor
> Attachments: issue_example.png
>
>
> When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
> {noformat}
> 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)
> {noformat}
> 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 :
> {code:java}
> if ( num - Math.round( num ) != 0 )
> {code}
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (WFLY-3078) directory-grouping configuration is not getting persisted via CLI when no servers defined
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3078?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3078:
-----------------------------------------------
Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1073715|https://bugzilla.redhat.com/show_bug.cgi?id=1073715] from ON_QA to VERIFIED
> directory-grouping configuration is not getting persisted via CLI when no servers defined
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-3078
> URL: https://issues.jboss.org/browse/WFLY-3078
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Environment: All Operating System
> Reporter: Jay Kumar SenSharma
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.1.Final
>
>
> - If none of the servers are defined in "host.xml" (means <servers></servers> empty tag is present) and if the user tries to run the following CLI command to change the "directory-grouping" to "by-type" then the value is not persisted in the configuration file (host.xml) and the <servers></servers> tag is also removed from the host.xml
> {code}
> /host=master/:write-attribute(name=directory-grouping,value=by-type)
> {code}
> - The value of "directory-grouping" is stored "in memory" so this change does not survive the host restart.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JBEE-151) Missing doPrivileged block(s) around getContextClassLoader
by Shelly McGowan (JIRA)
[ https://issues.jboss.org/browse/JBEE-151?page=com.atlassian.jira.plugin.s... ]
Shelly McGowan updated JBEE-151:
--------------------------------
Fix Version/s: jboss-el-api_3.0_spec-1.0.1.Final
> Missing doPrivileged block(s) around getContextClassLoader
> -----------------------------------------------------------
>
> Key: JBEE-151
> URL: https://issues.jboss.org/browse/JBEE-151
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-el-api
> Reporter: Carlo de Wolf
> Assignee: Shelly McGowan
> Fix For: jboss-el-api_2.2_spec-1.0.4.Final, jboss-el-api_3.0_spec-1.0.1.Final
>
>
> jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1
> {code}
> 12:56:34,897 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/read-props].[jsp]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_45]
> at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_45]
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_45]
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1561) [rt.jar:1.7.0_45]
> at java.lang.Thread.getContextClassLoader(Thread.java:1472) [rt.jar:1.7.0_45]
> at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JBEE-151) Missing doPrivileged block(s) around getContextClassLoader
by Shelly McGowan (JIRA)
[ https://issues.jboss.org/browse/JBEE-151?page=com.atlassian.jira.plugin.s... ]
Shelly McGowan commented on JBEE-151:
-------------------------------------
Fix also committed to master branch for jboss-el-api_3.0:
https://github.com/jboss/jboss-el-api_spec/commit/c82e83c9c78d25abd839f64...
> Missing doPrivileged block(s) around getContextClassLoader
> -----------------------------------------------------------
>
> Key: JBEE-151
> URL: https://issues.jboss.org/browse/JBEE-151
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-el-api
> Reporter: Carlo de Wolf
> Assignee: Shelly McGowan
> Fix For: jboss-el-api_2.2_spec-1.0.4.Final
>
>
> jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1
> {code}
> 12:56:34,897 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/read-props].[jsp]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_45]
> at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_45]
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_45]
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1561) [rt.jar:1.7.0_45]
> at java.lang.Thread.getContextClassLoader(Thread.java:1472) [rt.jar:1.7.0_45]
> at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JBEE-151) Missing doPrivileged block(s) around getContextClassLoader
by Shelly McGowan (JIRA)
[ https://issues.jboss.org/browse/JBEE-151?page=com.atlassian.jira.plugin.s... ]
Shelly McGowan edited comment on JBEE-151 at 3/12/14 7:54 PM:
--------------------------------------------------------------
Upstream patch committed to jboss-el-api_2.2 branch:
https://github.com/jboss/jboss-el-api_spec/commit/88e00f1d2e901cf6945471c...
was (Author: shelly.mcgowan):
Upstream patch committed:
https://github.com/jboss/jboss-el-api_spec/commit/88e00f1d2e901cf6945471c...
> Missing doPrivileged block(s) around getContextClassLoader
> -----------------------------------------------------------
>
> Key: JBEE-151
> URL: https://issues.jboss.org/browse/JBEE-151
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-el-api
> Reporter: Carlo de Wolf
> Assignee: Shelly McGowan
> Fix For: jboss-el-api_2.2_spec-1.0.4.Final
>
>
> jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1
> {code}
> 12:56:34,897 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/read-props].[jsp]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_45]
> at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_45]
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_45]
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1561) [rt.jar:1.7.0_45]
> at java.lang.Thread.getContextClassLoader(Thread.java:1472) [rt.jar:1.7.0_45]
> at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month