3.1-M1 - Can't get rules to build
by Tom Gonzalez
I am attempting to convert our application to use drools 3.1.M from
current use of 3.0.4.
I downloaded the binaries posted and am getting this very basic
exception when building our rules.
[java] Feb 19, 2007 5:21:25 PM
com.nortel.connect.rbuilder.RulePackage addR
ulesFromDrlFile
[java] INFO: adding Rules from: CBMRules.drl (with associated
DSL)
[java] Exception in thread "main" java.lang.NoSuchFieldError:
recognizer
[java] at
org.drools.lang.DRLLexer$DFA18.<init>(DRLLexer.java:3914)
[java] at org.drools.lang.DRLLexer.<init>(DRLLexer.java:3565)
[java] at
org.drools.compiler.DrlParser.getParser(DrlParser.java:78)
[java] at
org.drools.compiler.DrlParser.parse(DrlParser.java:110)
[java] at
org.drools.compiler.DrlParser.parse(DrlParser.java:96)
[java] at
com.nortel.connect.rbuilder.RulePackage.addRulesFromDrlFile(R
ulePackage.java:219)
Any suggestions for getting past this?
Thanks,
Tom G
16 years, 10 months
Bugs/Problems with 3.1.0M1
by Wolfgang Betz
Hello to all,
i would like to address some problems with 3.1.0M1:
I've noticed that:
- using eclipse 3.2.2, and JPDL Plugin 3.1.0 alpha3 a program using rules does
not stop at breakpoints in rules (RHS) - ok, its alpha, maybe i'm missing
something
- throws an internal NPE at parsing rules havin NO_LOOP set (even if parse
result caching is on)
- comparisons like "bpairl : BagsPerAirline(nrOfBusinessBags >= (500 + 333))"
throw NPE if field is null - maybe adressed by
http://jira.jboss.com/jira/browse/JBRULES-627
- when
BagsPerAirline(nrOfBusinessBags >= (500 + 333)) //gives all >= 833 BUT
BagsPerAirline(nrOfBusinessBags >= 500 + 333) //all >= 500!!!!!
- when
c : Flight(flightId == 1 | == (1+1))
// throws java.lang.UnsupportedOperationException:
// does not support method call
// isAllowed(Object object, InternalWorkingMemory workingMemoiry)
// at
// org.drools.rule.ReturnValueRestriction.
// isAllowed(ReturnValueRestriction.java:137)
Thanx a lot for the "from" extension :-)
16 years, 11 months
allowing self joining combinations
by Michael Neale
I know that we by default remove self joins, ie:
when
Foo()
Foo()
will not match for the same instance of Foo - is it possible to turn that
off? I know we talked about it at one point, not sure what the latest
position is (someone was asking me and I can't recall what our final
position is). FYI Jess and Jrules both self join by default.
17 years
ClassFieldInspector and Groovy Classes
by Terry Laurenzo
The attached diff (against 3.0.5 sources) adds a condition to the
ClassFieldInspector to not analyze methods named <clinit>. For some
reason, the Groovy compiler is outputing classes that were causing
this check to choke and throw an IllegalArgumentException because of
a <clinit> method with ACC_PUBLIC access code.
Applying this patch allows Drools to operate correctly with compiled
Groovy Fact classes.
This seems like a pretty innocuous change that someone should apply
to SVN. Unfortunately, it is rather difficult to create a test case
for it.
Terry Laurenzo
17 years
Persistent store and web administration
by Schwenker, Stephen
Hello,
We have been using jboss rules for 6 months now and find it to be a good
tool overall. On the other hand we have noticed a few down sides.
Currently our rule engine runs on a jboss server and is deployed in a
sar. Every time we want to change the rules, we have to re-package and
re-deploy the app.
We want to advance our solution by providing a web application to
administer the rules. The first step of this will be to create a form
of persistent store for the rules. My first thought is to put it into a
database because we can then manage it easily with a web admin. Has
anyone done some work on this or can give me some ideas on how I should
start working on this? I'm willing to contribute some of my code to the
project if anyone is interested.
Thank you,
Steve.
17 years
Persistent store and web administration
by Schwenker, Stephen
Hello,
We have been using jboss rules for 6 months now and find it to be a good
tool overall. On the other hand we have noticed a few down sides.
Currently our rule engine runs on a jboss server and is deployed in a
sar. Every time we want to change the rules, we have to re-package and
re-deploy the app.
We want to advance our solution by providing a web application to
administer the rules. The first step of this will be to create a form
of persistent store for the rules. My first thought is to put it into a
database because we can then manage it easily with a web admin. Has
anyone done some work on this or can give me some ideas on how I should
start working on this? I'm willing to contribute some of my code to the
project if anyone is interested.
Thank you,
Steve.
17 years
quick design ideas re deployment to runtimes (rule agent)
by Michael Neale
I have been looking at JBoss Cache (Tree Cache specifically, not pojo
cache), as a default way of deploying from BRMS to runtime systems.
This mean the runtime system, as well as the -core jar, will also have an
optional dependency on jboss cache - and be able to be hooked into a named
jboss cache on the network. The BRMS (or anything) can then progressively
update rulebases with binary packages. Each runtime (rule-agent) also has a
local persistent store, so servers can be cold started without BRMS or cache
"cloud" being up on the network (it just uses the latest versions). Multiple
versions could exist in parallel with different names in the cache.
This may all sound more complex then it is, but from a users point of view
it will be very simple to use.
Plan B, is to have a task to emit a binary serialized blob to distribute by
hand (kind of like Edsons ant task can do).
If anyone has experience with jboss cache/tree cache, let me know, I would
appreciate any advice and assistance.
17 years, 1 month
drools eclipse reorg
by Mark Proctor
I'm just in the process of automating the eclipse plugin, so things
might be broken for a bit :)
I'm creating a new top level directory drools-eclipse. drools-ide will
move undernath this and be renamed to drools-eclipse-plugin,
drools-ide-feature will move underneath and be renamed
drools-eclipse-feature.
Mark
17 years, 1 month
Fact counts in drools
by Jim Majure
I have what I think is a very simple rule to implement, but I can't find a way to do it without "cheating" by using an eval/function. Here's the basic rule in English:
Reject a claim if it contains a treatment that has already been claimed more than 70 times
in the same calendar month.
In other words, I need to count the number of instances of the treatment that have already been paid.
Assume for the sake of this discussion, my facts are instances of the Treatment class.
If I replace "70" with, say, "2" in this rule I could do this:
rule
when
Treatment(id=="t1", status=="pending")
Treatment(id=="t1", status=="paid")
Treatment(id=="t1", status=="paid")
then
assert ( new Rejection("reason"));
end
Unfortunately, I can't simply replace "70" with "2", and using the same strategy to check for 70 instances doesn't seem quite right.
Am I missing something very simple here? Are there standard strategies to deal with this type of rule?
17 years, 1 month
Another big refactor for BRMS - FYI (for people who build from source)
by Michael Neale
To facilitate re-using some Cool Stuff (tm) between the web and the IDE - I
have moved common classes into drools-compiler (about 2 dozen and change).
They are all in the org.drools.brms package in drools-compiler (and unit
tests to match) in case we want to move them again.
I also change drools-jbrms to, obviously, remove the stuff that is now in
compiler. I also had to do a few tricks for the GWT launcher and compiler,
so it knows where to find source that the GUI needs, but thats all good.
So, you WILL need to:
cd drools-compiler
mvn install
(to update the deps that jbrms needs)
cd drools-jbrms
mvn package
Any problems, hassle me.
17 years, 1 month
