[JBoss JIRA] Created: (JBRULES-2343) Context assist in DSLR Editor
by Hamza Bakkali (JIRA)
Context assist in DSLR Editor
-----------------------------
Key: JBRULES-2343
URL: https://jira.jboss.org/jira/browse/JBRULES-2343
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.0.1.FINAL
Environment: Eclipse 3.4 Ganymede
Reporter: Hamza Bakkali
Assignee: Mark Proctor
Fix For: 4.0.8
I have been using drools 4 for couple of months now and I am starting to get the hang of it. We recently decided to move to Dools 5 with Eclipse 3.4.2 (Ganymede).
We unfortunately hit a major 'show stopper' (for us). In the DSLR editor: Context Assist + space + enter removes/replaces the whole line, not only the place holder.
In other words:
DSL:
[*][]Log : {msg}=System.out.println("{msg}");
[*][]id1="some id label"
DSLR:
rule "MyRule"
when
then
end
If I Press L , control space --> the line Log:{msg} appears in the context menu. Hit enter I get
Log :{msg}
Now, If want to replace msg by id1. I position the cursor in the {msg}, hit ctrl space, id1 shows in the list. I hit enter the whole line disappear, and I am left with
id1
instead of
Log : id1
Is this a setting somewhere in eclipse itself?? I doubt it.
The same thing use to work as expected in Drools 4.
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, 11 months
[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
14 years, 11 months
[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
14 years, 11 months
[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
14 years, 11 months