I am trying to accomplish a couple of things:
1) I want to fire all rules and then have the rules constantly being
evaluated as facts are created,updated, and deleted, i.e. there are
situations where its not feasible to have all the facts inserted upfront
before firing all rules.
2) Once a rule
Upgrading to 1.3.9 is completely safe. It is tested with drools. We did
not tested with 1..3.15, but should be ok too.
[]s
Edson
2008/11/19 hongyu lu <[EMAIL PROTECTED]>
> worse case is we switch to java dialect, although we do need to use jbrms
> for rule maintenance. is there a way to
I remember trying 1.4 with Drools 4.0.7 and it didn't work. Can't remember
exactly what the problem was, but there were some.
On Wed, Nov 19, 2008 at 2:14 PM, seemamani <[EMAIL PROTECTED]> wrote:
>
> I understand that Drools 4.0.7 internally uses JackRabbit 1.3. However this
> version of Jackrabb
worse case is we switch to java dialect, although we do need to use jbrms for
rule maintenance. is there a way to force jbrms to use java dialect globally(i
tried dialect "java" in the package header, but didn't seem to work)? we could
force java dialect on each rule but we really want to avoid
I understand that Drools 4.0.7 internally uses JackRabbit 1.3. However this
version of Jackrabbit is old and has many issues such as in the case of
clustering. The Jackrabbit mailing list has suggested using the new 1.4
version in which many bugs have been fixed. If I simply replace the
JackRabbit
Maxim,
Depending on your use case you may be able to disable shadow facts in your
Drools 4 instance. See the manual on when it is ok/not-ok to disable shadow
facts. Based on your description it probably is acceptable for your uses.
Disabling shadow facts may improve your performance, the manual
Keith,
If you're using the Java dialect try this syntax
Try this syntax:
JavaDialectConfiguration javaConf = (JavaDialectConfiguration)
pkgBuilderCfg.getDialectConfiguration( "java" );
javaConf.setCompiler( JavaDialectConfiguration.JANINO );
PackageBuilder builder = new Pa
it is 1.3.1 for jdk 1.4, the original one from 4.0.7 download. is it safe to
use a mvel lib for jdk 1.5? shall i grab 1.3.9 or the latest(1.3.15) since i
want to be conservative with a version well accepted by drools?
thanks!
Jeff
From: Edson Tirelli <[EMAIL
Hello everyone,
Please allow me to briefly describe how our system works:
We use drools as an efficient matching layers - I have X rules, in the RHS
of each rule I have a mark for each rule to signal that it has passed in the
current context (There are by definition more then 1 contexts). After
I have the following code:
PackageBuilder packageBuilder = null;
Properties properties = new Properties();
properties.setProperty( "drools.dialect.java.compiler","JANINO" );
PackageBuilderConfiguration cfg = new PackageBuilderConfiguration(
properties );
//error was thrown here complaining about
Jeff,
What mvel version are you using? (take a look at the jar name)
If it is not 1.3.9, try it out to check if the problem still happens.
[]s
Edson
2008/11/19 hongyu lu <[EMAIL PROTECTED]>
> Hi,
>
> I am seeking some help here for a very weird issue we ran into with drools
> 4.0
Hi,
I am seeking some help here for a very weird issue we ran into with drools
4.0.7. The error is intermittent but once happens it will be consistent for the
rest rule evaluation.
We have a fact object called com.like.rules.facts.AllocationFact. But somehow
the class name was messed up when p
12 matches
Mail list logo
