November 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2218) Unknown error while parsing. This is a bug. Please contact the Development team.

by Udo Klinkmüller (JIRA)

Unknown error while parsing. This is a bug. Please contact the Development team. -------------------------------------------------------------------------------- Key: JBRULES-2218 URL: https://jira.jboss.org/jira/browse/JBRULES-2218 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-eclipse Affects Versions: 5.0.0.FINAL Environment: Eclipse 3.5 (Galileo), Mac OS X Reporter: Udo Klinkmüller Assignee: Mark Proctor rule "Arrival-Delayed-Upd" salience 1000 when #conditions VisitPair( $ov: oldVisit != null, $nv: visit ) $oaf: ArrivalFlight( onBlock == null, $ost: scheduledTime != null, $op: position != null ) from $ov.arrivalFlight $naf: ArrivalFlight( onBlock == null, (($nst: scheduledTime != null, != $ost) || ($np: position != null, != $op)) ) from $nv.arrivalFlighT then #actions Date vf = addMinutes($nst, 15); ResourceEvent re = eventBuilderFactory.getResourceVisitEventBuilder(EventType.ARRIVAL_DELAYED, $naf.getPositionKey(), vf) .visitKey($nv.getKey()) .build(); eventHandler.handleEvent(re); 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

13 years, 8 months

7
12
0 / 0

[JBoss JIRA] Created: (JBRULES-2151) Parser exceptions

by Edson Tirelli (JIRA)

Parser exceptions ----------------- Key: JBRULES-2151 URL: https://jira.jboss.org/jira/browse/JBRULES-2151 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.0.1.FINAL Reporter: Edson Tirelli Assignee: Edson Tirelli Fix For: 5.1.0.M1 Parser errors that raise the "Contact the development team" message. ================= a similar "contact-developers-bug" occurs when you write an empty not CE: not( ) ================= -- 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

13 years, 8 months

2
7
0 / 0

[JBoss JIRA] Created: (JBRULES-2106) Allow "implicit" operators in the language

by Edson Tirelli (JIRA)

Allow "implicit" operators in the language ------------------------------------------ Key: JBRULES-2106 URL: https://jira.jboss.org/jira/browse/JBRULES-2106 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-compiler, drools-core Affects Versions: 5.0.1.FINAL Reporter: Edson Tirelli Assignee: Edson Tirelli Fix For: 5.1.0.M1 It would be cool if we could develop and enable "implicit" operators. By that I mean, a method that returns a boolean and take 1 parameter could be used automatically. Example: Person( name startsWith "Edson" ) The engine would understand the "startsWith" implicit operator, and would call the method on the name String. -- 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

13 years, 8 months

2
5
0 / 0

[JBoss JIRA] Created: (JBRULES-1769) Improvements to pluggable operator framework

by Edson Tirelli (JIRA)

Improvements to pluggable operator framework -------------------------------------------- Key: JBRULES-1769 URL: https://jira.jboss.org/jira/browse/JBRULES-1769 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Edson Tirelli Assignee: Edson Tirelli e-mail from Michel Zimmermann: ----------- Hi Edson, I think I got it working :-) Edson Tirelli wrote: > For an example, look at the file SetEvaluatorsDefinition and look at > the BaseMemberOf inner class. So, all the logic is in there, but we > still used subclasses just to set the constructor attributes and > override the toString() method, but you could still implement > everything in a single class I guess. Yes, this approach makes sense as long as you don't need to use the different VariableContextEntry subclasses for handling double, char etc. Yet, this can be handled, too. toString(): You can avoid subclassing from your BaseMyEvaluatorClass to override toString() by using a string method like: public String toString() { return getValueType().getName() + " " + getOperator().getOperatorString(); } Regarding the evaluator API: If you only need one evaluator class (subclassed from BaseEvaluator), personally I don't like the > 10 static calls to addEvaluator(type, operator, myEvaluatorInstance) in the EvaluatorDefinition class. So, how about adding the method addDefaultEvaluator(operator, evaluatorClass) to EvaluatorCache, see attachment? This would allow you to register a evaluator as default and only overide the special cases... PS: If you are interested I will write some small tutorial about custom evaluators / operators in drools trunk. This might take a week or two, though. Any preferences regarding the format? Thanks for the help.... cu, Michael @SuppressWarnings("unchecked") public void addDefaultEvaluator(final Operator operator, Class evaluatorClass) { // define the constructor Class[] evaluatorParameters = new Class[2]; evaluatorParameters[0] = ValueType.class; evaluatorParameters[1] = Operator.class; // get the constructor try { Constructor<BaseEvaluator> constructor; constructor = evaluatorClass.getConstructor( evaluatorParameters ); // add feault operators addEvaluator(ValueType.ARRAY_TYPE, operator, constructor.newInstance(ValueType.ARRAY_TYPE, operator)); addEvaluator(ValueType.BIG_DECIMAL_TYPE, operator, constructor.newInstance(ValueType.BIG_DECIMAL_TYPE, operator)); addEvaluator(ValueType.BIG_INTEGER_TYPE, operator, constructor.newInstance(ValueType.BIG_INTEGER_TYPE, operator)); addEvaluator(ValueType.BOOLEAN_TYPE, operator, constructor.newInstance(ValueType.BOOLEAN_TYPE, operator)); addEvaluator(ValueType.PBOOLEAN_TYPE, operator, constructor.newInstance(ValueType.PBOOLEAN_TYPE, operator)); addEvaluator(ValueType.BYTE_TYPE, operator, constructor.newInstance(ValueType.BYTE_TYPE, operator)); addEvaluator(ValueType.PBYTE_TYPE, operator, constructor.newInstance(ValueType.PBYTE_TYPE, operator)); addEvaluator(ValueType.CHAR_TYPE, operator, constructor.newInstance(ValueType.CHAR_TYPE, operator)); addEvaluator(ValueType.PCHAR_TYPE, operator, constructor.newInstance(ValueType.PCHAR_TYPE, operator)); addEvaluator(ValueType.DATE_TYPE, operator, constructor.newInstance(ValueType.DATE_TYPE, operator)); addEvaluator(ValueType.DOUBLE_TYPE, operator, constructor.newInstance(ValueType.DOUBLE_TYPE, operator)); addEvaluator(ValueType.PDOUBLE_TYPE, operator, constructor.newInstance(ValueType.PDOUBLE_TYPE, operator)); addEvaluator(ValueType.FLOAT_TYPE, operator, constructor.newInstance(ValueType.FLOAT_TYPE , operator)); addEvaluator(ValueType.PFLOAT_TYPE, operator, constructor.newInstance(ValueType.PFLOAT_TYPE, operator)); addEvaluator(ValueType.INTEGER_TYPE, operator, constructor.newInstance(ValueType.INTEGER_TYPE, operator)); addEvaluator(ValueType.PINTEGER_TYPE, operator, constructor.newInstance(ValueType.PINTEGER_TYPE, operator)); addEvaluator(ValueType.LONG_TYPE, operator, constructor.newInstance(ValueType.LONG_TYPE, operator)); addEvaluator(ValueType.PLONG_TYPE, operator, constructor.newInstance(ValueType.PLONG_TYPE, operator)); addEvaluator(ValueType.OBJECT_TYPE, operator, constructor.newInstance(ValueType.OBJECT_TYPE, operator)); addEvaluator(ValueType.SHORT_TYPE, operator, constructor.newInstance(ValueType.SHORT_TYPE, operator)); addEvaluator(ValueType.PSHORT_TYPE, operator, constructor.newInstance(ValueType.PSHORT_TYPE, operator)); addEvaluator(ValueType.STRING_TYPE, operator, constructor.newInstance(ValueType.STRING_TYPE, operator)); } catch (SecurityException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (NoSuchMethodException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IllegalArgumentException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (InstantiationException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IllegalAccessException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (InvocationTargetException e) { // TODO Auto-generated catch block e.printStackTrace(); } } -- 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

13 years, 8 months

2
13
0 / 0

[JBoss JIRA] Created: (JBRULES-1455) Or / And used with DSL language

by M H (JIRA)

Or / And used with DSL language ------------------------------- Key: JBRULES-1455 URL: http://jira.jboss.com/jira/browse/JBRULES-1455 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.4 Reporter: M H Fix For: 4.0.5 DSL: [condition][]is a Person=Person() [condition][]- female=sex == "f" [condition][]- male=sex == "f" [condition][]- age {value}=age=={value} DSLR: rule when ($person: is a Person - male - age 60 or $person: is a Person - female - age 70) then end resolves to: | \/ .... ($person: Person( , sex="m", age == 60) or $person: Person(sex="f", age == 70)) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

3
15
0 / 0

[JBoss JIRA] Created: (JBRULES-1226) allow capture of match groups in 'matches' clauses

by Godmar Back (JIRA)

allow capture of match groups in 'matches' clauses -------------------------------------------------- Key: JBRULES-1226 URL: http://jira.jboss.com/jira/browse/JBRULES-1226 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.0.1 Reporter: Godmar Back Assigned To: Mark Proctor Please add a way to capture match groups in matches clauses. See http://lists.jboss.org/pipermail/rules-users/2007-September/003227.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

4
7
0 / 0

[JBoss JIRA] Created: (JBRULES-1322) Accumulate functions are highly unreliable for long's and BigDecimals

by Geoffrey De Smet (JIRA)

Accumulate functions are highly unreliable for long's and BigDecimals --------------------------------------------------------------------- Key: JBRULES-1322 URL: http://jira.jboss.com/jira/browse/JBRULES-1322 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.3 Reporter: Geoffrey De Smet Assigned To: Edson Tirelli Priority: Critical Fix For: 4.1.0 When dealing with financial data, one should never ever use double's. Instead BigDecimal should be used. Not because BigDecimal is bigger (that's rarely a problem) but because it doesn't do any decimal to binary transformation. For example, it's impossible for a double to correctly represent "0.2", aka 1/5. Summing many doubles (or even a few differing in scale), can easily give wrong results (and for financial data this tends to be important). Using doubles to sum longs have the exact same problem. Attached is a testcase patch which proves this by checking if (MAX_LONG - 4L) and 3L sum up to be (MAX_LONG - 1L). Currently they don't. One possible way to solve this is to fix JBRULES-1075, which just happens to give drools-solver 3% more performance ;) what a coincidence ^^ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

3
21
0 / 0

[JBoss JIRA] Created: (JBBUILD-640) Remove reporting section from the parent pom

by Paul Gier (JIRA)

Remove reporting section from the parent pom -------------------------------------------- Key: JBBUILD-640 URL: https://jira.jboss.org/browse/JBBUILD-640 Project: JBoss Build System Issue Type: Task Components: JBoss Parent POM Reporter: Paul Gier Assignee: Paul Gier Fix For: JBoss Parent POM - 6 The reporting section has been deprecated in Maven 3. Since the jboss parent POM requires Maven 3 by default, the reporting section should be removed. The site plugin configuration should be updated to generate the site reports once the site plugin works with Maven 3. https://cwiki.apache.org/MAVEN/maven-3x-and-site-plugin.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2238) Accumulate should be implemented with left-input incremental so they don't start from scratch on every left-input retraction/assertion

by Geoffrey De Smet (JIRA)

Accumulate should be implemented with left-input incremental so they don't start from scratch on every left-input retraction/assertion -------------------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-2238 URL: https://jira.jboss.org/jira/browse/JBRULES-2238 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.0.1.FINAL Reporter: Geoffrey De Smet Assignee: Mark Proctor The current accumulate implementation has a severe performance loss in the drools-solver context. Edson said that this issue could be the culprit. However, for this to be implemented the true modify feature should first be implemented. See the discussion "Why is this DRL twice as slow?" on the dev user list. >From IRC: <ge0ffrey> more and more of my experiments show the poisones nature of accumulate for drools-solver. Probably because they are backwards chained (as I understand it?). Of course accummulate is great for many use cases, just not drools-solver. <ge0ffrey> The problem is, I have no way to workaround them. I need the sum of my logically inserted objects. <etirelli> ge0ffrey: no, accumulate are implemented as forward chain as usual <etirelli> the problem is that a left-input retraction on an accumulate node will throw away any result and a leftinput assert will recalculate everything from scratch <ge0ffrey> What do you mean by "must fully recalculate"? <etirelli> mean from scratch <ge0ffrey> Why does it do that? <etirelli> remember that modify = retract+assert <ge0ffrey> And right-input retractions won't recalculate everything from scratch? <etirelli> no... right input are incremental <ge0ffrey> would making leftinput assert incremental too be possible? <etirelli> ge0ffrey: the only way to do left-input incremental is with a feature called "true modify" -- 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

13 years, 8 months

3
5
0 / 0

[JBoss JIRA] Created: (JBRULES-1466) please bail if user is using an incompatible MVEL

by Godmar Back (JIRA)

please bail if user is using an incompatible MVEL ------------------------------------------------- Key: JBRULES-1466 URL: http://jira.jboss.com/jira/browse/JBRULES-1466 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.0.4 Reporter: Godmar Back When using MVEL, please check String constants org.mvel.MVEL.VERSION and org.mvel.MVEL.VERSION_SUB to see if it's compatible. Bail if it isn't. Ignoring version mismatches leads to difficult to diagnose problems, see: http://lists.jboss.org/pipermail/rules-users/2008-February/004759.html http://lists.jboss.org/pipermail/rules-users/2008-February/004709.html Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

6
20
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2010