April 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBRULES-3289) PackageBuilder.getErrors().toString() should use a clearer layout (indentation and empty lines)

by Geoffrey De Smet (Created) (JIRA)

PackageBuilder.getErrors().toString() should use a clearer layout (indentation and empty lines) ----------------------------------------------------------------------------------------------- Key: JBRULES-3289 URL: https://issues.jboss.org/browse/JBRULES-3289 Project: Drools Issue Type: Enhancement Security Level: Public (Everyone can see) Components: drools-compiler (expert) Reporter: Geoffrey De Smet Assignee: Edson Tirelli Fix For: 5.4.0.Beta1 It's hard to read the compilation errors in drools (and parsing them in my head). The main problem is parsing the points where the next compile error begins. By adding some indentation and removing some confusing empty lines this can be made a lot clearer. BEFORE: {code} Unable to resolve ObjectType 'NotExistingClass' : [Rule name='serviceLocationSpread'] Unable to Analyse Expression location == $location: [Error: unable to resolve method using strict-mode: org.drools.planner.examples.machinereassignment.domain.MrProcessAssignment.$location()] [Near : {... location == $location ....}] ^ [Line: 112, Column: 68] : [Rule name='serviceLocationSpread'] Rule Compilation error : [Rule name='serviceLocationSpread'] org/drools/planner/examples/machinereassignment/solver/Rule_serviceLocationSpread_503372c0945a4f2287a530f4ff3aee40.java (9:2095) : $location cannot be resolved // 2 extra empty lines {code} AFTER (with indentation): {code} Unable to resolve ObjectType 'NotExistingClass' : [Rule name='serviceLocationSpread'] Unable to Analyse Expression location == $location: [Error: unable to resolve method using strict-mode: org.drools.planner.examples.machinereassignment.domain.MrProcessAssignment.$location()] [Near : {... location == $location ....}] ^ [Line: 112, Column: 68] : [Rule name='serviceLocationSpread'] Rule Compilation error : [Rule name='serviceLocationSpread'] org/drools/planner/examples/machinereassignment/solver/Rule_serviceLocationSpread_503372c0945a4f2287a530f4ff3aee40.java (9:2095) : $location cannot be resolved {code} Just compare those two. The second one is easier to read diagonally and understand what's going wrong. It might be even better if the "Rule Compliation error" part comes first (following the context-first guideline): So instead of: {code} Error A1 Error A1 details Error A2 Error A2 details Rule Compilation error A Rule Compilation error A details Error B1 Error B1 details Error B2 Error B2 details Rule Compilation error B Rule Compilation error B details {code} We get: {code} Rule Compilation error A Rule Compilation error A details Error A1 Error A1 details Error A2 Error A2 details Rule Compilation error B Rule Compilation error B details Error B1 Error B1 details Error B2 Error B2 details {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

5
7
0 / 0

[JBoss JIRA] (JBRULES-3309) drools core and drools grid impl split packages osgi.

by surya aditya (Created) (JIRA)

drools core and drools grid impl split packages osgi. ----------------------------------------------------- Key: JBRULES-3309 URL: https://issues.jboss.org/browse/JBRULES-3309 Project: Drools Issue Type: Enhancement Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.3.0.Final Environment: windows, linux, osgi Reporter: surya aditya Assignee: Mark Proctor Priority: Blocker Fix For: 5.3.1.Final Split Packages in drools-core and drools-grid-impl. 1. drools-core has package org.drools.grid and is split between drools-core and drools-grid-impl. this causes issue in OSGI environment. If package can be completely moved to drools-grid-api/drools-grid-impl, it will be clean per OSGI best practice "avoid split packages" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

4
4
0 / 0

[JBoss JIRA] (JBRULES-3286) org.drools.time.TimerService.scheduleJob(Job, JobContext, Trigger) suddenly requires non-null JobContext

by Richard Calmbach (Created) (JIRA)

org.drools.time.TimerService.scheduleJob(Job, JobContext, Trigger) suddenly requires non-null JobContext -------------------------------------------------------------------------------------------------------- Key: JBRULES-3286 URL: https://issues.jboss.org/browse/JBRULES-3286 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (fusion) Affects Versions: 5.3.0.Final Reporter: Richard Calmbach Assignee: Mark Proctor See the forum reference above for context. As requested, this is the bug report for issue F3 in the post. The intro and description are copied from the original post: I am making extensive use of the event processing features of the Drools rule engine. Upgrading from Drools 5.2.0.Final to Drools 5.3.0.Final broke 47 of my unit tests and also broke my functional tests. There seem to be multiple changes in Drools 5.3.0 that cause incorrect behavior and/or break backward compatibility. Here are the results of my investigation so far. Issue F3: It is debatable whether this is a bug, but it is a backward-compatibility breaking change. Previously, when scheduling a job with org.drools.time.TimerService.scheduleJob(Job job, JobContext ctx, Trigger trigger) (for both real-time and pseudo clock), you could pass a null JobContext (say, because you didn't need one), and it would work. However, in Drools 5.3.0, this causes a NullPointerException at: org.drools.time.impl.DefaultTimerJobFactoryManager.createTimerJobInstance(Job, JobContext, Trigger, JobHandle, InternalSchedulerService) line: 25 I realize that if it's not in knowledge-api-<version>.jar, it's not an official API, but the available interfaces and classes in org.drools.time.** (as used in the Broker example) are *very* useful for test harnesses *and* for production code (for implementing dynamic timers, for instance). So, this is more of a heads-up: If you are suddenly getting an NPE, this might be the cause. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

6
7
0 / 0

[JBoss JIRA] (JBRULES-3284) Duplicate job scheduling in org.drools.time.impl.DefaultTimerJobInstance.call()

by Richard Calmbach (Created) (JIRA)

Duplicate job scheduling in org.drools.time.impl.DefaultTimerJobInstance.call() ------------------------------------------------------------------------------- Key: JBRULES-3284 URL: https://issues.jboss.org/browse/JBRULES-3284 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (fusion) Affects Versions: 5.3.0.Final Reporter: Richard Calmbach Assignee: Mark Proctor See the forum reference above for context. As requested, this is the bug report for issue F1 in the post. The intro and description are copied from the original post: I am making extensive use of the event processing features of the Drools rule engine. Upgrading from Drools 5.2.0.Final to Drools 5.3.0.Final broke 47 of my unit tests and also broke my functional tests. There seem to be multiple changes in Drools 5.3.0 that cause incorrect behavior and/or break backward compatibility. Here are the results of my investigation so far. Issue F1: While tracking down the failures of my unit tests, I experimented with the Broker example, and while probably not finding the root cause of the broken unit tests, I nonetheless came across what clearly seems to be incorrect behavior in the DefaultTimerJobInstance.call() method. The bug only reveals itself after all input has been processed, so it is masked by the fact that running the Broker demo through the entire sequence in stocktickstream.dat (1100 lines) takes a long time. In order to reveal the problem more quickly, run the demo with only the first 14 lines in stocktickstream.dat. Do so for both the 5.2.0 Broker demo (against Drools 5.2.0) and the 5.3.0 Broker demo (against Drools 5.3.0). The Broker example code in both versions is identical, so only the Drools-internal code changes matter. When running the 5.2.0 Broker demo to the end, you get one java.text.ParseException (given the structure of the example code, that's expected, albeit not elegant, and not the focus of our investigation). In particular, no matter how many lines stocktickstream.dat contains, you always get exactly one ParseException at the end. Contrast this with running the 5.3.0 Broker demo: At the end you get N occurrences of java.text.ParseException, where N is the number of lines in stocktickstream.dat. So for 14 lines you get 14 occurrences of ParseException. Looking at two specific methods shows us why: Method org.drools.examples.broker.events.EventFeeder.FeedJob.execute(JobContext): {code} public void execute(JobContext context) { this.sink.receive( ((FeedContext) context).event ); if ( this.source.hasNext() ) { ((FeedContext) context).setEvent( this.source.getNext() ); this.trigger.setNextFireTime( ((FeedContext) context).getEvent().getDate() ); clock.scheduleJob( this, context, trigger ); } } {code} Note in particular how this method already takes care of scheduling the next job execution by updating the next fire time of the job's existing FeedTrigger instance. Unfortunately, in Drools 5.3.0, DefaultTimerJobInstance.call() does a duplicate scheduling of the same job: Method org.drools.time.impl.DefaultTimerJobInstance.call(): {code} public Void call() throws Exception { this.trigger.nextFireTime(); // need to pop if ( handle.isCancel() ) { return null; } this.job.execute( this.ctx ); if ( handle.isCancel() ) { return null; } // our triggers allow for flexible rescheduling Date date = this.trigger.hasNextFireTime(); if ( date != null ) { scheduler.internalSchedule( this ); } return null; } {code} So, every job is duplicated and that's why there are 2*N calls to org.drools.examples.broker.events.StockTickPersister.load() instead of N. I think the rescheduling inside DefaultTimerJobInstance.call() is incorrect. For one, it breaks backward compatibility, and it is unexpected. The job should be in charge of deciding whether there is another job to schedule or what to do. Implicitly scheduling the next job just by updating the trigger time is a little too much magic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

7
8
0 / 0

[JBoss JIRA] (JBRULES-3285) NullPointerException in org.drools.time.impl.DefaultTimerJobInstance.compareTo(DefaultTimerJobInstance)

by Richard Calmbach (Created) (JIRA)

NullPointerException in org.drools.time.impl.DefaultTimerJobInstance.compareTo(DefaultTimerJobInstance) ------------------------------------------------------------------------------------------------------- Key: JBRULES-3285 URL: https://issues.jboss.org/browse/JBRULES-3285 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (fusion) Affects Versions: 5.3.0.Final Reporter: Richard Calmbach Assignee: Mark Proctor See the forum reference above for context. As requested, this is the bug report for issue F2 in the post. The intro and description are copied from the original post: I am making extensive use of the event processing features of the Drools rule engine. Upgrading from Drools 5.2.0.Final to Drools 5.3.0.Final broke 47 of my unit tests and also broke my functional tests. There seem to be multiple changes in Drools 5.3.0 that cause incorrect behavior and/or break backward compatibility. Here are the results of my investigation so far. Issue F2: This is the bug that causes my unit tests to fail. I have not pinpointed the root cause, but it seems to have to do with the event scheduling Drools does as part of its job execution mechanism. Its symptom is a NullPointerException during insertion of an event. What makes it so tricky is that with the out-of-the-box configuration, Drools catches such exceptions in org.drools.time.impl.PseudoClockScheduler.runCallBacks() and passes them to the aptly named "DoNothingSystemEventListener", which literally does nothing, not so much as logging (the methods are empty). So you don't actually know that the event insertion failed, you only wonder why your mock WorkingMemoryEventListener is telling you that your expectations are not met. The stack trace (as copied from the Eclipse Debug view, hence the unusual formatting) inside Drools is: Date.getMillisOf(Date) line: 939 Date.compareTo(Date) line: 959 DefaultTimerJobInstance.compareTo(DefaultTimerJobInstance) line: 38 DefaultTimerJobInstance.compareTo(Object) line: 13 PriorityQueue<E>.siftUpComparable(int, E) line: 582 PriorityQueue<E>.siftUp(int, E) line: 574 PriorityQueue<E>.offer(E) line: 274 PriorityQueue<E>.add(E) line: 251 PseudoClockScheduler.internalSchedule(TimerJobInstance) line: 136 PseudoClockScheduler.scheduleJob(Job, JobContext, Trigger) line: 126 ObjectTypeNode.assertObject(InternalFactHandle, PropagationContext, InternalWorkingMemory) line: 230 EntryPointNode.assertObject(InternalFactHandle, PropagationContext, ObjectTypeConf, InternalWorkingMemory) line: 244 NamedEntryPoint.insert(InternalFactHandle, Object, Rule, Activation, ObjectTypeConf) line: 330 NamedEntryPoint.insert(Object, boolean, boolean, Rule, Activation) line: 291 NamedEntryPoint.insert(Object) line: 116 NamedEntryPoint.insert(Object) line: 48 <my code calling into Drools> Here is method org.drools.time.impl.DefaultTimerJobInstance.compareTo(DefaultTimerJobInstance): {code} public int compareTo(DefaultTimerJobInstance o) { return this.trigger.hasNextFireTime().compareTo( o.getTrigger().hasNextFireTime() ); } {code} Essentially, this method calls java.util.Date.compareTo(Date) with a null argument, which, as documented, causes a NullPointerException. Sometimes, this.trigger.hasNextFireTime() already returns null, and then the NPE gets thrown in DefaultTimerJobInstance.compareTo() itself. I've seen different stack traces leading to this NPE, so this must be affecting scheduling and job execution quite broadly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

6
7
0 / 0

[JBoss JIRA] Created: (JBRULES-3228) Method for inserting facts via entryPoints from a DRL is not documented

by Michael Pellegrini (JIRA)

Method for inserting facts via entryPoints from a DRL is not documented ------------------------------------------------------------------------ Key: JBRULES-3228 URL: https://issues.jboss.org/browse/JBRULES-3228 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-docs Affects Versions: 5.3.0.CR1 Reporter: Michael Pellegrini Assignee: Mark Proctor The current documentation does not describe how to insert fact into a specific entryPoint from with the DRL. Either using the drools object reference or the shortcut version. rule "test" when then entryPoint["name"].insert() end -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

6
10
0 / 0

[JBoss JIRA] (JBRULES-3346) Batch execution code has not been finished and is missing tests

by Marco Rietveld (JIRA)

Marco Rietveld created JBRULES-3346: --------------------------------------- Summary: Batch execution code has not been finished and is missing tests Key: JBRULES-3346 URL: https://issues.jboss.org/browse/JBRULES-3346 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler, drools-core Affects Versions: 5.4.0.Beta1 Reporter: Marco Rietveld Assignee: Marco Rietveld Priority: Minor Fix For: 5.3.2.Final, 5.4.0.Beta2 See [here|https://github.com/droolsjbpm/drools/blob/622d359886bf687a8397214f16...] for an example. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

4
5
0 / 0

[JBoss JIRA] (JBRULES-3334) AbstractTabuAcceptor doesn't add the starting solution as tabu

by Patrik Dufresne (Created) (JIRA)

AbstractTabuAcceptor doesn't add the starting solution as tabu -------------------------------------------------------------- Key: JBRULES-3334 URL: https://issues.jboss.org/browse/JBRULES-3334 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-planner Affects Versions: 5.3.1.Final Reporter: Patrik Dufresne Assignee: Mark Proctor When setting a complete solution tabu, the starting solution is not considered a Tabu making it possible to visit the same solution again. Consider a situation where there is construction phase followed by a local search phase. The construction phase will create a solution that will not be added to the tabu list of the local search phased. To fix it, I suggest to override the function phaseStarted(...) in SolutionTabuAcceptor to add solution to the Tabu map. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

9
10
0 / 0

[JBoss JIRA] (JBRULES-3324) Refactor the Simulation Fluents for World Remoting

by Mark Proctor (Created) (JIRA)

Refactor the Simulation Fluents for World Remoting -------------------------------------------------- Key: JBRULES-3324 URL: https://issues.jboss.org/browse/JBRULES-3324 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Mark Proctor Assignee: Mark Proctor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

3
3
0 / 0

[JBoss JIRA] (JBRULES-3448) XLS Decision tables: Add support for Condition column DRL fragments

by Michael Anstis (JIRA)

Michael Anstis created JBRULES-3448: --------------------------------------- Summary: XLS Decision tables: Add support for Condition column DRL fragments Key: JBRULES-3448 URL: https://issues.jboss.org/browse/JBRULES-3448 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Michael Anstis Assignee: Michael Anstis Fix For: 5.5.0.Beta1 Condition columns in XLS Decision Tables have a row for Object type and a row for code "snippet". The code snippet is taken as predicates within the Object type; for example:- {code} CONDITION | CONDITION ---------------------------- MyFact ---------------------------- field1 == | field2 == ---------------------------- a | b {code} This is rather limiting (and certainly not conducive to decision table round-tripping). Ideally we need to support:- {code} CONDITION ---------------------------------------------- MyFact( field1 == $param1, field2 == $param2 ) ---------------------------------------------- ---------------------------------------------- a,b {code} Even more ideally it'd be good to be able to register "column handlers" so this can be extended easily. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
3
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2012