Is Rules 4 different from rules 3?
by Joshua Jackson
Dear all,
I haven't had time exploring the latest rules 4 yet. But is it any
different from rules 3? Because from what I see from the rules 4
documentation, it's basically still the same. Will there will be no
migration effort from 3 to 4?
Thanks in advance.
--
Let's create a highly maintainable and efficient code
YM!: thejavafreak
Blog: http://www.nagasakti.or.id/roller/joshua/
18 years
How to get value of global variable from one rule to another
by Alexander Komissarov
Hello,
Please give me advice for best way storing global variables.
global java.lang.Integer res;
global java.lang.Integer res2;
...
I've several number of rules. One rule has variable initialization e.g.:
...
rule "AmountsAreNotNull" salience 20
when
< conditions >
then
...
res = new Integer(a.compareTo(new BigDecimal(25)));
res = (res == -1)?0:res;
res = (res == -1)?0:res;
res2 = new Integer(a.compareTo(b));
res2 = (res2 == -1)?0:res2;
...
end
The values of these variables are proper and equal 1
Then next rule has comparing for res|res2 values, but they have lost their
values (res == null and res2 == null)
rule "CompareValues" salience 10
when
res:Integer(intValue == 0)
res2:Integer(intValue == 0)
result:List()
then
result.add(Boolean.TRUE);
end
What decision you can advise me to save variables value between rules?
Thanks.
____________________
Regards,
Komissarov Alexander
mail: aleks.komissarov(a)gmail.com
icq: 239128267
18 years
Drools for spreadsheet style calculation
by Ming Fang
Hi Drools users,
I'm looking to use Drools to implement spreadsheet style calculation.
Here is an example with cells A, B, C
A = 1;
B = A + 1;
C = A + B;
One way of implementing this is to create a named fact I called Cell.
class Cell{
String name;
double value;
//left out constructor and getters/setters
}
Then the rules can look like this
rule "A"
when
Cell(name == "a")
then
//no-op
end
rule "B"
salience -20
no-loop
when
Cell(a: value, name == "a")
b: Cell(name == "b")
then
b.setValue(a + 1);
modify(b);
end
rule "C"
salience -30
no-loop
when
Cell(a: value, name == "a")
Cell(b: value, name == "b")
c: Cell(name == "c")
then
c.setValue(a + b);
modify(c);
System.out.println("C");
end
Now for this to work I need to first insert the three Cells, a, b, c.
Then anything I update a or b, c will be recalculated.
I want to hear what the experts think of think approach.
Is this optimal?
Can Drools automatically figure out the dependency? (In this case C
depends on A, B and therefore has the lowest salience value).
Can we add a initialization section in the DRL file? (like a static
init block).
--ming
18 years
Auditing for stateless session
by Budyanto Himawan
Hi,
I'm using the 4.0 version of the rules engine. In the old version we were
able to enable auditing by doing this
WorkingMemory workingMemory = ruleBase.newWorkingMemory();
// create a new Working Memory Logger, that logs to file.
WorkingMemoryFileLogger logger = new WorkingMemoryFileLogger(workingMemory);
Now if I use a stateful session, I can still do this. StateFulSession
extends WorkingMemory. For StatelessSession, however, this is not possible.
It does not extend WorkingMemory. Is there anyway I can have auditing for
StatelessSession?
Appreciate your help.
Thanks
Budyanto
18 years
typed grammar in DSL
by B Berteh
Hello,
I'd like to use extensively the DSL feature in order to provide
paraphrasing for rules... and still ensure that only syntactically rules
can be build.
This discussion mixes up IDE and rules core (dsl) issues.
Ideally I'd define DSL shortcuts with type handling to prevent common
errors in rule creation. My DSL would include, eg:
[when] The date {date} is outdated =
eval(Calendar.getInstance(TimeZone.getDefault()).getTime() <
date.getTime())
[date] today =
Calendar.getInstance(TimeZone.getDefault())
[date] {people}'s birthday =
people.getBirthday()
[people] Jack =
People.get("Jack")
And the selfcompletion would only provide the "date" placeholders when I
am completing the first LHS "when", hiding any other LHS, RHS or
[people] template.
A few related questions:
- Is this already available and if yes how/where?
- Is this of interest to anyone? currently working thereon?
- I'm willing to foster that question into JBoss Rules if no one is
doing it, as I'd need it... yesterday ;o) any comment/input/remark
would therefore be welcome.
Ideally this would bring the DSL feature close to a BNF grammar
declaration that provides implementation translation.
To go event further one should eventually take care of multiple
variables with same type, that would self-complete with the relevant
templates. like in:
[when] {date_1} was at least 100 years before {date_2} =
#java code ~ date_1.getTime() + 100 years < date_2.getTime()
and eventually take care of "parametric variables". In the following
example selecting Jack as people_1 would allow to select Car or Bike for
his transport means, but no Aircraft... that would be available to Rita
only.
[when] {people_1} has a dog and a {transport[people_1]} =
eval(people_1.hasTransport(transport)
[people] Jack =
People.get("Jack")
[people] Rita =
People.get("Rita")
#some transports are not available to Jack, like an aircraft
[transport[people]] Jack -> Car =
Transport._CAR
[transport[people]] Jack -> Bike =
Transport._BIKE
[transport[people]] Rita -> Aircraft =
Transport._AIRCRAFT
I actually did build rules from such strongly-typed grammars and
contextual behaviors (called parametric variables above) in other
prototypical systems. The final quality of the rules where satisfactory,
but the execution engine was not, so I am switching to JBoss... but
would rather not loose the type checking as it greatly improves the
quality of the designes rules from my experience.
Thanks for reading this long post, and feel free to give me any comment
you got.
Bertrand.
_________________________________________________________________
Tout ce qu'il y a de plus trendy pour Windows Live Messenger...
http://divertissements.fr.msn.be/funwithmessenger
18 years
possible classloading issue, causing rule to not evaluate properly
by Thong Nguyen
Hi,
I'm having an issue with the following rule NOT evaluating properly when
fired from a rulebase/package built on a web container vs. directly in
something like eclipse:
rule "Test Rule"
no-loop true
when
Customer( $name : name, $city : city )
Customer( ($name == "john" || $city == "la") )
then
System.out.println("you qualified");
end
For some reason when I run this rule on a standalone test class (with name
set to "john") it seems to fire and i get the "you qualified" printed out.
But the same exact rule, which I have configured to be accessable to fire
from within my web application does fire, but will not evaluate to true. I
have the same exact code building the package in both situations, same jars
and same Customer fact being asserted into session. The only difference I
can tell so far is classloaders that was used to load the standalone vs the
webapp PackageBuilder config.
>From standalone (run from eclipse), I have the following:
PackageBuilderConfiguration
- Compiler set to: 1 (JANINO)
- JavaLanguage set to: 1.4
- classloader: sun.misc.Launcher$AppClassLoader
>From webapp, I have the following for config;
- Compiler set to: 1 (JANINO)
- JavaLanguage set to: 1.4
- classloader: WebappClassLoader
delegate: false
repositories:
/WEB-INF/classes/
----------> Parent Classloader:
org.apache.catalina.loader.StandardClassLoader@10045eb
I'm running Tomcat 5.52 on JVM1.5.0_11-b03
I've tried searching everywhere and can't seem to figure out what's going
on. My only guess is maybe I have some extra jar loaded in my web container
or maybe they are loaded in the wrong order. Any pointers would be great -
been at this for the whole day.
Thanks for your time,
Thong
18 years
RE: [rules-users] change "assert" to "insert"+ other changes
by Michael Rhoden
I have a question related to this. Is there a way within a rule that you
can add 30 days to a date...
//mydate within last 30 days
mydate + 30 > getdate()
then dosomething()
I would only want mydate modified for this rule only not re-asserted on
the stack with a new date. Also if someone could point me in the
direction of some good info on dealing with dates in rules, love to see
more examples.
------------------------------------------------------------------------
-----------------------
-MVEL has sugar to do: modify ( person ) { age += 1, location = "london"
}, what actually happens here is it first calls modifyRetract then
applies the setters and then calles modifyAssert.
------------------------------------------------------------------------
-----------------------
Thanks,
-Michael
_____
From: rules-users-bounces(a)lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Mark Proctor
Sent: Tuesday, June 12, 2007 3:39 PM
To: Rules Dev List
Cc: Rules Users List
Subject: [rules-users] change "assert" to "insert"+ other changes
Ok, I'm now doing these changes.
Mark Proctor wrote:
I've had no further feedback on this, so I'm going to make this
change as part of the next milestone release (this week) - these
changes are considerable.
assert will change to insert
-avoid the constant keyword collision with "assert", most languages
are seem to support this now
-will change in both the drl and working memory api
modify to become update
-instead of workingMemory.modify(FactHandle, Object) it will be
workingMemory.update(FactHandle, Object), will change modify to
update in drl.
-this method is now only used for ShadowFact objects, it's a method
to let the engine know that an external object has been updated and
to update it's internal cache. and reprocess.
-avoid keyword collision in MVEL which has nice "modify" sugar now
insertObject, retractObject and updateObject to beome insert, retract
and update
-the Object part seems superflous, might as well remove it,
especially as we start to support none Object fact types
-drl and working memory api will now use the same method names.
added new WorkingMemory modifyRetract and modifyAssert methods
-allows for non shadow fact objects.
-When not using shadow facts (although will ofcourse work with shadow
facts) you cannot call 'update', or what use to be called 'modify',
because we need to know the "old" value of fields so we can retract
the from the workign memory. The only safe way is to first retract
the object and then assert it. However with the existing api this
adds extra work and results in new fact handle. modifyRetract and
modifyAssert can now be used together to "simulate" a modify on a
none shadow fact object in two parts. First call modifyRetract, then
change your field values, then call modifyAssert.
-MVEL has sugar to do: modify ( person ) { age += 1, location =
"london" }, what actually happens here is it first calls
modifyRetract then applies the setters and then calles modifyAssert.
Mark
Greg Barton wrote:
I think it's a good idea, so ya, change to "insert"
GreG
--- Mark Proctor <mproctor(a)codehaus.org> wrote:
We have been getting querries with regards to jdk
assert collision and
jboss rules assert, for this reason we are thinking
of changing it to
insert for 4.0. Further to that its causing language
integrations issues
for us as we expand pluggeable dialects. For this
reason we are thinking
of chaning assert to insert, this would be an api
change and a language
level change. I'd thought I'd throw this out to the
community before we
do it. This of course breaks backwards
compatability.
Mark
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
__________________________________________________________________
__________________Get the free Yahoo! toolbar and rest assured
with the added security of spyware protection.
http://new.toolbar.yahoo.com/toolbar/features/norton/index.php
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_____
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
18 years
change "assert" to "insert"+ other changes
by Mark Proctor
I've had no further feedback on this, so I'm going to make this change
as part of the next milestone release (this week) - these changes are
considerable.
assert will change to insert
-avoid the constant keyword collision with "assert", most languages are
seem to support this now
-will change in both the drl and working memory api
modify to become update
-instead of workingMemory.modify(FactHandle, Object) it will be
workingMemory.update(FactHandle, Object), will change modify to update
in drl.
-this method is now only used for ShadowFact objects, it's a method to
let the engine know that an external object has been updated and to
update it's internal cache. and reprocess.
-avoid keyword collision in MVEL which has nice "modify" sugar now
insertObject, retractObject and updateObject to beome insert, retract
and update
-the Object part seems superflous, might as well remove it, especially
as we start to support none Object fact types
-drl and working memory api will now use the same method names.
added new WorkingMemory modifyRetract and modifyAssert methods
-allows for non shadow fact objects.
-When not using shadow facts (although will ofcourse work with shadow
facts) you cannot call 'update', or what use to be called 'modify',
because we need to know the "old" value of fields so we can retract the
from the workign memory. The only safe way is to first retract the
object and then assert it. However with the existing api this adds extra
work and results in new fact handle. modifyRetract and modifyAssert can
now be used together to "simulate" a modify on a none shadow fact object
in two parts. First call modifyRetract, then change your field values,
then call modifyAssert.
-MVEL has sugar to do: modify ( person ) { age += 1, location = "london"
}, what actually happens here is it first calls modifyRetract then
applies the setters and then calles modifyAssert.
Mark
Greg Barton wrote:
> I think it's a good idea, so ya, change to "insert"
>
> GreG
>
> --- Mark Proctor <mproctor(a)codehaus.org> wrote:
>
>
>> We have been getting querries with regards to jdk
>> assert collision and
>> jboss rules assert, for this reason we are thinking
>> of changing it to
>> insert for 4.0. Further to that its causing language
>> integrations issues
>> for us as we expand pluggeable dialects. For this
>> reason we are thinking
>> of chaning assert to insert, this would be an api
>> change and a language
>> level change. I'd thought I'd throw this out to the
>> community before we
>> do it. This of course breaks backwards
>> compatability.
>>
>> Mark
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
>
>
>
> ____________________________________________________________________________________Get the free Yahoo! toolbar and rest assured with the added security of spyware protection.
> http://new.toolbar.yahoo.com/toolbar/features/norton/index.php
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
18 years
