Rule not compiling in IDE after migration to 5.2
by Jamie
This rule used to compile in the IDE under Drools 5.1.1:
when
$order: OrderFact(numberOfCreditCardDeclines >
FraudCCDeclines.find().getCreditCardDeclinesThreshold())
then
//do something
but it's breaking since I moved to 5.2, although it runs fine when I deploy
it to the server. Any idea why?
If I make the > comparison static, like this:
when
$order: OrderFact(numberOfCreditCardDeclines > 5)
then
//do something
It also works fine. What's wrong?
--
View this message in context: http://drools.46999.n3.nabble.com/Rule-not-compiling-in-IDE-after-migrati...
Sent from the Drools: User forum mailing list archive at Nabble.com.
14 years, 7 months
Rules migration from ILog
by Tomas Andersen
Hi.
We are thinking about using Drools instead of Ilog for a current project.
I have some ilr files containing rules/decision points. Is it possible to convert/migrate these to drl files to be used in Drools?
If not does anyone know if there is a way to import ilog rules into drools. We have excel scenario files and/or ilr files as a base.
Regards,
Tomas
14 years, 7 months
FW: FW: Capitalized element names
by Tom.E.Murphy＠wellsfargo.com
Thanks, Wolfgang.
Is it possible the error is in the internal treatment of caps in the code that converts
MICompanyMarketClassification in ("2", "3")
to
MICompanyMarketClassification == "2" || MICompanyMarketClassification == "3"
Why I think this:
The only place the capitalization seems harmful is when it occurs with an in (...) clause.
If I use forced lower- casing of the first letter of a capitalized property in other types of expressions, 5.2 fails.
If I use forced lower-casing of the first letter of a capitalized property in an in(...) expression, 5.2 succeeds.
If I use natural casing of a capitalized property in other types of expressions, 5.2 succeeds.
If I use natural casing of a capitalized property in property in an in(...) expression, 5.2 fails.
Tom Murphy
Systems Architect
Wells Fargo HCFG - CORE Deal Decisioning Platform
800 S. Jordan Creek Parkway | West Des Moines, IA 50266
MAC: X2301-01B
Office: 515 324 4853 | Mobile: 515 423 4334
tom.e.murphy(a)wellsfargo.com<mailto:tom.e.murphy@wellsfargo.com>
This transmission may contain information that is confidential and/or proprietary. If you are not the individual or entity to which it is addressed, note that any review, disclosure, copying, retransmission, or other use is strictly prohibited. If you received this transmission in error, please notify the sender immediately and delete the material from your system.
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Wolfgang Laun
Sent: Wednesday, July 27, 2011 12:46 AM
To: Rules Users List
Subject: Re: [rules-users] FW: Capitalized element names
Edson,
please also not JBRULES-3147: Regression: all uppercase field reference results in compile error. Some forms used to work in 5.1.1 that don't in 5.2.
I've added the gist of this thread to JIRA-3147.
-W
2011/7/27 Edson Tirelli <ed.tirelli(a)gmail.com<mailto:ed.tirelli@gmail.com>>
>
> If one works and the other doesn't, then we have a problem. It must work if you make the first letter lowercase, as that is part of the javabeans spec.
> Feel free to open a JIRA and we will take a look at it.
> Edson
>
> 2011/7/26 <Tom.E.Murphy(a)wellsfargo.com<mailto:Tom.E.Murphy@wellsfargo.com>>
>>
>> Thanks Edson, however here is more info on the issue as I've been playing with it:
>>
>> 1. I have other elements in other objects referenced within the same rule group that start with capital letters and they have no problem. Example:
>>
>> , FHAMaxBaseMortgageWithToleranceAmt < ($totalLoanAmt+$aggregateSubordinateFinancingAmt)
>>
>> Compiles just fine in the same session.
>>
>> 2. If I lower the first M to m to make it mICompanyMarketClassification, it compiles in 5.2 but does NOT compile in 5.0.1
>>
>> 3. If I leave it as the capitalized MICompanyMarketClassification, it compiles in 5.0.1 but not 5.2
>>
>> Thoughts?
>>
>> Tom Murphy
>>
>> Systems Architect
>> Wells Fargo HCFG - CORE Deal Decisioning Platform
>>
>>
>>
>> 800 S. Jordan Creek Parkway | West Des Moines, IA 50266
>> MAC: X2301-01B
>> Office: 515 324 4853 | Mobile: 515 423 4334
>>
>> tom.e.murphy(a)wellsfargo.com<mailto:tom.e.murphy@wellsfargo.com>
>>
>> This transmission may contain information that is confidential and/or proprietary. If you are not the individual or entity to which it is addressed, note that any review, disclosure, copying, retransmission, or other use is strictly prohibited. If you received this transmission in error, please notify the sender immediately and delete the material from your system.
>>
>>
>>
>>
>>
>> From: rules-users-bounces(a)lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org> [mailto:rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org>] On Behalf Of Edson Tirelli
>> Sent: Tuesday, July 26, 2011 7:45 PM
>> To: Rules Users List
>> Subject: Re: [rules-users] Capitalized element names
>>
>>
>>
>>
>>
>> Hi Tom,
>>
>>
>>
>> I've seen this before and AFAIK, the javaBeans spec always transforms the first letter to lowercase when converting a get method into a property name. We can try to address this in future releases, maybe falling back to uppercase if the lower case property name lookup fails, but I don't think there is a solution to keep it as is. In 5.2. you can use the full method name instead, but not sure if that isn't event worse:
>>
>>
>>
>> MortageInsurance{ getMICompanyMarketClassification() in ("2", "3") }
>>
>>
>>
>> Edson
>>
>>
>>
>> 2011/7/26 <Tom.E.Murphy(a)wellsfargo.com<mailto:Tom.E.Murphy@wellsfargo.com>>
>>
>> In the following rule, the element MICompanyMarketClassification is capitalized due to the MI portion being an acronym for Mortgage Insurance.
>>
>> This comes from our enterprise data model and is not something I can change.
>>
>>
>>
>> rule "R1234"
>>
>> dialect "java"
>>
>> when
>>
>> MortageInsurance{ MICompanyMarketClassification in ("2", "3") }
>>
>> then
>>
>> system.out.printLn("something");
>>
>> end
>>
>>
>>
>> The rule refuses to compile, giving a message "Unable to Analyse Expression MICompanyMarketClassification == "2" || MICompanyMarketClassification == "3":
>>
>> [Error: no such identifier: MICompanyMarketClassification]
>>
>> [Near : {... MICompanyMarketClassification ....}]"
>>
>>
>>
>> I assume this is caused by the capitalized first letter?
>>
>> Anything I can do to fix the issue or work around it?
>>
>>
>>
>> Drools 5.2 community edition
>>
>> Tom Murphy
>>
>> Systems Architect
>> Wells Fargo HCFG - CORE Deal Decisioning Platform
>>
>>
>>
>> 800 S. Jordan Creek Parkway | West Des Moines, IA 50266
>> MAC: X2301-01B
>> Office: 515 324 4853 | Mobile: 515 423 4334
>>
>> tom.e.murphy(a)wellsfargo.com<mailto:tom.e.murphy@wellsfargo.com>
>>
>> This transmission may contain information that is confidential and/or proprietary. If you are not the individual or entity to which it is addressed, note that any review, disclosure, copying, retransmission, or other use is strictly prohibited. If you received this transmission in error, please notify the sender immediately and delete the material from your system.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org<mailto:rules-users@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>> --
>> Edson Tirelli
>> JBoss Drools Core Development
>> JBoss by Red Hat @ www.jboss.com<http://www.jboss.com>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org<mailto:rules-users@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
>
>
> --
> Edson Tirelli
> JBoss Drools Core Development
> JBoss by Red Hat @ www.jboss.com<http://www.jboss.com>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org<mailto:rules-users@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
14 years, 7 months
Declare new fact type - where do i put it?
by Eugenia Carcel
I want to declare a new fact type, but I don't know where to put it.
In a java file? It's not java syntax... In a drl file?
I've already went through the docs but this piece of info is missing...
Thanks again,
14 years, 7 months
Unable to build constraint as '_default' is invalid
by Eugenia Carcel
Hi,
I get the following error when I try to build and deploy:
Unable to build constraint as '_default' is invalid : [Rule
name='myRuleName']
It yields this error because of this pattern in my drl file:
MyType(_default == DefaultType.YES)
In my java class MyType I have something like this:
public class MyType {
....
@XmlAttribute(name = "default")
protected DefaultType _default;
....
}
where DefaultType is an enum.
Here is the hole enum class:
@XmlType(name = "defaultType")
@XmlEnum
public enum DefaultType {
@XmlEnumValue("yes")
YES("yes");
private final String value;
DefaultType(String v) {
value = v;
}
public String value() {
return value;
}
public static DefaultType fromValue(String v) {
for (DefaultType c: DefaultType.values()) {
if (c.value.equals(v)) {
return c;
}
}
throw new IllegalArgumentException(v);
}
}
Can you help me? I don't see where the problem is...
Any suggestions are much appreciated.
14 years, 7 months
Can someone help me ?
by 祝英杰
When I use the drools,
I want to store the rules in the SQL Server Database,
Can someone help me and give me some advices, how do I do it?
Thanks!
14 years, 7 months
Rules influencing each other ?
by Andre
during my tests i see, that when data is evaluated from other rules than the
third one, the third will not fire, even if the right combination of events
occur
and when the same events occur without any other events, then the third one
works , any idea ??
rule "Request counting Subject By Id"
when
$set: Set()
from accumulate($neu : RequestCtx() over
window:time(1m),countMatchingSubjectIdsInRequest($neu) )
java.util.Map.Entry( $id: key, $count: value > 1 ) from $set
eval(DroolsUtils.isUpToDate($count))
then
channels["AuthZBlocking"].send(new ItemCacheEntry(new Item((String)$id),
new Date(System.currentTimeMillis()+ 30000),new StringMatcher()));
end
// Implementing Use Case 2
rule "Request counting Resources By Id"
when
$set: Set()
from accumulate($neu : RequestCtx() over
window:time(1m),countMatchingResourcesInRequest($neu) )
java.util.Map.Entry( $id: key, $count: value > 1 ) from $set
eval(DroolsUtils.isUpToDate($count))
then
channels["AuthZBlocking"].send(new ItemCacheEntry(new Item((String)$id),
new Date(System.currentTimeMillis()+ 30000),new StringMatcher()));
end
// Implementing Use Case 3
rule "Request counting analysed Resources By Id"
when
$list: ArrayList()
from accumulate($neu : RequestCtx() over
window:time(1m),countMatchingAnalysedResourcesInRequest($neu) )
ResourceMatch( $id: uri, count > 1 ) from $list
then
channels["AuthZBlocking"].send(new ItemCacheEntry(new URIItem($id), new
Date(System.currentTimeMillis()+ 30000), new URIMatcher()));
end
--
View this message in context: http://drools.46999.n3.nabble.com/Rules-influencing-each-other-tp3200654p...
Sent from the Drools: User forum mailing list archive at Nabble.com.
14 years, 7 months
