March 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBBUILD-504) Fix warning messages in the app server buld.

by Paul Gier (JIRA)

Fix warning messages in the app server buld. -------------------------------------------- Key: JBBUILD-504 URL: https://jira.jboss.org/jira/browse/JBBUILD-504 Project: JBoss Build System Issue Type: Task Components: JBossBuild/Buildmagic Reporter: Paul Gier Fix For: JBossBuild - Maint 2008 The app server build gives warning messages about the custom tasks being overridden for each module. This should be fixed so that these warnings do not continue. {quote} Trying to override old definition of task libraryset Trying to override old definition of task execmodules Trying to override old definition of task resolveproperties Trying to override old definition of task resolver Trying to override old definition of task require Trying to override old definition of task _dump Trying to override old definition of task _puke Trying to override old definition of task moduleinit Trying to override old definition of task moduleconfig Trying to override old definition of task modulelibrary Trying to override old definition of task projectinfo Trying to override old definition of task library Trying to override old definition of task Ant Trying to override old definition of task moduleinfo Trying to override old definition of task projecthelp Trying to override old definition of task propertyfilter Trying to override old definition of task call Trying to override old definition of task property {quote} -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2107) Support StateNode for Finite State Machines

by Mauricio Salatino (JIRA)

Support StateNode for Finite State Machines ------------------------------------------- Key: JBRULES-2107 URL: https://jira.jboss.org/jira/browse/JBRULES-2107 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-compiler (flow), drools-core (flow) Affects Versions: 5.1.0.M1 Reporter: Mauricio Salatino Assignee: Mauricio Salatino Support for StateNode for Finite State Machines -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2100) ExecuteResultHandler calls handleResult twice

by Jaroslaw Kijanowski (JIRA)

ExecuteResultHandler calls handleResult twice --------------------------------------------- Key: JBRULES-2100 URL: https://jira.jboss.org/jira/browse/JBRULES-2100 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.0.1.FINAL Reporter: Jaroslaw Kijanowski Assignee: Mark Proctor The receive() method in drools-core/src/main/java/org/drools/runtime/pipeline/impl/ExecuteResultHandler.java calls context.getResultHandler().handleResult( context.getResult() ); twice. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2122) SchedulerTest too impatient

by Martin Vecera (JIRA)

SchedulerTest too impatient --------------------------- Key: JBRULES-2122 URL: https://jira.jboss.org/jira/browse/JBRULES-2122 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 4.0.7 Reporter: Martin Vecera Assignee: Mark Proctor On line 184 in org/drools/reteoo/SchedulerTest.java is a sleep for a data structure to get filled. On some machines, the half second sleep is not sufficient and the tast permanently fails with data.size() == 3 instead of 4. Could the sleep be prolonged at least to one second? The drawback of this failure is SOA Platform certification on HP-UX IA64. We have to manually edit the sleep and rerun the test. This slows down the QE process. Actually, I got the problem with https://svn.jboss.org/repos/labs/labs/jbossrules/soa_tags/4.3.0.GA_IR1/ but it would affect more versions than just 4.0.7 IMHO. Could you please edit the "Affects Version/s" field to all potential versions? Many thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2234) Test Scenario shows green bar even though test failed

by Jeff DeLong (JIRA)

Test Scenario shows green bar even though test failed ----------------------------------------------------- Key: JBRULES-2234 URL: https://jira.jboss.org/jira/browse/JBRULES-2234 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-guvnor Affects Versions: 5.0.0.FINAL Reporter: Jeff DeLong Assignee: Mark Proctor A test scenario shows green even though no rules have run and the expectation is not met. Will attach repository_export.zip with that exhibits this behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
8
0 / 0

[JBoss JIRA] Created: (JBRULES-2260) MVEL not support multiple setters in modify

by Jeff DeLong (JIRA)

MVEL not support multiple setters in modify ------------------------------------------- Key: JBRULES-2260 URL: https://jira.jboss.org/jira/browse/JBRULES-2260 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Environment: JBoss Drool Core 5.1.0.trunk-N200908260601-H218 in Eclipse 3.5 (installed as part of JBoss Tools Nightly Build) Reporter: Jeff DeLong Assignee: Mark Proctor MVEL not support multiple setters in modify. The following results in an exception: modify(alert) {setServerHeartBeatStatus("down"), setPassportScannerStatus("down") } Description Resource Path Location Type BuildError: Unable to build expression for 'consequence': Failed to compile: 1 compilation error(s): - (4,-82) unable to resolve method using strict-mode: java.lang.Object.setServerHeartBeatStatus(java.lang.String) ' //actions modify(alert) {setServerHeartBeatStatus("down"), setPassportScannerStatus("down") } ' KioskEventRules.drl /kiosk-rules/src/main/rules line 156 Drools Error The expression does work if the dialect is Java. However the following works with the MVEL dialect: modify(alert) {passportScannerStatus = "down"} Also modify(alert) {serverHeartBeatStatus = "down", passportScannerStatus = "down" } I will also log this in the MVEL JIRA. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2299) Retracting events using PseudoClockScheduler causes ClassCastException

by Maciej Prochniak (JIRA)

Retracting events using PseudoClockScheduler causes ClassCastException ---------------------------------------------------------------------- Key: JBRULES-2299 URL: https://jira.jboss.org/jira/browse/JBRULES-2299 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core, drools-core (fusion) Affects Versions: 5.1.0.M1 Reporter: Maciej Prochniak Assignee: Mark Proctor When job is scheduled e.g. in sth like not A(this after [1s,10s] $a) and relevant event is retracted from working memory, the job should be removed. However, PseudoClockScheduler usues queue containing wrappers for job (ScheduledJob), and remove method tries to remove job without this wrapper which causes: java.lang.ClassCastException: org.drools.common.Scheduler$DuractionJob incompatible with org.drools.time.impl.PseudoClockScheduler$ScheduledJob at org.drools.time.impl.PseudoClockScheduler$ScheduledJob.compareTo(PseudoClockScheduler.java:188) at java.util.PriorityQueue.remove(PriorityQueue.java:355) at org.drools.time.impl.PseudoClockScheduler.removeJob(PseudoClockScheduler.java:121) at org.drools.common.Scheduler.removeAgendaItem(Scheduler.java:62) at org.drools.common.DefaultAgenda.removeScheduleItem(DefaultAgenda.java:451) at org.drools.common.ScheduledAgendaItem.remove(ScheduledAgendaItem.java:198) at org.drools.reteoo.RuleTerminalNode.retractLeftTuple(RuleTerminalNode.java:289) at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:131) at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:42) at org.drools.reteoo.NotNode.retractLeftTuple(NotNode.java:276) at org.drools.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:234) at org.drools.reteoo.EntryPointNode.retractObject(EntryPointNode.java:195) at org.drools.common.AbstractWorkingMemory.retract(AbstractWorkingMemory.java:1207) at org.drools.common.AbstractWorkingMemory.retract(AbstractWorkingMemory.java:1161) at org.drools.impl.StatefulKnowledgeSessionImpl.retract(StatefulKnowledgeSessionImpl.java:237) at pl.touk.droolsTest.PseudoSchedulerRemoveJobTest.testRule(PseudoSchedulerRemoveJobTest.java:61) ...more Solution would be probably to wrap job which should be removed -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-1944) Adding crontab type functionality for repetitive rules.

by Griz frf (JIRA)

Adding crontab type functionality for repetitive rules. ------------------------------------------------------- Key: JBRULES-1944 URL: https://jira.jboss.org/jira/browse/JBRULES-1944 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-api Affects Versions: FUTURE Reporter: Griz frf Assignee: Mark Proctor A convinient helper function to schedule rule executions in a similar manner to the cron utility would be useful. My specific use case is for a long running session to periodically write out data to a persistence store (db, file, etc) The current code for this is as follows : rule "DBpoll" duration(30s) when $d:String(toString=="Run") then System.out.println("30seconds elapsed"); Database.dosomething(); modify($d){}; end -------------------------------- session.insert(new String("Run")); --------------------------------- While this method does work, it requires the external dummy object trigger. In dynamically generated rules and rules pulled in from libraries, etc (not under the current developers control) it is difficult to ensure that a suibtable trigger is available. Therefore a cron like function would solve this issue. I envision the EVERY keyword and possibly a COUNT or for loop style format rule "DBpoll" EVERY(30s, 100) <-- means every 30 seconds for 100 iterations. or EVERY(30s, 10m) <-- every 30 seconds for 10 mins then System.out.println("30seconds elapsed"); Database.dosomething(); end -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-2431) Typo on Drools Fusion website

by Bruce Mitchener (JIRA)

Typo on Drools Fusion website ----------------------------- Key: JBRULES-2431 URL: https://jira.jboss.org/jira/browse/JBRULES-2431 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Bruce Mitchener Assignee: Mark Proctor http://www.jboss.org/drools/drools-fusion.html In the TOC, the 2nd entry reads: What is Event Processin (or Complex Event Processing, CEP)? But should read: What is Event Processing (or Complex Event Processing, CEP)? Just a small typo... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1804) Logical insertion lingers after the rule that inserted it no longer supports it (with testcase patch)

by Geoffrey De Smet (JIRA)

Logical insertion lingers after the rule that inserted it no longer supports it (with testcase patch) ----------------------------------------------------------------------------------------------------- Key: JBRULES-1804 URL: https://jira.jboss.org/jira/browse/JBRULES-1804 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.0.0.M2 Reporter: Geoffrey De Smet Assignee: Edson Tirelli Priority: Critical Fix For: 5.0.0.M3 This one got me headscratching for a while, untill I realized what the problem is. Tim reported on the mailing list he ran into it to. I've commmited a testcase in subversion, in TruthMaintenanceTest, called disabled_testLogicalInsertionsModifySameRuleGivesDifferentLogicalInsertion Remove the "disabled_" to enable it and try it out. Here's what happens in the testcase: 3 sensors with tempature 100, 200 and 200 are inserted. There's a rule which logically inserts all encountered tempatures, so 100 and 200. Then the first sensor modifies to a tempature of 150. As it turns out, the encoutered tempatures should be 150 and 200 now, but instead it's 100, 150 and 200. Even though there is no sensor that has a tempature of 100. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

4
17
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2010