12:28 p.m.
Hi all,
I have some set of rules which work on same Person object but depending on
whether a person is student/employee/Faculty, the rule will have dfferent
logic.
So, I've made 3 .drl files, one will have all the rules for students, other
for employee and then last .drl for faculty. All 3 .drl have same package
name (as the first statement in drl) but all rules are named differently.
When my rule engine starts, it reads these 3 drl files and adds them to a
single rule base, starts a new session, inserts person in working memory and
fires rules.
Now, my questions are...is there anything odd/wrong with this approach?
Secondly, I had some rules names same in different drl and when I changed
them ....then I started getting null pointer exception error..... during
parsing of drl files. Any idea why is that?
code snippet:
list=new ArrayList<File>();
list.add(new File("students.drl"));
list.add(new File("emloyee.drl");
list.add(new File("faculty.drl"));
Iterator<File> it = list.iterator();
ruleBase = RuleBaseFactory.newRuleBase();
builder = new PackageBuilder();
Reader source=null;
while(it.hasNext())
{
source = new
InputStreamReader(RuleEngine.class.getResourceAsStream(it.next().toString()));
builder.addPackageFromDrl(source);
//if DRL has errors don't add it to the RuleBase
if(builder.hasErrors())
log4j.logError(RuleEngine.class, builder.getErrors().toString());
else
ruleBase.addPackage(builder.getPackage());
}
workingMemory = ruleBase.newStatefulSession();
workingMemory.insert(person);
workingMemory.fireAllRules();
--
View this message in context:
http://www.nabble.com/DRL-package-builder-or-rule-base-error-tp20627083p2...
Sent from the drools - user mailing list archive at Nabble.com.
1:19 p.m.
Vanshi,
In general it would be better to put all of the rules together in the
same drl file as they all relate to the same object and are all destined
for the same rule base. Though there is nothing fundamentally incorrect
about your approach in most cases you want related rules to managed and
deployed together.
As for your exception it is impossible to say without seeing your rules
and the exception. You can try sending them to the list and maybe
somebody will be able to help you.
Joe
-----Original Message-----
From: rules-users-bounces(a)lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] On Behalf Of vanshi
Sent: Friday, November 21, 2008 11:28 AM
To: rules-users(a)lists.jboss.org
Subject: [rules-users] DRL package builder or rule base error
Hi all,
I have some set of rules which work on same Person object but depending
on
whether a person is student/employee/Faculty, the rule will have
dfferent
logic.
So, I've made 3 .drl files, one will have all the rules for students,
other
for employee and then last .drl for faculty. All 3 .drl have same
package
name (as the first statement in drl) but all rules are named
differently.
When my rule engine starts, it reads these 3 drl files and adds them to
a
single rule base, starts a new session, inserts person in working memory
and
fires rules.
Now, my questions are...is there anything odd/wrong with this approach?
Secondly, I had some rules names same in different drl and when I
changed
them ....then I started getting null pointer exception error..... during
parsing of drl files. Any idea why is that?
code snippet:
list=new ArrayList<File>();
list.add(new File("students.drl"));
list.add(new File("emloyee.drl");
list.add(new File("faculty.drl"));
Iterator<File> it = list.iterator();
ruleBase = RuleBaseFactory.newRuleBase();
builder = new PackageBuilder();
Reader source=null;
while(it.hasNext())
{
source = new
InputStreamReader(RuleEngine.class.getResourceAsStream(it.next().toStrin
g()));
builder.addPackageFromDrl(source);
//if DRL has errors don't add it to the RuleBase
if(builder.hasErrors())
log4j.logError(RuleEngine.class,
builder.getErrors().toString());
else
ruleBase.addPackage(builder.getPackage());
}
workingMemory = ruleBase.newStatefulSession();
workingMemory.insert(person);
workingMemory.fireAllRules();
--
View this message in context:
http://www.nabble.com/DRL-package-builder-or-rule-base-error-tp20627083p
20627083.html
Sent from the drools - user mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
1:58 p.m.
On Fri, Nov 21, 2008 at 8:28 PM, vanshi <nilu.thakur(a)gmail.com> wrote:
Hi all,
I have some set of rules which work on same Person object but depending on
whether a person is student/employee/Faculty, the rule will have dfferent
logic.
So, I've made 3 .drl files, one will have all the rules for students, other
for employee and then last .drl for faculty. All 3 .drl have same package
name (as the first statement in drl) but all rules are named differently.
When my rule engine starts, it reads these 3 drl files and adds them to a
single rule base, starts a new session, inserts person in working memory
and
fires rules.
Now, my questions are...is there anything odd/wrong with this approach?
Secondly, I had some rules names same in different drl and when I changed
them ....then I started getting null pointer exception error..... during
parsing of drl files. Any idea why is that?
Hi vanshi,
In our system the rules are deployed in a similar method:
We have a "include.drl", "globles.drl", "common.drl" and the
specific rules
for each channel (C1, C2, C3).
The "include.drl" and "globles.drl" are inserted at system load to
each of
the filtering files (common, C1, C2...).
All the filtering files sit in the same package "com.XX.filtering".
Up until now I had no problems with this approach, the only thing that I'm
concerned with is the RuleBaes performance because we use several "Packages"
to build the sessions.
I hope someone on this list could answer if this working mode has effect on
performance?
--
Cheers,
Maxim Veksler
"Free as in Freedom" - Do u GNU ?
5:16 p.m.
You will not find any major impact in runtime performance, but it
obviously affects compile performance, because there are more rules to
compile.
The Rete algorithm is know for scaling very well to increasing number of
rules, as long as the rules activated for each working memory actions remain
constant.
Also, in the case of Drools, creating sessions is really cheap in terms
of performance, because most of the data structures, like node memories, are
lazily created and on an on-demand basis.
[]s
Edson
2008/11/21 Maxim Veksler <maxim.veksler(a)gmail.com>
On Fri, Nov 21, 2008 at 8:28 PM, vanshi <nilu.thakur(a)gmail.com> wrote:
>
> Hi all,
>
> I have some set of rules which work on same Person object but depending on
> whether a person is student/employee/Faculty, the rule will have dfferent
> logic.
>
> So, I've made 3 .drl files, one will have all the rules for students,
> other
> for employee and then last .drl for faculty. All 3 .drl have same package
> name (as the first statement in drl) but all rules are named differently.
> When my rule engine starts, it reads these 3 drl files and adds them to a
> single rule base, starts a new session, inserts person in working memory
> and
> fires rules.
>
> Now, my questions are...is there anything odd/wrong with this approach?
> Secondly, I had some rules names same in different drl and when I changed
> them ....then I started getting null pointer exception error..... during
> parsing of drl files. Any idea why is that?
>
Hi vanshi,
In our system the rules are deployed in a similar method:
We have a "include.drl", "globles.drl", "common.drl" and
the specific rules
for each channel (C1, C2, C3).
The "include.drl" and "globles.drl" are inserted at system load to
each of
the filtering files (common, C1, C2...).
All the filtering files sit in the same package "com.XX.filtering".
Up until now I had no problems with this approach, the only thing that I'm
concerned with is the RuleBaes performance because we use several "Packages"
to build the sessions.
I hope someone on this list could answer if this working mode has effect on
performance?
--
Cheers,
Maxim Veksler
"Free as in Freedom" - Do u GNU ?
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
8:45 p.m.
Thanks everybody for the responses.
Scanning through old posts here, I found out that each time a new DRL is
added to package builder, all the rules from the previous DRL are also
compiled again. So, that means, the rules in the first DRL will compile 3
times unnecessarily. So, I'm going to put all rules in just one drl. If
anybody wishes to see mor details then check out the end of this thread
where this behaviour has been discussed......plz look towards the end.
http://www.nabble.com/RuleBase-addPackage-failure-td6603598.html#a6607165
I noticed that when I chaged the name of some rules then I started getting
null pointer exception with this stack trace.
java.lang.NullPointerException
at org.drools.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:224)
at org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:270)
at org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:656)
at
org.drools.common.AbstractRuleBase.mergePackage(AbstractRuleBase.java:519)
at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:409)
at
com.uhg.scs.optum.ng.rules.RuleEngine.parseRuleFiles(RuleEngine.java:102)
at com.uhg.scs.optum.ng.rules.RuleEngine.<clinit>(RuleEngine.java:46)
at
com.uhg.scs.optum.ng.unittest.HaRulesOldUnitTests.<init>(HaRulesOldUnitTests.java:20)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at junit.framework.TestSuite.createTest(TestSuite.java:61)
at junit.framework.TestSuite.addTestMethod(TestSuite.java:283)
at junit.framework.TestSuite.<init>(TestSuite.java:146)
at
org.junit.internal.runners.JUnit38ClassRunner.<init>(JUnit38ClassRunner.java:67)
at
org.junit.internal.builders.JUnit3Builder.runnerForClass(JUnit3Builder.java:14)
at
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
Guessing ....that removing/renaming rules must proceed with some clean up
first...anybody has any idea how to cleanly do that??
--
View this message in context:
http://www.nabble.com/DRL-package-builder-or-rule-base-error-tp20627083p2...
Sent from the drools - user mailing list archive at Nabble.com.
9 p.m.
Is this still true? That was back in Drools 3, but I thought this was
fixed a long time ago... Mark may confirm that.
[]s
Edson
2008/11/21 vanshi <nilu.thakur(a)gmail.com>
Thanks everybody for the responses.
Scanning through old posts here, I found out that each time a new DRL is
added to package builder, all the rules from the previous DRL are also
compiled again. So, that means, the rules in the first DRL will compile 3
times unnecessarily. So, I'm going to put all rules in just one drl. If
anybody wishes to see mor details then check out the end of this thread
where this behaviour has been discussed......plz look towards the end.
http://www.nabble.com/RuleBase-addPackage-failure-td6603598.html#a6607165
I noticed that when I chaged the name of some rules then I started getting
null pointer exception with this stack trace.
java.lang.NullPointerException
at
org.drools.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:224)
at
org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:270)
at
org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:656)
at
org.drools.common.AbstractRuleBase.mergePackage(AbstractRuleBase.java:519)
at
org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:409)
at
com.uhg.scs.optum.ng.rules.RuleEngine.parseRuleFiles(RuleEngine.java:102)
at
com.uhg.scs.optum.ng.rules.RuleEngine.<clinit>(RuleEngine.java:46)
at
com.uhg.scs.optum.ng.unittest.HaRulesOldUnitTests.<init>(HaRulesOldUnitTests.java:20)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at junit.framework.TestSuite.createTest(TestSuite.java:61)
at junit.framework.TestSuite.addTestMethod(TestSuite.java:283)
at junit.framework.TestSuite.<init>(TestSuite.java:146)
at
org.junit.internal.runners.JUnit38ClassRunner.<init>(JUnit38ClassRunner.java:67)
at
org.junit.internal.builders.JUnit3Builder.runnerForClass(JUnit3Builder.java:14)
at
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at
org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
Guessing ....that removing/renaming rules must proceed with some clean up
first...anybody has any idea how to cleanly do that??
--
View this message in context:
http://www.nabble.com/DRL-package-builder-or-rule-base-error-tp20627083p2...
Sent from the drools - user mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
9:21 p.m.
I see.....I would wait for Mark's response in this case... before I change
anything. But surprisingly when I put all the rules in single DRL then this
null pointer exception is gone. What could be the cause of that??
Is this still true? That was back in Drools 3, but I thought this was
fixed a long time ago... Mark may confirm that.
[]s
Edson
--
View this message in context:
http://www.nabble.com/DRL-package-builder-or-rule-base-error-tp20627083p2...
Sent from the drools - user mailing list archive at Nabble.com.
5845
days inactive
5846
days old
6 comments
4 participants
participants (4)
-
Edson Tirelli -
Joe White -
Maxim Veksler -
vanshi