[JBoss JIRA] (DROOLS-626) collectList on objects of type java.lang.Class get returned as null
by David Fell (JIRA)
David Fell created DROOLS-626:
---------------------------------
Summary: collectList on objects of type java.lang.Class get returned as null
Key: DROOLS-626
URL: https://issues.jboss.org/browse/DROOLS-626
Project: Drools
Issue Type: Bug
Affects Versions: 6.2.0.Beta1
Environment: Snapshot Drools 6.2.0.201410031437 runtime
Reporter: David Fell
Assignee: Mark Proctor
If collectList in an accumulate is supplied objects of type java.lang.Class, then subsequent examination of the supplied list yields null values rather than the expect Class values.
Test case below. Swapping the comments to make InitClass have a String field instead of a Class field changes the behaviour of the list from collectList to what one would expect.
package com.sample
declare MyClass end
declare InitClass
clazz: Class @key
// clazz: String @key
end
rule "init"
when
then
insert( new InitClass( MyClass.class ) );
// insert( new InitClass( "some string" ) );
end
rule "make init classes"
when
accumulate( InitClass( $clazz; ), $list: collectList( $clazz ) )
then
System.out.printf("%d items in list\n", $list.size());
for(Object obj : $list)
System.out.printf("item is %s\n", obj);
end
rule "show init classes"
when
InitClass( $v; )
then
System.out.printf("match %s\n", $v);
end
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1850) jGroups 3.4.3 timeouts after a node leaves and rejoins cluster
by Justin Cranford (JIRA)
[ https://issues.jboss.org/browse/JGRP-1850?page=com.atlassian.jira.plugin.... ]
Justin Cranford commented on JGRP-1850:
---------------------------------------
There was an update to WFLY-2632 for the same JGRP000031 error after my last comment here on June 12.
Radoslav Husar added a comment - 24/Jun/14 9:57 AM
We don't have a final fix yet, though you can ignore these warnings for now.
Unfortunately I cannot ignore the error. Immediately after cluster start, I am acquire locks no problem. But as soon as any application node is restarted, the errors appear and all attempts to acquire a lock fail.
Paul Ferraro works on both WildFly and HA-JDBC. He confirmed both are affected.
> jGroups 3.4.3 timeouts after a node leaves and rejoins cluster
> --------------------------------------------------------------
>
> Key: JGRP-1850
> URL: https://issues.jboss.org/browse/JGRP-1850
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.3
> Environment: Tomcat 7.0.54
> Java 7u45 x32
> HA-JDBC 3.0.0, 3.0.1, 3.0.2, 3.0.3-SNAPSHOT
> Debian 5 x64
> Reporter: Justin Cranford
> Assignee: Bela Ban
> Attachments: catalina.out.bz2, ha-jdbc-jgroups-tcp.xml
>
>
> I have this open thread on HA-JDBC forum. The issue seems to be jGroups. I attached my Tomcat log there with steps to reproduce the issue.
> http://sourceforge.net/p/ha-jdbc/discussion/383397/thread/843c60ad/?limit...
> Here is an example of what my jGroups error looks like, copied from the HA-JDBC thread. I can reproduce this quite often, possibly every time I try it, but not sure if it happens 100% of the time. I have reproduced it at least half a dozen times.
> May 09, 2014 12:01:45 AM net.sf.hajdbc.logging.slf4j.SLF4JLogger log
> FINE: Received MemberAcquireLockCommand(writeLock()) from 10.0.0.187
> May 09, 2014 12:01:46 AM org.jgroups.logging.JDKLogImpl debug
> FINE: 10.0.0.188: sending are-you-alive msg to 10.0.0.187
> May 09, 2014 12:01:49 AM org.jgroups.logging.JDKLogImpl debug
> FINE: 10.0.0.188: sending are-you-alive msg to 10.0.0.187
> May 09, 2014 12:01:50 AM org.jgroups.logging.JDKLogImpl debug
> FINE: 10.0.0.188: sending are-you-alive msg to 10.0.0.187
> May 09, 2014 12:01:51 AM net.sf.hajdbc.logging.slf4j.SLF4JLogger log
> WARNING: timeout sending message to 10.0.0.187
> org.jgroups.TimeoutException: timeout sending message to 10.0.0.187
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:419)
> at net.sf.hajdbc.distributed.jgroups.JGroupsCommandDispatcher.execute(JGroupsCommandDispatcher.java:177)
> at net.sf.hajdbc.lock.distributed.DistributedLockManager$DistributedLock.lockCoordinator(DistributedLockManager.java:420)
> at net.sf.hajdbc.lock.distributed.DistributedLockManager$DistributedLock.lockInterruptibly(DistributedLockManager.java:320)
> at net.sf.hajdbc.sql.DatabaseClusterImpl.activate(DatabaseClusterImpl.java:864)
> at net.sf.hajdbc.sql.DatabaseClusterImpl.activate(DatabaseClusterImpl.java:156)
> May 09, 2014 12:01:51 AM net.sf.hajdbc.logging.slf4j.SLF4JLogger log
> FINE: Received MemberAcquireLockCommand(writeLock()) from 10.0.0.187
> May 09, 2014 12:01:53 AM org.jgroups.logging.JDKLogImpl debug
> FINE: 10.0.0.188: sending are-you-alive msg to 10.0.0.187
> May 09, 2014 12:01:54 AM org.jgroups.logging.JDKLogImpl debug
> FINE: 10.0.0.188: sending are-you-alive msg to 10.0.0.187
> May 09, 2014 12:01:57 AM org.jgroups.logging.JDKLogImpl debug
> FINE: 10.0.0.188: sending are-you-alive msg to 10.0.0.187
> May 09, 2014 12:01:57 AM net.sf.hajdbc.logging.slf4j.SLF4JLogger log
> WARNING: timeout sending message to 10.0.0.187
> org.jgroups.TimeoutException: timeout sending message to 10.0.0.187
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:419)
> at net.sf.hajdbc.distributed.jgroups.JGroupsCommandDispatcher.execute(JGroupsCommandDispatcher.java:177)
> at net.sf.hajdbc.lock.distributed.DistributedLockManager$DistributedLock.lockCoordinator(DistributedLockManager.java:420)
> at net.sf.hajdbc.lock.distributed.DistributedLockManager$DistributedLock.lockInterruptibly(DistributedLockManager.java:320)
> at net.sf.hajdbc.sql.DatabaseClusterImpl.activate(DatabaseClusterImpl.java:864)
> at net.sf.hajdbc.sql.DatabaseClusterImpl.activate(DatabaseClusterImpl.java:156)
> May 09, 2014 12:01:57 AM net.sf.hajdbc.logging.slf4j.SLF4JLogger log
> FINE: Received MemberAcquireLockCommand(writeLock()) from 10.0.0.187
> May 09, 2014 12:01:58 AM org.jgroups.logging.JDKLogImpl debug
> FINE: 10.0.0.188: sending are-you-alive msg to 10.0.0.187
> May 09, 2014 12:02:01 AM org.jgroups.logging.JDKLogImpl debug
> FINE: 10.0.0.188: sending are-you-alive msg to 10.0.0.187
> May 09, 2014 12:02:02 AM org.jgroups.logging.JDKLogImpl debug
> FINE: 10.0.0.188: sending are-you-alive msg to 10.0.0.187
> May 09, 2014 12:02:03 AM net.sf.hajdbc.logging.slf4j.SLF4JLogger log
> WARNING: timeout sending message to 10.0.0.187
> org.jgroups.TimeoutException: timeout sending message to 10.0.0.187
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:419)
> at net.sf.hajdbc.distributed.jgroups.JGroupsCommandDispatcher.execute(JGroupsCommandDispatcher.java:177)
> at net.sf.hajdbc.lock.distributed.DistributedLockManager$DistributedLock.lockCoordinator(DistributedLockManager.java:420)
> at net.sf.hajdbc.lock.distributed.DistributedLockManager$DistributedLock.lockInterruptibly(DistributedLockManager.java:320)
> at net.sf.hajdbc.sql.DatabaseClusterImpl.activate(DatabaseClusterImpl.java:864)
> at net.sf.hajdbc.sql.DatabaseClusterImpl.activate(DatabaseClusterImpl.java:156)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-2632) JGroups drops unicast messages after shutdown/restart
by Justin Cranford (JIRA)
[ https://issues.jboss.org/browse/WFLY-2632?page=com.atlassian.jira.plugin.... ]
Justin Cranford commented on WFLY-2632:
---------------------------------------
I am experiencing the same JGRP000031 error with JGroups 3.4.3 and 3.4.4. However, I was trying JGroups 3.4 with Tomcat 7 & HA-JDBC 3.0 instead of WildFly. The symptoms are identical - restart an application server in the JGroups cluster, and it logs these JGRP000031 errors. Restart the cluster and the errors disappear.
I added myself to the watchlist for this WFLY-2632 bug. I previously reported it on the HA-JDBC forum and in the JGroups bug tracker:
https://sourceforge.net/p/ha-jdbc/discussion/383397/thread/843c60ad/?limi...
https://issues.jboss.org/browse/JGRP-1850
Unfortunately I cannot ignore the warnings. If I try to acquire locks after cluster restart then all is ok, but if I try to acquire a lock after an application server restart then it fails. This is a blocker bug for me, and goes beyond Wildfly. My hope is if and when it is fixed for WildFly, I can apply the same fix to my situation.
> JGroups drops unicast messages after shutdown/restart
> -----------------------------------------------------
>
> Key: WFLY-2632
> URL: https://issues.jboss.org/browse/WFLY-2632
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 9.0.0.Beta1
>
>
> JGroups drops unicast messages (citing wrong destination) after a node in a cluster is shutdown and then restarted.
> The JGroups version in use is 3.4.1.Final.
> Steps to reproduce:
> - start two nodes A, B using the server configuration standalone-ha.xml to create a cluster
> - shutdown A
> - restart A
> - after restart, we see these messages:
> {noformat}
> 13:15:03,227 INFO [stdout] (ServerService Thread Pool -- 63)
> 13:15:03,228 INFO [stdout] (ServerService Thread Pool -- 63) -------------------------------------------------------------------
> 13:15:03,228 INFO [stdout] (ServerService Thread Pool -- 63) GMS: address=lenovo/web, cluster=web, physical address=127.0.0.1:55200
> 13:15:03,229 INFO [stdout] (ServerService Thread Pool -- 63) -------------------------------------------------------------------
> 13:15:03,414 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000094: Received new cluster view: [fred/
> web|3] (2) [fred/web, lenovo/web]
> 13:15:03,422 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000079: Cache local address is lenovo/web
> , physical addresses are [127.0.0.1:55200]
> 13:15:03,427 INFO [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 63) ISPN000128: Infinispan version: Infinispan 'Infinium' 6
> .0.0.CR1
> 13:15:03,533 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5
> -f005-ddb2-b377-46b165e2aa77
> 13:15:03,609 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 61) ISPN000031: MBeans were successfully registered to the platform
> MBean server.
> 13:15:03,610 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 62) ISPN000031: MBeans were successfully registered to the platform
> MBean server.
> 13:15:03,765 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 62) JBAS010281: Started default-host/distributable cache from web contain
> er
> 13:15:03,768 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 61) JBAS010281: Started dist cache from web container
> 13:15:03,906 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017534: Register web context: /distributable
> 13:15:03,978 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "distributable.war" (runtime-name : "distributable.war")
> 13:15:04,033 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5
> -f005-ddb2-b377-46b165e2aa77
> 13:15:04,059 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 13:15:04,060 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 13:15:04,060 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Beta2-SNAPSHOT "WildFly" started in 5193ms - Started 293 of 410 services (178 services are lazy, passive or on-demand)
> 13:15:04,533 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> 13:15:05,034 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> 13:15:05,534 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3623) Spurious ":" in @Resource annotation 'name' value results in invalid binding but no deployment error
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3623?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3623:
-----------------------------------------------
Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1139188|https://bugzilla.redhat.com/show_bug.cgi?id=1139188] from ASSIGNED to POST
> Spurious ":" in @Resource annotation 'name' value results in invalid binding but no deployment error
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3623
> URL: https://issues.jboss.org/browse/WFLY-3623
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: JBoss AS7 7.2.0.Final, 8.0.0.Final, 8.1.0.Final
> Reporter: Brian Stansberry
> Assignee: Bartosz Baranowski
> Attachments: 01134324.jar, dumpServices.txt
>
>
> See attached jar for a reproducer. Just deploy it. The jar includes it's own source.
> An @Resource annotation with a spurious ":" in the name attribute value results in an incorrect binding but no deployment failure:
> {code}
> @Resources({
> @Resource(
> // name="java:jboss/ResourceTestEJB", // ==> this works fine
> name="java:jboss:/ResourceTestEJB", // ==> this will not bind the JNDI correctly, and there is no error on deploying EJB
>
> type=com.test.ResourceEJB.class,
> lookup="java:global/01134324/ResourceEJBImpl")
> })
> {code}
> There is no error reported in the log.
> Using jndi-view op in the CLI, I see:
> {code}
> [standalone@localhost:9990 subsystem=naming] :jndi-view
> {
> "outcome" => "success",
> "result" => {
> "java: contexts" => {
> .....
> "java:jboss" => {
> ....
> "java:jboss:" => {"class-name" => "javax.naming.Context"},
> }
> }
> ....
> }
> {code}
> Any time the jndi-view op is run, the following is logged in the server.log:
> {code}
> 10:52:02,985 ERROR [org.jboss.as.naming] (management-handler-thread - 5) WFLYNAM0013: Failed to obtain jndi view value for entry java:jboss:.: javax.naming.NameNotFoundException: jboss: -- service jboss.naming.context.java.jboss.jboss:
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:132) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:47) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:72) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:603) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:481) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1060) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:296) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:165) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:204) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:133) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:154) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_45]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_45]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:150) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:297)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:536)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> If a proper binding can't be done per the annotation value, there should be an exception thrown triggering deployment rollback.
> I'll attach an MSC service dump in case it's useful.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3534) Transaction is not being shared by different operations within the same thread
by Richard Yang (JIRA)
[ https://issues.jboss.org/browse/WFLY-3534?page=com.atlassian.jira.plugin.... ]
Richard Yang commented on WFLY-3534:
------------------------------------
We are facing this issue in 8.1.0.Final. It is a show stopper for us.
Could you have this fix patched to 8.1.0.Final? or provide jars for us to replace?
Thanks.
> Transaction is not being shared by different operations within the same thread
> ------------------------------------------------------------------------------
>
> Key: WFLY-3534
> URL: https://issues.jboss.org/browse/WFLY-3534
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 9.0.0.Alpha1
> Reporter: Pedro Igor
> Assignee: Pedro Igor
> Fix For: 9.0.0.Alpha1
>
>
> When injecting a JPA-based PartitionManager configuration in a EJB as follows:
> {code}
> @Resource(mappedName = "picketlink/JPADSBasedPartitionManager")
> private PartitionManager jpaDSBasedPartitionManager;
> {code}
> The IDM operations are executed without share the same EntityManager instance. This causes some strange behaviors such as not being able to retrieve data stored from a previous operation during a method execution.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (DROOLS-625) Implement a passive pattern
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-625:
----------------------------------
Summary: Implement a passive pattern
Key: DROOLS-625
URL: https://issues.jboss.org/browse/DROOLS-625
Project: Drools
Issue Type: Feature Request
Reporter: Mario Fusco
Assignee: Mario Fusco
Prepending a pattern with a '?' should make it passive (i.e. non reactive to right insertions) as dimostrated by the following test case.
{code}
@Test
public void testPassiveInsert() throws Exception {
String str =
"global java.util.List list\n" +
"rule R when\n" +
" $i : Integer()\n" +
" ?String( this == $i.toString() )\n" +
"then\n" +
" list.add( $i );\n" +
"end\n";
KieSession ksession = new KieHelper()
.addContent(str, ResourceType.DRL)
.build()
.newKieSession();
List<Integer> list = new ArrayList<Integer>();
ksession.setGlobal("list", list);
ksession.insert(1);
ksession.insert("2");
ksession.fireAllRules();
assertEquals(0, list.size());
ksession.insert("1");
ksession.fireAllRules();
assertEquals(0, list.size());
ksession.insert(2);
ksession.fireAllRules();
assertEquals(1, list.size());
assertEquals(2, (int)list.get(0));
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (DROOLS-624) Passive queries behave in a reactive way
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-624:
----------------------------------
Summary: Passive queries behave in a reactive way
Key: DROOLS-624
URL: https://issues.jboss.org/browse/DROOLS-624
Project: Drools
Issue Type: Bug
Reporter: Mario Fusco
Assignee: Mark Proctor
The batch evaluation performed by phreak doesn't allow to take count of the sequence of the inserts performed into a kiesession between 2 consecutive fireAllRules. This means that the following test case succeeds as expected
{code}
@Test
public void testPassiveQuery2() throws Exception {
String str =
"global java.util.List list\n" +
"query Q (Integer i)\n" +
" String( this == i.toString() )\n" +
"end\n" +
"rule R @Eager(true) when\n" +
" $i : Integer()\n" +
" ?Q( $i; )\n" +
"then\n" +
" list.add( $i );\n" +
"end\n";
KieSession ksession = new KieHelper()
.addContent(str, ResourceType.DRL)
.build()
.newKieSession();
List<Integer> list = new ArrayList<Integer>();
ksession.setGlobal("list", list);
ksession.insert("1");
ksession.insert(1);
ksession.fireAllRules();
assertEquals(1, list.size());
}
{code}
but you got an activatoin even if the fact matched by the passive query is inserted (the String in this case) is inserted after. So the following test fails:
{code}
@Test
public void testPassiveQuery3() throws Exception {
String str =
"global java.util.List list\n" +
"query Q (Integer i)\n" +
" String( this == i.toString() )\n" +
"end\n" +
"rule R @Eager(true) when\n" +
" $i : Integer()\n" +
" ?Q( $i; )\n" +
"then\n" +
" list.add( $i );\n" +
"end\n";
KieSession ksession = new KieHelper()
.addContent(str, ResourceType.DRL)
.build()
.newKieSession();
List<Integer> list = new ArrayList<Integer>();
ksession.setGlobal("list", list);
ksession.insert(1);
ksession.insert("1");
ksession.fireAllRules();
System.out.println(list);
assertEquals(0, list.size());
}
{code}
Note that performing a further fireAllRules between the 2 insertions force the evaluation of the lefttTuple before the insertion of the fact matched by the passive query and the fixes the problem as demonstrated by this last test.
{code}
@Test
public void testPassiveQuery4() throws Exception {
String str =
"global java.util.List list\n" +
"query Q (Integer i)\n" +
" String( this == i.toString() )\n" +
"end\n" +
"rule R @Eager(true) when\n" +
" $i : Integer()\n" +
" ?Q( $i; )\n" +
"then\n" +
" list.add( $i );\n" +
"end\n";
KieSession ksession = new KieHelper()
.addContent(str, ResourceType.DRL)
.build()
.newKieSession();
List<Integer> list = new ArrayList<Integer>();
ksession.setGlobal("list", list);
ksession.insert(1);
ksession.fireAllRules();
ksession.insert("1");
ksession.fireAllRules();
System.out.println(list);
assertEquals(0, list.size());
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years