[JBoss JIRA] (DROOLS-1130) Using fireAllRules, Timed rules does not cascade rule execution after modifying a fact, event when Session conf is set to TimedRuleExectionOption.YES
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1130?page=com.atlassian.jira.plugi... ]
Mario Fusco closed DROOLS-1130.
-------------------------------
Resolution: Rejected
This is not a bug and the engine is working as expected. The TimedRuleExectionOption only affects the rules that have a declared timer and doesn't cascade on other rules. You need to explicitly call fireAllRules if you want the other rules to be evaluated.
> Using fireAllRules, Timed rules does not cascade rule execution after modifying a fact, event when Session conf is set to TimedRuleExectionOption.YES
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1130
> URL: https://issues.jboss.org/browse/DROOLS-1130
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Mario Fusco
> Attachments: timer-rule-bug.zip
>
>
> I have a DRL file with 2 rules and the first rule has a timer of 3s, after this rule gets fired and a fact is modified, i expect a second rule to get activate and trigger but is not happening. Even though the documentation explicitly said in the 2.9.2 section of:
> http://docs.jboss.org/drools/release/6.3.0.Final/drools-docs/html/ch02.ht...
> _When the rule engine runs in passive mode (i.e.: using fireAllRules) by default it doesn't fire consequences of timed rules unless fireAllRules isn't invoked again. Now it is possible to change this default behavior by configuring the KieSession with a *TimedRuleExectionOption*_
> Please advise if i have misunderstood the expected behavior, attached is a demo project enclosing the mentioned rules and a testcase.
> *DRL:*
> {code}
> import java.util.logging.Logger
> import bug.timedrules.Table
> rule "table with 1 player"
> timer( int: 3s)
> no-loop true
> when
> $table : Table( getCounter() == 1)
> then
> Logger.getLogger("timer.drl").info("triggered - counter is 1");
> modify($table){
> setCounter(2)
> }
> end
> rule "Table upgrade to 2 player"
> no-loop true
> when
> $table : Table( getCounter() == 2)
> then
> Logger.getLogger("timer.drl").info("triggered - counter is 2");
> modify($table){
> setCounter(3)
> }
> end
> {code}
> *java code:*
> {code}
> @Test
> public void executeNewRuleAfterTimedRuleExecution() throws Exception {
> KieBaseConfiguration config = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
> KieSessionConfiguration ksconf = KieServices.Factory.get().newKieSessionConfiguration();
> ksconf.setOption(TimedRuleExectionOption.YES);
> config.setOption(EventProcessingOption.STREAM);
> KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(config);
> final KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
> kbuilder.add(ResourceFactory.newClassPathResource("bug/timer/timer.drl", BugTest.class), ResourceType.DRL);
> if (kbuilder.hasErrors()) {
> throw new IllegalStateException(kbuilder.getErrors().toString());
> }
> kbase = KnowledgeBaseFactory.newKnowledgeBase(config);
> kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
> final StatefulKnowledgeSession statefulKnowledgeSession = kbase.newStatefulKnowledgeSession(ksconf, null);
> Table table = new Table(1234, 1);
> statefulKnowledgeSession.insert(table);
> statefulKnowledgeSession.fireAllRules();
> Thread.sleep(TimeUnit.SECONDS.toMillis(5));
> statefulKnowledgeSession.dispose();
> Assert.assertThat(table.getCounter(), CoreMatchers.is(3));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1682) Missleading tab completion for edit-batch-line command
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1682?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1682:
----------------------------------------------
The core commands tha tare impacted by the change of behaviour:
connect command, --controller
edit-batch-line, --line-number
holdback-batch, --name
move-batch-line, --current and --new
remove-batch-line, --line
if, --condition
patch, --patch-id
> Missleading tab completion for edit-batch-line command
> ------------------------------------------------------
>
> Key: WFCORE-1682
> URL: https://issues.jboss.org/browse/WFCORE-1682
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> Tab completion for edit-batch-list command suggest to use --line-number as a command option, but that is not how the command works.
> *command usage*
> {noformat}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] :read-resource
> [standalone@localhost:9990 / #] list-batch
> #1 /:read-resource
> [standalone@localhost:9990 / #] edit-batch-line 1 :read-attribute(name=launch-type)
> #1 :read-attribute(name=launch-type)
> [standalone@localhost:9990 / #] list-batch
> #1 :read-attribute(name=launch-type)
> {noformat}
> *actual*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> [standalone@localhost:9990 / #] edit-batch-line --<TAB>
> --help --line-number
> [standalone@localhost:9990 / #] edit-batch-line --line-number=1 :read-attribute(name=launch-type)
> Failed to parse line number '--line-number=1': For input string: "--line-number=1"
> {noformat}
> {{--line-number}} shouldn't be offered by tab completion for the command.
> Misleading tab completion ends up with syntax error.
> *expected*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> --help
> {noformat}
> The issue is a regression against EAP 7.0.0 release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1680) Tab completion for echo-dmr command is broken
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1680?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-1680:
-----------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1717
> Tab completion for echo-dmr command is broken
> ---------------------------------------------
>
> Key: WFCORE-1680
> URL: https://issues.jboss.org/browse/WFCORE-1680
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Jean-Francois Denise
>
> Tab completion for echo-dmr command doesn't work.
> To reproduce, start the standalone server and connect with CLI
> *actual 3.0.0.Alpha5-SNAPSHOT 77673c5*
> {noformat}
> [standalone@localhost:9990 /] echo-dmr /sub[TAB]
> core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
> [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
> core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
> {noformat}
> *expected*
> {noformat}
> [standalone@localhost:9990 /] echo-dmr /sub[TAB]
> [standalone@localhost:9990 /] echo-dmr /subsystem=
> [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
> [standalone@localhost:9990 /] echo-dmr /subsystem=logging
> {noformat}
> The issue is not reproducible with 2.2.0.CR7 (EAP 7.1.0.DR1).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6898) ConcurrentModificationException when returning from JMS onMessage() MBean
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6898?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-6898:
-----------------------------------
Issue Type: Bug (was: Feature Request)
> ConcurrentModificationException when returning from JMS onMessage() MBean
> -------------------------------------------------------------------------
>
> Key: WFLY-6898
> URL: https://issues.jboss.org/browse/WFLY-6898
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.1.0.CR1
> Reporter: Harold Campbell
> Assignee: Stuart Douglas
>
> I receive the following stacktrace when an MBean's onMessage() returns. The transaction is rolled back and the message marked as undelivered. This started sometime after nightly #2280 which works fine for me.
> 2016-07-30 21:51:49,273 TRACE [com.envestnet.ejb.winthorpe.optimizer.WinthorpeRunListener] (Thread-0 (ActiveMQ-client-global-threads-556320704)) Finished processing run 16819
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:159)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:256)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentDescription$5$1.processInvocation(MessageDrivenComponentDescription.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> at com.envestnet.ejb.winthorpe.optimizer.WinthorpeRunListener$$$view3.onMessage(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:139)
> at org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73)
> at com.envestnet.ejb.winthorpe.optimizer.WinthorpeRunListener$$$endpoint1.onMessage(Unknown Source)
> at org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:310)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1018)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:48)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1145)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:103)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
> at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
> at org.jboss.weld.context.AbstractContext.destroy(AbstractContext.java:160)
> at org.jboss.weld.context.AbstractManagedContext.deactivate(AbstractManagedContext.java:58)
> at org.jboss.weld.context.AbstractBoundContext.deactivate(AbstractBoundContext.java:72)
> at org.jboss.weld.context.ejb.EjbRequestContextImpl.deactivate(EjbRequestContextImpl.java:47)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:76)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6897) Replacing a disabled deployment destroys profile section of xml config
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6897?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-6897.
------------------------------------
Fix Version/s: 10.1.0.CR1
Assignee: Brian Stansberry (was: Jason Greene)
Resolution: Done
The WFCORE-1577 fix is in WildFly 10.1.0.CR1.
> Replacing a disabled deployment destroys profile section of xml config
> ----------------------------------------------------------------------
>
> Key: WFLY-6897
> URL: https://issues.jboss.org/browse/WFLY-6897
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.0.Final
> Environment: Fresh install of Wildfly 10 on Ubuntu 15.10 / JDK 8_101
> Reporter: Brian Rozmierski
> Assignee: Brian Stansberry
> Fix For: 10.1.0.CR1
>
>
> When replacing a deployment that is disabled at the time of replacement, Wildfly will write out a new configuration .xml that is missing the entire <profile> section, resulting in an application server that is, essentially, non-functional once restarted. There is no obvious effect until restart.
> Also note there is a forum post reporting this behavior from April.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1680) Tab completion for echo-dmr command is broken
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1680?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise edited comment on WFCORE-1680 at 8/1/16 9:16 AM:
----------------------------------------------------------------------
Looking at the src code, it seems that deployment-overlay, echo-dmr, batch-edit-line, if commands are passing a cursor value of 0.
OperationRequestCompleter and CommandCompleter are possibly impacted too.
was (Author: jdenise):
Looking at the src code, it seems that deployment-overlay, echo-dmr, batch-edit-line, if commands are passing a cursor value of 0.
OperationRequestCompleter is possibly impacted too.
> Tab completion for echo-dmr command is broken
> ---------------------------------------------
>
> Key: WFCORE-1680
> URL: https://issues.jboss.org/browse/WFCORE-1680
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Jean-Francois Denise
>
> Tab completion for echo-dmr command doesn't work.
> To reproduce, start the standalone server and connect with CLI
> *actual 3.0.0.Alpha5-SNAPSHOT 77673c5*
> {noformat}
> [standalone@localhost:9990 /] echo-dmr /sub[TAB]
> core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
> [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
> core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
> {noformat}
> *expected*
> {noformat}
> [standalone@localhost:9990 /] echo-dmr /sub[TAB]
> [standalone@localhost:9990 /] echo-dmr /subsystem=
> [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
> [standalone@localhost:9990 /] echo-dmr /subsystem=logging
> {noformat}
> The issue is not reproducible with 2.2.0.CR7 (EAP 7.1.0.DR1).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1680) Tab completion for echo-dmr command is broken
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1680?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1680:
----------------------------------------------
Looking at the src code, it seems that deployment-overlay, echo-dmr, batch-edit-line, if commands are passing a cursor value of 0.
OperationRequestCompleter is possibly impacted too.
> Tab completion for echo-dmr command is broken
> ---------------------------------------------
>
> Key: WFCORE-1680
> URL: https://issues.jboss.org/browse/WFCORE-1680
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Jean-Francois Denise
>
> Tab completion for echo-dmr command doesn't work.
> To reproduce, start the standalone server and connect with CLI
> *actual 3.0.0.Alpha5-SNAPSHOT 77673c5*
> {noformat}
> [standalone@localhost:9990 /] echo-dmr /sub[TAB]
> core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
> [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
> core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
> {noformat}
> *expected*
> {noformat}
> [standalone@localhost:9990 /] echo-dmr /sub[TAB]
> [standalone@localhost:9990 /] echo-dmr /subsystem=
> [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
> [standalone@localhost:9990 /] echo-dmr /subsystem=logging
> {noformat}
> The issue is not reproducible with 2.2.0.CR7 (EAP 7.1.0.DR1).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1682) Missleading tab completion for edit-batch-line command
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1682?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1682:
----------------------------------------------
WFCORE-1487 was logged and fixed in order to change the behaviour of completion to expose unnamed internal property name. So what you are observing seems the new expected behaviour.
I also think that it is misleading.
> Missleading tab completion for edit-batch-line command
> ------------------------------------------------------
>
> Key: WFCORE-1682
> URL: https://issues.jboss.org/browse/WFCORE-1682
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> Tab completion for edit-batch-list command suggest to use --line-number as a command option, but that is not how the command works.
> *command usage*
> {noformat}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] :read-resource
> [standalone@localhost:9990 / #] list-batch
> #1 /:read-resource
> [standalone@localhost:9990 / #] edit-batch-line 1 :read-attribute(name=launch-type)
> #1 :read-attribute(name=launch-type)
> [standalone@localhost:9990 / #] list-batch
> #1 :read-attribute(name=launch-type)
> {noformat}
> *actual*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> [standalone@localhost:9990 / #] edit-batch-line --<TAB>
> --help --line-number
> [standalone@localhost:9990 / #] edit-batch-line --line-number=1 :read-attribute(name=launch-type)
> Failed to parse line number '--line-number=1': For input string: "--line-number=1"
> {noformat}
> {{--line-number}} shouldn't be offered by tab completion for the command.
> Misleading tab completion ends up with syntax error.
> *expected*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> --help
> {noformat}
> The issue is a regression against EAP 7.0.0 release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-414) Queries do not work with chained accessors as arguments
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-414?page=com.atlassian.jira.plugin... ]
Mario Fusco updated DROOLS-414:
-------------------------------
Priority: Critical (was: Major)
> Queries do not work with chained accessors as arguments
> -------------------------------------------------------
>
> Key: DROOLS-414
> URL: https://issues.jboss.org/browse/DROOLS-414
> Project: Drools
> Issue Type: Feature Request
> Affects Versions: 5.5.0.Final, 6.0.1.Final
> Reporter: Davide Sottara
> Assignee: Mario Fusco
> Priority: Critical
>
> When processing a query CE that uses chained property accessors:
> when
> $x : Foo()
> myQuery( $x.bar ; )
> then
> the QueryElementBuilder considers the whole expression $x.bar as a variable. Since no variable with that name has been bound, it is taken to be a new declaration, and thus an output. This results in an inconsistent behavior, since an obvious constraint will be ignored.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months