[JBoss JIRA] (JBEE-151) Missing doPrivileged block(s) around getContextClassLoader
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBEE-151?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated JBEE-151:
-----------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1075045
> 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: general
> Reporter: Carlo de Wolf
> Assignee: Shelly McGowan
>
> 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 Carlo de Wolf (JIRA)
Carlo de Wolf created JBEE-151:
----------------------------------
Summary: 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: general
Reporter: Carlo de Wolf
Assignee: Shelly McGowan
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] (JBASMP-58) jboss-as-maven-plugin freezes on authentication
by Bryan Galvin (JIRA)
[ https://issues.jboss.org/browse/JBASMP-58?page=com.atlassian.jira.plugin.... ]
Bryan Galvin commented on JBASMP-58:
------------------------------------
We upgraded to jboss-as-maven-plugin version=7.4.Final, today. We have not experienced the 'freeze' issue since the upgrade.
> jboss-as-maven-plugin freezes on authentication
> -----------------------------------------------
>
> Key: JBASMP-58
> URL: https://issues.jboss.org/browse/JBASMP-58
> Project: JBoss AS Maven Plugins
> Issue Type: Bug
> Components: deploy
> Affects Versions: 7.5.Final
> Environment: mac os x 10.8.5 & mac os x 10.9
> mvn 3.1.1
> Reporter: Julien Derveeuw
> Assignee: James Perkins
> Priority: Critical
>
> I have jboss 7.1.1 in standalone mode running on machine A (linux).
> I want to deploy remotely to it using client machine B @ mac os X 10.8.5 / JDK 1.7.0_45-b18.
> If I connect from B to A using {{jboss-cli}}, everything works fine, I am able to login.
> If I try to deploy from maven with this :
> {code:xml}
> <groupId>org.jboss.as.plugins</groupId>
> <artifactId>jboss-as-maven-plugin</artifactId>
> <version>7.5.Final</version>
> <configuration>
> <hostname>${deploy.jboss.host}</hostname>
> <port>${deploy.jboss.port}</port>
> <username>${deploy.jboss.user}</username>
> <password>${deploy.jboss.password}</password>
> </configuration>
> <executions>
> <execution>
> <phase>install</phase>
> <goals>
> <goal>deploy</goal>
> </goals>
> </execution>
> </executions>
> {code}
> plugin freezes indefinitely on
> {{Authenticating against security realm: ManagementRealm}}
> No more details are available with {{mvn -X}}
> If I remove the password or username from pom, it fails correctly with :
> {{The connection failed: Authentication failed: all available authentication mechanisms failed}}
> so it seems that the plugin somehow manages to connect to machine A.
> After digging on google, I ended up adding {{-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KQueueSelectorProvider}} to mvn runner options because NIOs on jdk7@macosx is said to be buggy but it didn't help.
> More details :
> {code:title=mvn 3.1.1 output|borderStyle=solid}Nov 7, 2013 10:40:09 PM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.3.GA
> Nov 7, 2013 10:40:09 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.3.GA
> Nov 7, 2013 10:40:09 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.3.GA
> Authenticating against security realm: ManagementRealm
> {code}
> {code:title=jstack 7.1.1.Final|borderStyle=solid}
> "main" prio=5 tid=7f86d6800800 nid=0x1060f0000 in Object.wait() [1060ee000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <7f4102a20> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at java.lang.Object.wait(Object.java:485)
> at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> - locked <7f4102a20> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <7f4102a20> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get(AbstractModelControllerClient.java:363)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get(AbstractModelControllerClient.java:317)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:137)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:81)
> at org.jboss.as.plugin.deployment.standalone.StandaloneDeployment.exists(StandaloneDeployment.java:175)
> at org.jboss.as.plugin.deployment.standalone.StandaloneDeployment.createPlan(StandaloneDeployment.java:108)
> at org.jboss.as.plugin.deployment.standalone.StandaloneDeployment.execute(StandaloneDeployment.java:133)
> at org.jboss.as.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:138)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
> {code:title=jstack 7.5.Final|borderStyle=solid}
> "main" prio=5 tid=7fceea001000 nid=0x10d4d0000 in Object.wait() [10d4ce000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <7f42f2150> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at java.lang.Object.wait(Object.java:485)
> at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> - locked <7f42f2150> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <7f42f2150> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at org.jboss.as.plugin.common.AbstractServerConnection.isDomainServer(AbstractServerConnection.java:234)
> at org.jboss.as.plugin.common.AbstractServerConnection.getClient(AbstractServerConnection.java:156)
> - locked <7f42f2230> (a java.lang.Object)
> at org.jboss.as.plugin.common.AbstractServerConnection.isDomainServer(AbstractServerConnection.java:133)
> - locked <7f42f2230> (a java.lang.Object)
> at org.jboss.as.plugin.deployment.AbstractDeployment.validate(AbstractDeployment.java:192)
> at org.jboss.as.plugin.deployment.AbstractDeployment.doExecute(AbstractDeployment.java:136)
> - locked <7f42f2230> (a java.lang.Object)
> at org.jboss.as.plugin.deployment.AbstractAppDeployment.doExecute(AbstractAppDeployment.java:70)
> at org.jboss.as.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:111)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {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] (JGRP-1797) NakackTest testReceptionOfAllMessages fails to receive all messages
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1797:
-------------------------------------------
The PR makes the receiver thread synchronized. This should have no impact on the test because we are simply testing that all messages are received and in the correct order (i.e.not allowing concurrent processing of message receipt is not relevant).
Also added a little more debugging info on the assertion.
> NakackTest testReceptionOfAllMessages fails to receive all messages
> -------------------------------------------------------------------
>
> Key: JGRP-1797
> URL: https://issues.jboss.org/browse/JGRP-1797
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions.
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
> Attachments: stdout.txt
>
>
> This test does the following:
> - involves channels A, B, and C where only B and C are senders and all are receivers
> - B and C send 1000 multicast messages
> - checks that all messages are received and in the correct order
> This test is failing intermittently but quite often.
--
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-451) Timed rules, different name, same timer, same LHS, different RHS, one mask the other
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-451?page=com.atlassian.jira.plugin... ]
Matteo Mortari updated DROOLS-451:
----------------------------------
Attachment: 2014-03-11_18-52-25.png
20140311.drools6test.timerrulessamelhs.zip
Screenshot of rete/phreak looking promising but apparently not working, but also Java code to reproduce the failure.
> Timed rules, different name, same timer, same LHS, different RHS, one mask the other
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-451
> URL: https://issues.jboss.org/browse/DROOLS-451
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Matteo Mortari
> Assignee: Mark Proctor
> Attachments: 2014-03-11_18-52-25.png, 20140311.drools6test.timerrulessamelhs.zip
>
>
> Consider the following KB:
> {code}
> rule "Dummy timer rule 1"
> timer (cron: 0 0 0 * * ?)
> when
> Integer()
> then
> insert("Dummy timer rule 1");
> System.out.println("Dummy timer rule 1");
> end
> rule "Dummy timer rule 2"
> timer (cron: 0 0 0 * * ?)
> when
> Integer()
> then
> insert("Dummy timer rule 2");
> System.out.println("Dummy timer rule 2");
> end
> {code}
> Then consider the following steps:
> # insert new Integer
> # advance clock by +1 day
> *Expected result:* 3 facts in the working memory, the original Integer, and two String.
> *Actual results:* 2 facts in the working memory, the original Integer, and only 1 String, from the former of the two rules.
> I hope this is not another duplicate report, I've done search on Jira before submitting, but kindly excuse me if I didn't found an already open bug which is a greater case of this one =)
> I will attach relevant source code to replicate the issue, and related material
--
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-451) Timed rules, different name, same timer, same LHS, different RHS, one mask the other
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-451:
-------------------------------------
Summary: Timed rules, different name, same timer, same LHS, different RHS, one mask the other
Key: DROOLS-451
URL: https://issues.jboss.org/browse/DROOLS-451
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.1.Final
Reporter: Matteo Mortari
Assignee: Mark Proctor
Attachments: 2014-03-11_18-52-25.png, 20140311.drools6test.timerrulessamelhs.zip
Consider the following KB:
{code}
rule "Dummy timer rule 1"
timer (cron: 0 0 0 * * ?)
when
Integer()
then
insert("Dummy timer rule 1");
System.out.println("Dummy timer rule 1");
end
rule "Dummy timer rule 2"
timer (cron: 0 0 0 * * ?)
when
Integer()
then
insert("Dummy timer rule 2");
System.out.println("Dummy timer rule 2");
end
{code}
Then consider the following steps:
# insert new Integer
# advance clock by +1 day
*Expected result:* 3 facts in the working memory, the original Integer, and two String.
*Actual results:* 2 facts in the working memory, the original Integer, and only 1 String, from the former of the two rules.
I hope this is not another duplicate report, I've done search on Jira before submitting, but kindly excuse me if I didn't found an already open bug which is a greater case of this one =)
I will attach relevant source code to replicate the issue, and related material
--
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] (JGRP-1797) NakackTest testReceptionOfAllMessages fails to receive all messages
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on JGRP-1797 at 3/11/14 1:31 PM:
--------------------------------------------------------------------
I guess even though messages are delivered in order, once they start processing of the receive() method, they can get context switched out of order by other later threads. I did a quick check and there are often two threads in the receiver code at any one time.
was (Author: rachmato):
I guess even though messages are delivered in order, once they start processing of the receive() method, they can get context switched out of order by other later threads.
> NakackTest testReceptionOfAllMessages fails to receive all messages
> -------------------------------------------------------------------
>
> Key: JGRP-1797
> URL: https://issues.jboss.org/browse/JGRP-1797
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions.
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
> Attachments: stdout.txt
>
>
> This test does the following:
> - involves channels A, B, and C where only B and C are senders and all are receivers
> - B and C send 1000 multicast messages
> - checks that all messages are received and in the correct order
> This test is failing intermittently but quite often.
--
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 updated DROOLS-450:
----------------------------------
Description:
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.
was:
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}
The end users should have the possibility to keep the same formatter for the same column, with integers or not.
> 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 Maxime Falaize (JIRA)
[ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin... ]
Maxime Falaize updated DROOLS-450:
----------------------------------
Description:
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}
The end users should have the possibility to keep the same formatter for the same column, with integers or not.
was:
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}
This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :
{code:java}
if ( num - Math.round( num ) != 0 )
{code}
The end users should have the possibility to keep the same formatter for the same column, with integers or not.
> 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}
> 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