Problem with function
by Natraj Gudla
With 4.0.0 i am getting the run time exception on functions. what could be
the problem
*Exception*
**
*
java.lang.NullPointerException
*
at org.drools.base.ClassTypeResolver.resolveType(*ClassTypeResolver.java:127
*)
at org.drools.rule.builder.dialect.java.JavaFunctionBuilder.build(*
JavaFunctionBuilder.java:72*)
at org.drools.rule.builder.dialect.java.JavaDialect.addFunction(*
JavaDialect.java:434*)
at org.drools.compiler.PackageBuilder.addFunction(*PackageBuilder.java:350*)
at org.drools.compiler.PackageBuilder.addPackage(*PackageBuilder.java:259*)
at org.drools.compiler.PackageBuilder.addPackageFromDrl(*PackageBuilder.java
:147*)
at com.drools.sample.ParseDRL.readRuleFromDrl(*ParseDRL.java:86*)
at com.drools.sample.ParseDRL.main(*ParseDRL.java:25*)
Exception in thread "main"
*My Function:*
*
function* *double* getROI(loanAmount){
*double* roI=0.0;*
**if*( loanAmount <= 499000 )
roI = 18;*
**else* *if*( loanAmount <= 999000 )*
*roI = 17;*
**else* *if*( loanAmount <= 1990000 )*
*roI = 14.5;*
**else* *if*( loanAmount <= 3990000 )*
*roI = 12;*
**else* *if*( loanAmount <= 7490000 )*
*roI = 11.5;*
**else* *if*( loanAmount > 7490000 )*
*roI = 9.99;*
**return* roI;
}
Thanks
Natraj Gudla
16 years, 9 months
rete view colours appear diffirent to documentation
by Aakil Omar
I was busy trying to draw a rete view according to what I was understanding
from the documentation, but thought it prudent to create the rule in the ide
and then look at the rete view there before assuming that I am correct. I
had a bit of shock at first as it did not look at all as I expected. After a
few deep breaths realized that the colors are probably just different. I
need confirmation if I am reading it correctly please.
Jboss Rules Documentation:
Rete Nodes
In the Eclipse IDE Rete view
It looks like the ObjectTypeNodes are Red not blue and
AlphaNodes are blue not red and the rest is the same as the documentation.
Can someone please confirm this for me before I get it all wrong.
Thanks
Aakil
16 years, 9 months
Trouble with BRMS on newly released 4.0
by Wagner Rick - rwagne
Hi all,
Thanks for all the hard work going into 4.0.
Could you please help me diagnose a problem I'm having with the BRMS?
I've installed it on Tomcat 6 and JBossWS1.0.1, but under both when I
try to access localhost/drools-jbrms I get only a banner header and a
new URL:
http://localhost:8080/drools-jbrms/org.drools.brms.JBRMS/JBRMS.html
The log shows nothing out of the ordinary...
Thanks,
Rick
***************************************************************************
The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be legally
privileged.
If the reader of this message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.
If you have received this communication in error, please resend this
communication to the sender and delete the original message or any copy
of it from your computer system.
Thank You.
****************************************************************************
16 years, 9 months
Partial "not"?
by Yuri de Wit
I have a case where I need to negate only part of the predicates.
RULE1
when:
c1 : Child()
c2 : Child(hashCode < c1.hashCode, prop1==c1.prop1, ... propN==c1.propN)
then:
insert(new Parent(c1, c2));
RULE2
when
p:Parent()
c1:Child(this memberOf p)
not Child(this memberOd p, prop1==c1.prop1, ...propN==c1.propN)
then
retract(p);
While in rule1 I use a matching criteria to group c1 and c2, in rule2
I want to use the inverse of the same exact criteria to ungroup them.
I dont care which propN no longer holds, as long as the any of the
propN no longer holds. The problem is that I still need the "positive"
this memberOf p. How to solve this problem?
RULE2
when
p:Parent()
c1:Child(this memberOf p)
Child(
this memberOd p,
not(prop1==c1.prop1, ...propN==c1.propN)
)
then
retract(p);
(afaik, not supported)
any ideas?
16 years, 9 months
Few rules, many facts
by Yuri de Wit
I am working on a drools application with few rules and large number
of facts. In my first design I tried to avoid excessive joins thinking
I was helping improve performance but didnt realized that I was
actually shooting myself in the foot. I was basically creating a
single facade-fact that would contain two or three diff concerns
joined under the same interface. The problem I am seeing is that for
simple things like changing the status of one of many facts would
cause that fact to be reevaluated against all the other facts.
I then realized that thinking relationally about the problem would not
only simplify my solution but also probably make a lot faster.
However, in this new and relational solution I will need to make use
of many "not" CE.
My question is: is there any cost in using "not"s that I should be
awae of? Any other words of wisdom re: improving the performance in
small rules x many facts?
thanks,
-- yuri
16 years, 9 months
