Re: [rules-users] OutOfMemoryError happens when dynamic loading of Rules from Guvnor frequently
Try using JMAP to get a heap dump, and then find an analysis tool you like to find the memory leak. It is probably due to a memory leak in MVEL that show itself when you do dynamic rules allocation (I don't think it has been fixed yet), but I can't be sure unless you find the class that is leaking. Jason Smith From: rules-users-boun...@lists.jboss.org [rules-users-boun...@lists.jboss.org] On Behalf Of Oliver Liu [liuyy2...@hotmail.com] Sent: Monday, June 20, 2011 5:44 PM To: rules-users@lists.jboss.org Subject: Re: [rules-users] OutOfMemoryError happens when dynamic loading of Rules from Guvnor frequently Any idea is appreciated, it's critical for my project. Thanks. -- View this message in context: http://drools.46999.n3.nabble.com/OutOfMemoryError-happens-when-dynamic-loading-of-Rules-from-Guvnor-frequently-tp3079965p3088701.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Missing space when using DSL and Guvnor
I would like to recall the previous message... please ignore. Big oops!
Jason Smith
From: rules-users-boun...@lists.jboss.org [rules-users-boun...@lists.jboss.org]
On Behalf Of Paul R. [reverselo...@gmail.com]
Sent: Friday, April 30, 2010 5:40 PM
To: Rules Users List
Subject: Re: [rules-users] Missing space when using DSL and Guvnor
Hi Jeff,
I logged a bug for this one a while back, here's the JIRA, patch details
included.
https://jira.jboss.org/jira/browse/GUVNOR-520
I would appreciate it if somebody could commit this for me :)
Cheers,
Paul
2010/4/30 Esteban Aliverti
mailto:esteban.alive...@gmail.com>>
It sounds like a bug. Can you double check it and create a jira issue please?
best,
2010/4/29 Doyel,Jeff mailto:jdo...@cerner.com>>
I am setting up a very simple example using a DSL and Guvnor. My DSL is as
follows:
[when]Age is less than {age} years old=AgeFact(ageInYears < {age})
When I attempt to create a new Business Rule using the Guvnor I can select the
above expression just fine and the sentence displays as expected. I then fill
in the years with a numeric value (4) and validate. Upon validation I receive
the following error.
[Age Test Rule] [ERR 101] Line 4:2 no viable alternative at input 'Age' in rule
"Age Test Rule"
I then view the source and it looks like this.
rule "Age Test Rule"
dialect "mvel"
when
Age is less than 4years old
then
end
I noticed that there is no space between the ‘4’ and the word ‘years’.
However, in my DSL sentence there is a space between {age} and years. Another
interesting thing, if I enter the number 4 followed by a space in the Guvnor
form then the rule validates correctly. Is this a bug or is it something I am
doing wrong in my DSL?
Thanks,
Jeff
CONFIDENTIALITY NOTICE This message and any included attachments are from
Cerner Corporation and are intended only for the addressee. The information
contained in this message is confidential and may constitute inside or
non-public information under international, federal, or state securities laws.
Unauthorized forwarding, printing, copying, distribution, or use of such
information is strictly prohibited and may be unlawful. If you are not the
addressee, please promptly delete this message and notify the sender of the
delivery error by e-mail or you may call Cerner's corporate offices in Kansas
City, Missouri, U.S.A at (+1) (816)221-1024.
___
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
--
Esteban Aliverti
___
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Missing space when using DSL and Guvnor
Hey, didn't mean to come off as critical today. You are doing a good job on
this, and the basic rules stuff is spot on as far as functionality goes. Words
like *refactor* and *scrub* are just artifacts of code that has gone through
several revision cycles (and I helped). Functionally, it's working great, as
intended, with no compromises in the design - or at least tiny ones. If the
code is a little hard to modify (due to a couple of years of active
maintenance), that's not a big deal.
It really may be a very small deal. It looks to me like this code is about to
enter a fairly stable time. It's pretty close to feature-complete, and it's
working. So then it's your call if and when you want to spend the time and
effort to pretty it up a bit. In a code base as big as this one, with as many
things as need to be done, there's plenty of other low hanging fruit... :-)
Have a good weekend, and try not to work on this stuff.
Jason Smith
Software Engineer
InfoTrust Group, Inc.
500 Discovery Parkway, Suite 200
Superior, CO 80027
Office 303-627-6571
Fax 303-666-6711
Email jsm...@infotrustgroup.com<mailto:jsm...@infotrustgroup.com>
WEB www.infotrustgroup.com<http://www.infotrustgroup.com/>
This e-mail and all information included herein do not constitute a legal
agreement accorded by INFOTRUST GROUP and its affiliates and subsidiaries. All
legal agreements must be formulated in writing by a legal representative of
INFOTRUST GROUP. This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to whom they are
addressed. If you have received this e-mail by mistake, please inform us and
destroy this e-mail and any documents it might contain. Please note that any
views or opinions presented in this email are solely those of the author and do
not necessarily represent those of the company. Finally, the recipient should
check this email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by this
email. Thank you for your cooperation.
From: rules-users-boun...@lists.jboss.org [rules-users-boun...@lists.jboss.org]
On Behalf Of Paul R. [reverselo...@gmail.com]
Sent: Friday, April 30, 2010 5:40 PM
To: Rules Users List
Subject: Re: [rules-users] Missing space when using DSL and Guvnor
Hi Jeff,
I logged a bug for this one a while back, here's the JIRA, patch details
included.
https://jira.jboss.org/jira/browse/GUVNOR-520
I would appreciate it if somebody could commit this for me :)
Cheers,
Paul
2010/4/30 Esteban Aliverti
mailto:esteban.alive...@gmail.com>>
It sounds like a bug. Can you double check it and create a jira issue please?
best,
2010/4/29 Doyel,Jeff mailto:jdo...@cerner.com>>
I am setting up a very simple example using a DSL and Guvnor. My DSL is as
follows:
[when]Age is less than {age} years old=AgeFact(ageInYears < {age})
When I attempt to create a new Business Rule using the Guvnor I can select the
above expression just fine and the sentence displays as expected. I then fill
in the years with a numeric value (4) and validate. Upon validation I receive
the following error.
[Age Test Rule] [ERR 101] Line 4:2 no viable alternative at input 'Age' in rule
"Age Test Rule"
I then view the source and it looks like this.
rule "Age Test Rule"
dialect "mvel"
when
Age is less than 4years old
then
end
I noticed that there is no space between the ‘4’ and the word ‘years’.
However, in my DSL sentence there is a space between {age} and years. Another
interesting thing, if I enter the number 4 followed by a space in the Guvnor
form then the rule validates correctly. Is this a bug or is it something I am
doing wrong in my DSL?
Thanks,
Jeff
CONFIDENTIALITY NOTICE This message and any included attachments are from
Cerner Corporation and are intended only for the addressee. The information
contained in this message is confidential and may constitute inside or
non-public information under international, federal, or state securities laws.
Unauthorized forwarding, printing, copying, distribution, or use of such
information is strictly prohibited and may be unlawful. If you are not the
addressee, please promptly delete this message and notify the sender of the
delivery error by e-mail or you may call Cerner's corporate offices in Kansas
City, Missouri, U.S.A at (+1) (816)221-1024.
___
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
--
Esteban Aliverti
___
rules-users mailing lis
Re: [rules-users] AGE problem
Hey, I haven't been following this thread, but you can use Joda Time to get
much better, easier results. For instance, you can add 1 month to a DateTime
by using a new Period("P1M") [that is, a period of 1 month] - all done
according to ISO8601 standards, so it works flawlessly, including adjustments
for things like daylight savings time (so you don't have to think about it
much).
In business, we live and die by precise time calculations. Think of it as
being like a check writing program that "estimates" a salary, and then pays the
employee that amount. Get your torches and pitchforks!
Jason Smith
From: rules-users-boun...@lists.jboss.org [rules-users-boun...@lists.jboss.org]
On Behalf Of Pavel Tavoda [pavel.tav...@gmail.com]
Sent: Tuesday, February 23, 2010 1:30 AM
To: Rules Users List
Subject: Re: [rules-users] AGE problem
Try to do this in bank application. People come 1 hour after they date
expired and try to charge them for sooner withdrawal because you
calculate with 365.25 not 365 days. You will be kicked, believe me.
Pavel
2010/2/23 Wolfgang Laun :
> On Tue, Feb 23, 2010 at 8:07 AM, djb wrote:
>>
>> I think though that the majority of uses for a rules engine is in a
>> business
>> context, where they don't use astronomical time.
>>
>> If the doctor's orders are:
>> "You cannot get out of bed for 2 months"
>>
>> This means 59 days if he told you February 1st, and it means 62 days if he
>> told you July 1st.
>>
>
> This is a particularly bad example, because doctors can't say that - at
> least not one I'd trust ;-)
>
> I'm arguing that you cannot expect a computer program to relieve you from
> the burden of defining what you mean by a "duration of one year" (or month).
> Some legal rules require a person to have a certain age, and it is (for
> humans)
> more convenient to decide this on a person's birthday YMD plus an increment
> in the Y number. If your application requires you to use an increment in
> the year
> component of the YMDhms representation of a point in time, then you are
> indeed stuck with Calendar and the resulting overhead. (Memoizing
> the results of YMDhms +/- n years might speed things up, for the usual
> price.)
>
> But many applications would be satisfied with using a fixed duration for
> a year in terms of 365 or 365.25 or some such value. If, for instance, you
> have a library, and you must decide to move a book into deep storage
> "if it has not been requested for more than a year" you might calculate
> this (faster) by adding 356*24*60*60 to the clock value of the last return.
>
> -W
>
>> So at least for me, I am going to have to work out a plan that involves
>> GregorianCalendar.
>>
>> --
>> View this message in context:
>> http://n3.nabble.com/AGE-problem-tp215215p354847.html
>> Sent from the Drools - User mailing list archive at Nabble.com.
>> ___
>> rules-users mailing list
>> rules-users@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Updates with property change on facts. How???
I think I've solved this. You have to fire the property change event *AFTER*
you change the underlying property. As long as session.update() is called
*AFTER* the value has changed, things seem to work correctly.
Does this sound like a reasonable solution? I think I saw in the documentation
(what little I could find on this particular subject) that the property event
was triggered before the actual value changed.
Jason Smith
From: rules-users-boun...@lists.jboss.org [rules-users-boun...@lists.jboss.org]
On Behalf Of Jason Smith [jsm...@infotrustgroup.com]
Sent: Friday, November 27, 2009 10:13 AM
To: Rules Users List
Subject: Re: [rules-users] Updates with property change on facts. How???
The Update command appears to be processed in
org.drools.process.commands.UpdateCommand. It's doing the update the same way
I am.
Why does this code work when Drools uses it, and it doesn't work for me?
package org.drools.process.command;
import org.drools.reteoo.ReteooWorkingMemory;
import org.drools.runtime.rule.FactHandle;
public class UpdateCommand
implements
Command {
private FactHandle handle;
private Object object;
public UpdateCommand(FactHandle handle,
Object object) {
this.handle = handle;
this.object = object;
}
public Object execute(ReteooWorkingMemory session) {
session.update( handle,
object );
return null;
}
public String toString() {
return "session.update( " + handle + ", " + object + " );";
}
}
Jason Smith
From: rules-users-boun...@lists.jboss.org [rules-users-boun...@lists.jboss.org]
On Behalf Of Jason Smith [jsm...@infotrustgroup.com]
Sent: Friday, November 27, 2009 10:04 AM
To: Rules Users List
Subject: Re: [rules-users] Updates with property change on facts. How???
Here is a twist.
If I call "update($fact)" explicitly in the rule, the rule is NOT called twice.
Can someone point me to the code used by "update($fact)"? Maybe I can figure
out what I did wrong to cause the rule to fire incorrectly a second time.
Jason Smith
From: rules-users-boun...@lists.jboss.org [rules-users-boun...@lists.jboss.org]
On Behalf Of Jason Smith [jsm...@infotrustgroup.com]
Sent: Friday, November 27, 2009 9:54 AM
To: Rules Users List
Subject: [rules-users] Updates with property change on facts. How???
I implemented the following listener for my bean and I am calling .update()
directly on the StatefulKnowledgeSession.
QUESTION 1: Is there a better way? The old API supported
.insert(fact,boolean). The new one does not. I am not finding any
documentation that explains the new API (version 5.0.1).
QUESTION 2: Why is this calling my rule twice? The rule is getting called
twice, and the second time it's called, the entry conditions are invalid! That
is, I changed the bean in a way that invalidates the WHEN condition. The rule
still gets called twice.
How do I even begin to go about troubleshooting this? This same behavior was
happening with Drools 4 and the old API as well.
private class InnerPropertyChangeListener implements PropertyChangeListener
{
private final InternalFactHandle factHandle;
private final Object fact;
private final StatefulKnowledgeSession session;
public InnerPropertyChangeListener(InternalFactHandle factHandle, Object
fact, StatefulKnowledgeSession session)
{
this.factHandle = factHandle;
this.fact = fact;
this.session = session;
}
@Override
public void propertyChange(PropertyChangeEvent evt)
{
System.out.println("** UPDATING " + evt.getPropertyName() + ": " +
"\nNEW:" +
StringUtil.indent(BeanUtil.printObject(evt.getNewValue()),16) +
"\nOLD:" +
StringUtil.indent(BeanUtil.printObject(evt.getOldValue()),16));
if((evt.getNewValue() == null && evt.getOldValue() != null) ||
!evt.getNewValue().equals(evt.getOldValue()))
{
session.update(factHandle, fact);
}
}
}
Jason Smith
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Updates with property change on facts. How???
The Update command appears to be processed in
org.drools.process.commands.UpdateCommand. It's doing the update the same way
I am.
Why does this code work when Drools uses it, and it doesn't work for me?
package org.drools.process.command;
import org.drools.reteoo.ReteooWorkingMemory;
import org.drools.runtime.rule.FactHandle;
public class UpdateCommand
implements
Command {
private FactHandle handle;
private Object object;
public UpdateCommand(FactHandle handle,
Object object) {
this.handle = handle;
this.object = object;
}
public Object execute(ReteooWorkingMemory session) {
session.update( handle,
object );
return null;
}
public String toString() {
return "session.update( " + handle + ", " + object + " );";
}
}
Jason Smith
From: rules-users-boun...@lists.jboss.org [rules-users-boun...@lists.jboss.org]
On Behalf Of Jason Smith [jsm...@infotrustgroup.com]
Sent: Friday, November 27, 2009 10:04 AM
To: Rules Users List
Subject: Re: [rules-users] Updates with property change on facts. How???
Here is a twist.
If I call "update($fact)" explicitly in the rule, the rule is NOT called twice.
Can someone point me to the code used by "update($fact)"? Maybe I can figure
out what I did wrong to cause the rule to fire incorrectly a second time.
Jason Smith
From: rules-users-boun...@lists.jboss.org [rules-users-boun...@lists.jboss.org]
On Behalf Of Jason Smith [jsm...@infotrustgroup.com]
Sent: Friday, November 27, 2009 9:54 AM
To: Rules Users List
Subject: [rules-users] Updates with property change on facts. How???
I implemented the following listener for my bean and I am calling .update()
directly on the StatefulKnowledgeSession.
QUESTION 1: Is there a better way? The old API supported
.insert(fact,boolean). The new one does not. I am not finding any
documentation that explains the new API (version 5.0.1).
QUESTION 2: Why is this calling my rule twice? The rule is getting called
twice, and the second time it's called, the entry conditions are invalid! That
is, I changed the bean in a way that invalidates the WHEN condition. The rule
still gets called twice.
How do I even begin to go about troubleshooting this? This same behavior was
happening with Drools 4 and the old API as well.
private class InnerPropertyChangeListener implements PropertyChangeListener
{
private final InternalFactHandle factHandle;
private final Object fact;
private final StatefulKnowledgeSession session;
public InnerPropertyChangeListener(InternalFactHandle factHandle, Object
fact, StatefulKnowledgeSession session)
{
this.factHandle = factHandle;
this.fact = fact;
this.session = session;
}
@Override
public void propertyChange(PropertyChangeEvent evt)
{
System.out.println("** UPDATING " + evt.getPropertyName() + ": " +
"\nNEW:" +
StringUtil.indent(BeanUtil.printObject(evt.getNewValue()),16) +
"\nOLD:" +
StringUtil.indent(BeanUtil.printObject(evt.getOldValue()),16));
if((evt.getNewValue() == null && evt.getOldValue() != null) ||
!evt.getNewValue().equals(evt.getOldValue()))
{
session.update(factHandle, fact);
}
}
}
Jason Smith
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Updates with property change on facts. How???
Here is a twist.
If I call "update($fact)" explicitly in the rule, the rule is NOT called twice.
Can someone point me to the code used by "update($fact)"? Maybe I can figure
out what I did wrong to cause the rule to fire incorrectly a second time.
Jason Smith
From: rules-users-boun...@lists.jboss.org [rules-users-boun...@lists.jboss.org]
On Behalf Of Jason Smith [jsm...@infotrustgroup.com]
Sent: Friday, November 27, 2009 9:54 AM
To: Rules Users List
Subject: [rules-users] Updates with property change on facts. How???
I implemented the following listener for my bean and I am calling .update()
directly on the StatefulKnowledgeSession.
QUESTION 1: Is there a better way? The old API supported
.insert(fact,boolean). The new one does not. I am not finding any
documentation that explains the new API (version 5.0.1).
QUESTION 2: Why is this calling my rule twice? The rule is getting called
twice, and the second time it's called, the entry conditions are invalid! That
is, I changed the bean in a way that invalidates the WHEN condition. The rule
still gets called twice.
How do I even begin to go about troubleshooting this? This same behavior was
happening with Drools 4 and the old API as well.
private class InnerPropertyChangeListener implements PropertyChangeListener
{
private final InternalFactHandle factHandle;
private final Object fact;
private final StatefulKnowledgeSession session;
public InnerPropertyChangeListener(InternalFactHandle factHandle, Object
fact, StatefulKnowledgeSession session)
{
this.factHandle = factHandle;
this.fact = fact;
this.session = session;
}
@Override
public void propertyChange(PropertyChangeEvent evt)
{
System.out.println("** UPDATING " + evt.getPropertyName() + ": " +
"\nNEW:" +
StringUtil.indent(BeanUtil.printObject(evt.getNewValue()),16) +
"\nOLD:" +
StringUtil.indent(BeanUtil.printObject(evt.getOldValue()),16));
if((evt.getNewValue() == null && evt.getOldValue() != null) ||
!evt.getNewValue().equals(evt.getOldValue()))
{
session.update(factHandle, fact);
}
}
}
Jason Smith
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Updates with property change on facts. How???
I implemented the following listener for my bean and I am calling .update()
directly on the StatefulKnowledgeSession.
QUESTION 1: Is there a better way? The old API supported
.insert(fact,boolean). The new one does not. I am not finding any
documentation that explains the new API (version 5.0.1).
QUESTION 2: Why is this calling my rule twice? The rule is getting called
twice, and the second time it's called, the entry conditions are invalid! That
is, I changed the bean in a way that invalidates the WHEN condition. The rule
still gets called twice.
How do I even begin to go about troubleshooting this? This same behavior was
happening with Drools 4 and the old API as well.
private class InnerPropertyChangeListener implements PropertyChangeListener
{
private final InternalFactHandle factHandle;
private final Object fact;
private final StatefulKnowledgeSession session;
public InnerPropertyChangeListener(InternalFactHandle factHandle, Object
fact, StatefulKnowledgeSession session)
{
this.factHandle = factHandle;
this.fact = fact;
this.session = session;
}
@Override
public void propertyChange(PropertyChangeEvent evt)
{
System.out.println("** UPDATING " + evt.getPropertyName() + ": " +
"\nNEW:" +
StringUtil.indent(BeanUtil.printObject(evt.getNewValue()),16) +
"\nOLD:" +
StringUtil.indent(BeanUtil.printObject(evt.getOldValue()),16));
if((evt.getNewValue() == null && evt.getOldValue() != null) ||
!evt.getNewValue().equals(evt.getOldValue()))
{
session.update(factHandle, fact);
}
}
}
Jason Smith
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] FW: Rule runs twice without explicit call to update($fact).
I never got an answer, any answer to this question. I really need to know if
PropertyChangeSupport actually works. Is anyone out there successfully using
it?
In one case (using "modify()") I get a NPE. In all cases, the rules run twice
unless I explicitly call "update()". Is anyone *not* seeing this behaviour?
Is anyone successfully using the PropertyChangeSupport mechanism without
explicit calls to "update()"???
Jason Smith
____
From: Jason Smith
Sent: Monday, November 23, 2009 12:36 PM
To: rules-users@lists.jboss.org
Subject: Rule runs twice without explicit call to update($fact).
My colleague has confirmed that this behavior has been around since Drools 4,
and it continues to be a problem for Drools 5.0.1 and 5.1.0.M1, assuming it's a
problem and not working as intended.
$fact.setPath("...") implements the correct PropertyChangeSupport mechanism for
Drools. At least Drools is using it and responding mostly as expected.
This runs once:
rule "Constrain to owner or published to public"
when
$fact : ListFact(
$path : path not matches ".*owner.*",
noopResponse == true
)
$model : Model()
then
modify($fact)
{
setPath($fact.getPath() + "[owner]")
}
update($fact);
end
This runs twice:
rule "Constrain to owner or published to public"
when
$fact : ListFact(
$path : path not matches ".*owner.*",
noopResponse == true
)
$model : Model()
then
modify($fact)
{
setPath($fact.getPath() + "[owner]")
}
end
If I don't use modify(...) and simply change the $fact bean path property, the
same thing occurs. If I explicitly call update($fact), the rule runs once. If
I don't it runs twice.
I get "/path[owner][owner]" when I actually wanted "/path[owner]", because it
ran twice, not once.
Why doe update(...) work differently from the PropertyChangeSupport
mechanism??? Shouldn't I be able to depend on Drools to run this rule only one
time?
I am, admittedly, a bit of a noob at this, but I ran this by my local Drools
resident expert, and he doesn't know the answer either.
Thanks so much!
Jason Smith
Software Engineer
InfoTrust Group, Inc.
500 Discovery Parkway, Suite 200
Superior, CO 80027
Office 303-627-6571
Fax 303-666-6711
Email jsm...@infotrustgroup.com<mailto:jsm...@infotrustgroup.com>
WEB www.infotrustgroup.com<http://www.infotrustgroup.com/>
This e-mail and all information included herein do not constitute a legal
agreement accorded by INFOTRUST GROUP and its affiliates and subsidiaries. All
legal agreements must be formulated in writing by a legal representative of
INFOTRUST GROUP. This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to whom they are
addressed. If you have received this e-mail by mistake, please inform us and
destroy this e-mail and any documents it might contain. Please note that any
views or opinions presented in this email are solely those of the author and do
not necessarily represent those of the company. Finally, the recipient should
check this email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by this
email. Thank you for your cooperation.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Rule runs twice without explicit call to update($fact).
My colleague has confirmed that this behavior has been around since Drools 4,
and it continues to be a problem for Drools 5.0.1 and 5.1.0.M1, assuming it's a
problem and not working as intended.
$fact.setPath("...") implements the correct PropertyChangeSupport mechanism for
Drools. At least Drools is using it and responding mostly as expected.
This runs once:
rule "Constrain to owner or published to public"
when
$fact : ListFact(
$path : path not matches ".*owner.*",
noopResponse == true
)
$model : Model()
then
modify($fact)
{
setPath($fact.getPath() + "[owner]")
}
update($fact);
end
This runs twice:
rule "Constrain to owner or published to public"
when
$fact : ListFact(
$path : path not matches ".*owner.*",
noopResponse == true
)
$model : Model()
then
modify($fact)
{
setPath($fact.getPath() + "[owner]")
}
end
If I don't use modify(...) and simply change the $fact bean path property, the
same thing occurs. If I explicitly call update($fact), the rule runs once. If
I don't it runs twice.
I get "/path[owner][owner]" when I actually wanted "/path[owner]", because it
ran twice, not once.
Why doe update(...) work differently from the PropertyChangeSupport
mechanism??? Shouldn't I be able to depend on Drools to run this rule only one
time?
I am, admittedly, a bit of a noob at this, but I ran this by my local Drools
resident expert, and he doesn't know the answer either.
Thanks so much!
Jason Smith
Software Engineer
InfoTrust Group, Inc.
500 Discovery Parkway, Suite 200
Superior, CO 80027
Office 303-627-6571
Fax 303-666-6711
Email jsm...@infotrustgroup.com<mailto:jsm...@infotrustgroup.com>
WEB www.infotrustgroup.com<http://www.infotrustgroup.com/>
This e-mail and all information included herein do not constitute a legal
agreement accorded by INFOTRUST GROUP and its affiliates and subsidiaries. All
legal agreements must be formulated in writing by a legal representative of
INFOTRUST GROUP. This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to whom they are
addressed. If you have received this e-mail by mistake, please inform us and
destroy this e-mail and any documents it might contain. Please note that any
views or opinions presented in this email are solely those of the author and do
not necessarily represent those of the company. Finally, the recipient should
check this email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by this
email. Thank you for your cooperation.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] (no subject)
SUMMARY:
I am getting a NPE when using modify() with a JavaBean that implements
PropertyChangeSupport.
I have included the original source and a proposed fix. Stack trace is also
included.
This applies to Drools 5.0.1, and has been verified to also be a problem for
5.1.0.M1.
DETAIL:
I have a rule that looks like this:
rule "Constrain to owner or published to public"
when
$fact : ListFact(
path not matches ".*owner.*",
noopResponse == true
)
then
modify($fact)
{
setPath( "[owner/username='' or publishlist/publish='All Users']")
}
end
The $fact is a JavaBean that implements PropertyChangeSupport, and I've
verified that everything is working correctly at the bean level. When I run
this rule, I get this exception:
Caused by: java.lang.NullPointerException:
at org.drools.common.EqualityKey.removeFactHandle(EqualityKey.java:109)
at
org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1435)
at
org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1350)
at
org.drools.common.AbstractWorkingMemory.propertyChange(AbstractWorkingMemory.java:1577)
at
java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
at
java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:276)
at com.infotrustgroup.rules.RestFact.setPath(RestFact.java:264)
at
com.infotrustgroup.facts.ParametersFact.setPath(ParametersFact.java:105)
at
com.infotrustgroup.facts.ParametersFact.setPath(ParametersFact.java:74)
at
com.infotrustgroup.what.Rule_Constrain_to_owner_or_published_to_public_0.consequence(Rule_Constrain_to_owner_or_published_to_public_0.java:12)
at
com.infotrustgroup.what.Rule_Constrain_to_owner_or_published_to_public_0ConsequenceInvoker.evaluate(Rule_Constrain_to_owner_or_published_to_public_0ConsequenceInvoker.java:23)
at
org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:934)
... 38 more
The offending line is marked below. It looks like maybe "this.instances" is
null in the "else" clause.
public void removeFactHandle(final InternalFactHandle handle) {
if ( this.handle == handle ) {
if ( this.instances == null ) {
this.handle = null;
} else {
this.handle = (InternalFactHandle) this.instances.remove( 0 );
if ( this.instances.isEmpty() ) {
this.instances = null;
}
}
} else {
***this.instances.remove( handle );***
if ( this.instances.isEmpty() ) {
this.instances = null;
}
}
}
It looks like someone else ran into this problem before, but only fixed it for
the "if" portion, not the "else" portion. I modified the code as follows, and
this seems to fix the NPE. Basically, I followed the pattern from the "if"
portion.
public void removeFactHandle(final InternalFactHandle handle) {
if ( this.handle == handle ) {
if ( this.instances == null ) {
this.handle = null;
} else {
this.handle = (InternalFactHandle) this.instances.remove( 0 );
if ( this.instances.isEmpty() ) {
this.instances = null;
}
}
} else {
if(this.instances == null)
{
this.handle = null;
}
else
{
this.instances.remove( handle );
if ( this.instances.isEmpty() ) {
this.instances = null;
}
}
}
}
Please read around the formatting. Can someone verify if this is a correct
fix, and if it should be applied to the codebase? It seems to work for me. It
does not break any unit tests in drools-core 5.0.1 either.
Jason Smith
Software Engineer
InfoTrust Group, Inc.
500 Discovery Parkway, Suite 200
Superior, CO 80027
Office 303-627-6571
Fax 303-666-6711
Email jsm...@infotrustgroup.com<mailto:jsm...@infotrustgroup.com>
WEB www.infotrustgroup.com<http://www.infotrustgroup.com/>
This e-mail and all information included herein do not constitute a legal
agreement accorded by INFOTRUST GROUP and its affiliates and subsidiaries. All
legal agreements must be formulated in writing by a legal representative of
INFOTRUST GROUP. This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to whom they are
addressed. If you have received this e-mail by mistake, please inform us and
destroy this e-mail and any documents it might contain. Please note that any
views or opinions presented in this email are solely those of the author and do
not necessarily represent those of the company. Finally, the recipient should
check this email and any attachments for the presenc
