11:02 a.m.
Hello,
With prior versions of JBoss Rules (3.0.5) I have been using JDK generated
dynamic proxies as facts, and they have been working fine. However, after
upgrading to JBoss Rules 4.0.0MR3, I cannot seem to get the dynamic proxies
to work as facts. It seems that even though a rule fires that changes a
field on the proxy, a second rule that should not be activated after the
update still fires.
According to the JDK javadoc documentation, dynamic proxies are created as
final. My assumption is that JBoss Rules is not creating Shadow facts for
these since they are final. After reading the JIRA at
http://jira.jboss.com/jira/browse/JBRULES-960, I now am questioning what the
effect of not using shadow facts is on the engine. The relevant part of
that is:
"The problem is that SpringAOP is generating a proxy whose methods equals()
and hashCode() are "final". As drools must either override these methods in
the shadow proxy or not shadow the fact at all, I'm disabling shadow proxy
generation for this use case.
It is really important to note that if you are asserting SpringAOP proxies
as facts into the working memory, you will not be able to change any field
value whose field is constrained in rules or you may incur in a memory leak
and non-deterministic behavior by the rules engine. Unfortunately there is
nothing we can do about, since when SpringAOP makes the methods equals and
hashcode final, we can't override them anymore and as so, we can't shadow
them."
[ Show » <http://jira.jboss.com/jira/browse/JBRULES-960> ]
Edson Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
[02/Jul/07 03:29 PM] The problem is that SpringAOP is generating a proxy
whose methods equals() and hashCode() are "final". As drools must either
override these methods in the shadow proxy or not shadow the fact at all,
I'm disabling shadow proxy generation for this use case. It is really
important to note that if you are asserting SpringAOP proxies as facts into
the working memory, you will not be able to change any field value whose
field is constrained in rules or you may incur in a memory leak and
non-deterministic behavior by the rules engine. Unfortunately there is
nothing we can do about, since when SpringAOP makes the methods equals and
hashcode final, we can't override them anymore and as so, we can't shadow
them.
Although I'm not using SpringAOP, I believe my facts are not being
shadowed.
Is it true that not using shadow facts may lead to non-deterministic
behavior? Prior to shadow facts, the engine seemed to handle it. Any
chance of reverting back to the old style of truth maintenance in the case
of not using shadow facts.
I apologize if I'm not on the right track here. My only test case for my
problem is the entire application right now, so I cannot offer it for
discussion. Any advice would be greatly appreciated.
Thanks,
-Chris West
11:30 a.m.
Chris,
Unfortunately, that is true. Shadow facts exist to ensure the rules
engine integrity. At this point, there is no alternative to shadow facts,
because the solution we used in 3.x had too many drawbacks and did not
scaled for complex rules.
We are trying to come up with an alternative strategy compatible with
current architecture, but it will not make 4.0 final because we are in
feature freeze for the release. It will eventually come out in a maintenance
or minor release.
Can you present us your use case for asserting JDK proxies as facts?
Thanks,
[]s
Edson
2007/7/17, Chris West <crayzfishr(a)gmail.com>:
Hello,
With prior versions of JBoss Rules (3.0.5) I have been using JDK generated
dynamic proxies as facts, and they have been working fine. However, after
upgrading to JBoss Rules 4.0.0MR3, I cannot seem to get the dynamic
proxies to work as facts. It seems that even though a rule fires that
changes a field on the proxy, a second rule that should not be activated
after the update still fires.
According to the JDK javadoc documentation, dynamic proxies are created as
final. My assumption is that JBoss Rules is not creating Shadow facts for
these since they are final. After reading the JIRA at
http://jira.jboss.com/jira/browse/JBRULES-960, I now am questioning what
the effect of not using shadow facts is on the engine. The relevant part of
that is:
"The problem is that SpringAOP is generating a proxy whose methods
equals() and hashCode() are "final". As drools must either override these
methods in the shadow proxy or not shadow the fact at all, I'm disabling
shadow proxy generation for this use case.
It is really important to note that if you are asserting SpringAOP proxies
as facts into the working memory, you will not be able to change any field
value whose field is constrained in rules or you may incur in a memory leak
and non-deterministic behavior by the rules engine. Unfortunately there is
nothing we can do about, since when SpringAOP makes the methods equals and
hashcode final, we can't override them anymore and as so, we can't shadow
them."
[ Show » <http://jira.jboss.com/jira/browse/JBRULES-960> ]
Edson Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
[02/Jul/07 03:29 PM] The problem is that SpringAOP is generating a proxy
whose methods equals() and hashCode() are "final". As drools must either
override these methods in the shadow proxy or not shadow the fact at all,
I'm disabling shadow proxy generation for this use case. It is really
important to note that if you are asserting SpringAOP proxies as facts into
the working memory, you will not be able to change any field value whose
field is constrained in rules or you may incur in a memory leak and
non-deterministic behavior by the rules engine. Unfortunately there is
nothing we can do about, since when SpringAOP makes the methods equals and
hashcode final, we can't override them anymore and as so, we can't shadow
them.
Although I'm not using SpringAOP, I believe my facts are not being
shadowed.
Is it true that not using shadow facts may lead to non-deterministic
behavior? Prior to shadow facts, the engine seemed to handle it. Any
chance of reverting back to the old style of truth maintenance in the case
of not using shadow facts.
I apologize if I'm not on the right track here. My only test case for my
problem is the entire application right now, so I cannot offer it for
discussion. Any advice would be greatly appreciated.
Thanks,
-Chris West
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
11:49 a.m.
Thank you for your response to this issue.
My use case for using proxies is this:
The facts are not modifiable directly (no setter methods) or synchronously.
Modifications to facts occur by calling another method which modifies the
fact and notifies the rules engine of the modification asynchronously
outside of the call stack (but in the same thread) that triggered the change
to begin with. To give the appearance of a modification until the real
notification comes asynchronously, I wrap these objects with proxies, and
the proxy provides the ability to "override" a property until the real
notification comes in later in a different call stack. The reason for the
modifications occurring in this fashion is driven by the fact that this is a
discrete event simulation, and changes to the system occur only as events
which are queued to execute in priority order. The modifications to facts
are just queued events just like everything else.
-Chris
On 7/17/07, Edson Tirelli <tirelli(a)post.com> wrote:
Chris,
Unfortunately, that is true. Shadow facts exist to ensure the rules
engine integrity. At this point, there is no alternative to shadow facts,
because the solution we used in 3.x had too many drawbacks and did not
scaled for complex rules.
We are trying to come up with an alternative strategy compatible with
current architecture, but it will not make 4.0 final because we are in
feature freeze for the release. It will eventually come out in a maintenance
or minor release.
Can you present us your use case for asserting JDK proxies as facts?
Thanks,
[]s
Edson
2007/7/17, Chris West < crayzfishr(a)gmail.com>:
>
> Hello,
>
> With prior versions of JBoss Rules (3.0.5) I have been using JDK
> generated dynamic proxies as facts, and they have been working fine.
> However, after upgrading to JBoss Rules 4.0.0MR3, I cannot seem to get
> the dynamic proxies to work as facts. It seems that even though a rule
> fires that changes a field on the proxy, a second rule that should not be
> activated after the update still fires.
>
> According to the JDK javadoc documentation, dynamic proxies are created
> as final. My assumption is that JBoss Rules is not creating Shadow facts
> for these since they are final. After reading the JIRA at
> http://jira.jboss.com/jira/browse/JBRULES-960, I now am questioning what
> the effect of not using shadow facts is on the engine. The relevant part of
> that is:
>
> "The problem is that SpringAOP is generating a proxy whose methods
> equals() and hashCode() are "final". As drools must either override these
> methods in the shadow proxy or not shadow the fact at all, I'm disabling
> shadow proxy generation for this use case.
> It is really important to note that if you are asserting SpringAOP
> proxies as facts into the working memory, you will not be able to change any
> field value whose field is constrained in rules or you may incur in a memory
> leak and non-deterministic behavior by the rules engine. Unfortunately there
> is nothing we can do about, since when SpringAOP makes the methods equals
> and hashcode final, we can't override them anymore and as so, we can't
> shadow them."
> [ Show » <http://jira.jboss.com/jira/browse/JBRULES-960> ]
> Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> [02/Jul/07 03:29 PM ] The problem is that SpringAOP is generating a
> proxy whose methods equals() and hashCode() are "final". As drools must
> either override these methods in the shadow proxy or not shadow the fact at
> all, I'm disabling shadow proxy generation for this use case. It is really
> important to note that if you are asserting SpringAOP proxies as facts into
> the working memory, you will not be able to change any field value whose
> field is constrained in rules or you may incur in a memory leak and
> non-deterministic behavior by the rules engine. Unfortunately there is
> nothing we can do about, since when SpringAOP makes the methods equals and
> hashcode final, we can't override them anymore and as so, we can't shadow
> them.
>
> Although I'm not using SpringAOP, I believe my facts are not being
> shadowed.
>
> Is it true that not using shadow facts may lead to non-deterministic
> behavior? Prior to shadow facts, the engine seemed to handle it. Any
> chance of reverting back to the old style of truth maintenance in the case
> of not using shadow facts.
>
> I apologize if I'm not on the right track here. My only test case for
> my problem is the entire application right now, so I cannot offer it for
> discussion. Any advice would be greatly appreciated.
>
> Thanks,
> -Chris West
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
12:12 p.m.
Chris,
I'm not sure I understood your scenario bellow, but it does seem exactly
what shadow facts do: a lazy proxy.
In other words, lets say you have an object X. You assert X into working
memory and the engine creates a shadow proxy for it. Then, you can mess with
it as much as you want from outside the engine, changing its property values
and etc... all that will be "invisible" to the engine, until you call an
update on X. At this point, the engine will start seeing the current
"snapshot" of the object properties...
So, my question, isn't that what you are doing with your own proxy?
[]s
Edson
2007/7/17, Chris West <crayzfishr(a)gmail.com>:
Thank you for your response to this issue.
My use case for using proxies is this:
The facts are not modifiable directly (no setter methods) or
synchronously. Modifications to facts occur by calling another method which
modifies the fact and notifies the rules engine of the modification
asynchronously outside of the call stack (but in the same thread) that
triggered the change to begin with. To give the appearance of a
modification until the real notification comes asynchronously, I wrap these
objects with proxies, and the proxy provides the ability to "override" a
property until the real notification comes in later in a different call
stack. The reason for the modifications occurring in this fashion is driven
by the fact that this is a discrete event simulation, and changes to the
system occur only as events which are queued to execute in priority order.
The modifications to facts are just queued events just like everything else.
-Chris
On 7/17/07, Edson Tirelli <tirelli(a)post.com> wrote:
>
>
> Chris,
>
> Unfortunately, that is true. Shadow facts exist to ensure the rules
> engine integrity. At this point, there is no alternative to shadow facts,
> because the solution we used in 3.x had too many drawbacks and did not
> scaled for complex rules.
>
> We are trying to come up with an alternative strategy compatible with
> current architecture, but it will not make 4.0 final because we are in
> feature freeze for the release. It will eventually come out in a maintenance
> or minor release.
>
> Can you present us your use case for asserting JDK proxies as facts?
>
> Thanks,
>
> []s
> Edson
>
>
>
> 2007/7/17, Chris West < crayzfishr(a)gmail.com>:
> >
> > Hello,
> >
> > With prior versions of JBoss Rules (3.0.5) I have been using JDK
> > generated dynamic proxies as facts, and they have been working fine.
> > However, after upgrading to JBoss Rules 4.0.0MR3, I cannot seem to get
> > the dynamic proxies to work as facts. It seems that even though a rule
> > fires that changes a field on the proxy, a second rule that should not be
> > activated after the update still fires.
> >
> > According to the JDK javadoc documentation, dynamic proxies are
> > created as final. My assumption is that JBoss Rules is not creating Shadow
> > facts for these since they are final. After reading the JIRA at
> > http://jira.jboss.com/jira/browse/JBRULES-960, I now am questioning
> > what the effect of not using shadow facts is on the engine. The relevant
> > part of that is:
> >
> > "The problem is that SpringAOP is generating a proxy whose methods
> > equals() and hashCode() are "final". As drools must either override
these
> > methods in the shadow proxy or not shadow the fact at all, I'm disabling
> > shadow proxy generation for this use case.
> > It is really important to note that if you are asserting SpringAOP
> > proxies as facts into the working memory, you will not be able to change any
> > field value whose field is constrained in rules or you may incur in a memory
> > leak and non-deterministic behavior by the rules engine. Unfortunately there
> > is nothing we can do about, since when SpringAOP makes the methods equals
> > and hashcode final, we can't override them anymore and as so, we can't
> > shadow them."
> > [ Show » <http://jira.jboss.com/jira/browse/JBRULES-960> ]
> > Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> > [02/Jul/07 03:29 PM ] The problem is that SpringAOP is generating a
> > proxy whose methods equals() and hashCode() are "final". As drools
must
> > either override these methods in the shadow proxy or not shadow the fact at
> > all, I'm disabling shadow proxy generation for this use case. It is really
> > important to note that if you are asserting SpringAOP proxies as facts into
> > the working memory, you will not be able to change any field value whose
> > field is constrained in rules or you may incur in a memory leak and
> > non-deterministic behavior by the rules engine. Unfortunately there is
> > nothing we can do about, since when SpringAOP makes the methods equals and
> > hashcode final, we can't override them anymore and as so, we can't
shadow
> > them.
> >
> > Although I'm not using SpringAOP, I believe my facts are not being
> > shadowed.
> >
> > Is it true that not using shadow facts may lead to non-deterministic
> > behavior? Prior to shadow facts, the engine seemed to handle it. Any
> > chance of reverting back to the old style of truth maintenance in the case
> > of not using shadow facts.
> >
> > I apologize if I'm not on the right track here. My only test case for
> > my problem is the entire application right now, so I cannot offer it for
> > discussion. Any advice would be greatly appreciated.
> >
> > Thanks,
> > -Chris West
> >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
>
> --
> Edson Tirelli
> Software Engineer - JBoss Rules Core Developer
> Office: +55 11 3529-6000
> Mobile: +55 11 9287-5646
> JBoss, a division of Red Hat @ www.jboss.com
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
12:25 p.m.
Not quite.
It's really the opposite. There is a change I want the engine to see now,
but my own code has not propagated the real change back around to the rule
engine just yet. If I don't use my own proxy to hold the new value, then
other rules will fire that I don't want. If I use my proxy, I manipulate
the value and keep the other rules from firing. Once the "real" change
comes back around, my own proxy stops "overriding" the value and the rules
engine never even sees the real change to the underlying object.
-Chris West
On 7/17/07, Edson Tirelli <tirelli(a)post.com> wrote:
Chris,
I'm not sure I understood your scenario bellow, but it does seem
exactly what shadow facts do: a lazy proxy.
In other words, lets say you have an object X. You assert X into
working memory and the engine creates a shadow proxy for it. Then, you can
mess with it as much as you want from outside the engine, changing its
property values and etc... all that will be "invisible" to the engine, until
you call an update on X. At this point, the engine will start seeing the
current "snapshot" of the object properties...
So, my question, isn't that what you are doing with your own proxy?
[]s
Edson
2007/7/17, Chris West <crayzfishr(a)gmail.com >:
>
> Thank you for your response to this issue.
>
> My use case for using proxies is this:
>
> The facts are not modifiable directly (no setter methods) or
> synchronously. Modifications to facts occur by calling another method which
> modifies the fact and notifies the rules engine of the modification
> asynchronously outside of the call stack (but in the same thread) that
> triggered the change to begin with. To give the appearance of a
> modification until the real notification comes asynchronously, I wrap these
> objects with proxies, and the proxy provides the ability to "override" a
> property until the real notification comes in later in a different call
> stack. The reason for the modifications occurring in this fashion is driven
> by the fact that this is a discrete event simulation, and changes to the
> system occur only as events which are queued to execute in priority order.
> The modifications to facts are just queued events just like everything else.
>
>
> -Chris
>
> On 7/17/07, Edson Tirelli < tirelli(a)post.com> wrote:
> >
> >
> > Chris,
> >
> > Unfortunately, that is true. Shadow facts exist to ensure the rules
> > engine integrity. At this point, there is no alternative to shadow facts,
> > because the solution we used in 3.x had too many drawbacks and did not
> > scaled for complex rules.
> >
> > We are trying to come up with an alternative strategy compatible
> > with current architecture, but it will not make 4.0 final because we
> > are in feature freeze for the release. It will eventually come out in a
> > maintenance or minor release.
> >
> > Can you present us your use case for asserting JDK proxies as
> > facts?
> >
> > Thanks,
> >
> > []s
> > Edson
> >
> >
> >
> > 2007/7/17, Chris West < crayzfishr(a)gmail.com>:
> > >
> > > Hello,
> > >
> > > With prior versions of JBoss Rules (3.0.5) I have been using JDK
> > > generated dynamic proxies as facts, and they have been working fine.
> > > However, after upgrading to JBoss Rules 4.0.0MR3, I cannot seem to
> > > get the dynamic proxies to work as facts. It seems that even though a
rule
> > > fires that changes a field on the proxy, a second rule that should not be
> > > activated after the update still fires.
> > >
> > > According to the JDK javadoc documentation, dynamic proxies are
> > > created as final. My assumption is that JBoss Rules is not creating
Shadow
> > > facts for these since they are final. After reading the JIRA at
> > > http://jira.jboss.com/jira/browse/JBRULES-960, I now am questioning
> > > what the effect of not using shadow facts is on the engine. The relevant
> > > part of that is:
> > >
> > > "The problem is that SpringAOP is generating a proxy whose methods
> > > equals() and hashCode() are "final". As drools must either
override these
> > > methods in the shadow proxy or not shadow the fact at all, I'm
disabling
> > > shadow proxy generation for this use case.
> > > It is really important to note that if you are asserting SpringAOP
> > > proxies as facts into the working memory, you will not be able to change
any
> > > field value whose field is constrained in rules or you may incur in a
memory
> > > leak and non-deterministic behavior by the rules engine. Unfortunately
there
> > > is nothing we can do about, since when SpringAOP makes the methods equals
> > > and hashcode final, we can't override them anymore and as so, we
can't
> > > shadow them."
> > > [ Show » <http://jira.jboss.com/jira/browse/JBRULES-960> ]
> > > Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> > > [02/Jul/07 03:29 PM ] The problem is that SpringAOP is generating a
> > > proxy whose methods equals() and hashCode() are "final". As
drools must
> > > either override these methods in the shadow proxy or not shadow the fact
at
> > > all, I'm disabling shadow proxy generation for this use case. It is
really
> > > important to note that if you are asserting SpringAOP proxies as facts
into
> > > the working memory, you will not be able to change any field value whose
> > > field is constrained in rules or you may incur in a memory leak and
> > > non-deterministic behavior by the rules engine. Unfortunately there is
> > > nothing we can do about, since when SpringAOP makes the methods equals
and
> > > hashcode final, we can't override them anymore and as so, we can't
shadow
> > > them.
> > >
> > > Although I'm not using SpringAOP, I believe my facts are not being
> > > shadowed.
> > >
> > > Is it true that not using shadow facts may lead to non-deterministic
> > > behavior? Prior to shadow facts, the engine seemed to handle it. Any
> > > chance of reverting back to the old style of truth maintenance in the
case
> > > of not using shadow facts.
> > >
> > > I apologize if I'm not on the right track here. My only test case
> > > for my problem is the entire application right now, so I cannot offer it
for
> > > discussion. Any advice would be greatly appreciated.
> > >
> > > Thanks,
> > > -Chris West
> > >
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> >
> >
> > --
> > Edson Tirelli
> > Software Engineer - JBoss Rules Core Developer
> > Office: +55 11 3529-6000
> > Mobile: +55 11 9287-5646
> > JBoss, a division of Red Hat @ www.jboss.com
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
11:32 a.m.
If you do not have shadow facts you cannot use the update() method, it
will leave the working memory corrupted. Instead you must manage this
yourself, before you change any values on the object you must call
modifyRetract() and after you hvae finished your changes ot hte object
call modifyInsert() - luckily if you are doing this in the consequence
you can use the MVEL modify keyword combined with the block setter and
it does this for you:
modify ( person ) { age += 1, location = "london" }
Mark
Chris West wrote:
Hello,
With prior versions of JBoss Rules (3.0.5) I have been using JDK
generated dynamic proxies as facts, and they have been working fine.
However, after upgrading to JBoss Rules 4.0.0MR3, I cannot seem to get
the dynamic proxies to work as facts. It seems that even though a
rule fires that changes a field on the proxy, a second rule that
should not be activated after the update still fires.
According to the JDK javadoc documentation, dynamic proxies are
created as final. My assumption is that JBoss Rules is not creating
Shadow facts for these since they are final. After reading the JIRA
at http://jira.jboss.com/jira/browse/JBRULES-960, I now am questioning
what the effect of not using shadow facts is on the engine. The
relevant part of that is:
"The problem is that SpringAOP is generating a proxy whose methods
equals() and hashCode() are "final". As drools must either override
these methods in the shadow proxy or not shadow the fact at all, I'm
disabling shadow proxy generation for this use case.
It is really important to note that if you are asserting SpringAOP
proxies as facts into the working memory, you will not be able to
change any field value whose field is constrained in rules or you may
incur in a memory leak and non-deterministic behavior by the rules
engine. Unfortunately there is nothing we can do about, since when
SpringAOP makes the methods equals and hashcode final, we can't
override them anymore and as so, we can't shadow them."
[ Show » <http://jira.jboss.com/jira/browse/JBRULES-960> ]
Edson Tirelli
<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirelli>
[02/Jul/07 03:29 PM] The problem is that SpringAOP is generating a
proxy whose methods equals() and hashCode() are "final". As drools
must either override these methods in the shadow proxy or not shadow
the fact at all, I'm disabling shadow proxy generation for this use
case. It is really important to note that if you are asserting
SpringAOP proxies as facts into the working memory, you will not be
able to change any field value whose field is constrained in rules or
you may incur in a memory leak and non-deterministic behavior by the
rules engine. Unfortunately there is nothing we can do about, since
when SpringAOP makes the methods equals and hashcode final, we can't
override them anymore and as so, we can't shadow them.
Although I'm not using SpringAOP, I believe my facts are not being
shadowed.
Is it true that not using shadow facts may lead to non-deterministic
behavior? Prior to shadow facts, the engine seemed to handle it. Any
chance of reverting back to the old style of truth maintenance in the
case of not using shadow facts.
I apologize if I'm not on the right track here. My only test case for
my problem is the entire application right now, so I cannot offer it
for discussion. Any advice would be greatly appreciated.
Thanks,
-Chris West
------------------------------------------------------------------------
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
noon
Mark,
Using modifyRetract and modifyInsert seems to fix the problem (at least in
my test case I finally created). I'll try this on my real code.
My only concern here is that it puts the burden on the rule author to know
whether things are being shadowed or not. For shadowing that is explicitly
turned off this is ok. But for implicit non-shadowing based on a class
being final, this is not at all obvious to the rule auther.
Is there any way to have this hidden such that I can still call "update" but
have it use "modifyRetract" and "modifyInsert" instead?
Also, I'm curious why I have to call modifyRetract before I start modifing
the object, since the engine does not know about my modifications anyway
until I call update or modifyInsert? By the way, I was unable to use the
block setter approach in the rule consequence due to not having set methods
for modifying my objects.
Thanks,
-Chris West
On 7/17/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
If you do not have shadow facts you cannot use the update() method, it
will leave the working memory corrupted. Instead you must manage this
yourself, before you change any values on the object you must call
modifyRetract() and after you hvae finished your changes ot hte object call
modifyInsert() - luckily if you are doing this in the consequence you can
use the MVEL modify keyword combined with the block setter and it does this
for you:
modify ( person ) { age += 1, location = "london" }
Mark
Chris West wrote:
Hello,
With prior versions of JBoss Rules (3.0.5) I have been using JDK generated
dynamic proxies as facts, and they have been working fine. However, after
upgrading to JBoss Rules 4.0.0MR3, I cannot seem to get the dynamic
proxies to work as facts. It seems that even though a rule fires that
changes a field on the proxy, a second rule that should not be activated
after the update still fires.
According to the JDK javadoc documentation, dynamic proxies are created as
final. My assumption is that JBoss Rules is not creating Shadow facts for
these since they are final. After reading the JIRA at
http://jira.jboss.com/jira/browse/JBRULES-960, I now am questioning what
the effect of not using shadow facts is on the engine. The relevant part of
that is:
"The problem is that SpringAOP is generating a proxy whose methods
equals() and hashCode() are "final". As drools must either override these
methods in the shadow proxy or not shadow the fact at all, I'm disabling
shadow proxy generation for this use case.
It is really important to note that if you are asserting SpringAOP proxies
as facts into the working memory, you will not be able to change any field
value whose field is constrained in rules or you may incur in a memory leak
and non-deterministic behavior by the rules engine. Unfortunately there is
nothing we can do about, since when SpringAOP makes the methods equals and
hashcode final, we can't override them anymore and as so, we can't shadow
them."
[ Show » <http://jira.jboss.com/jira/browse/JBRULES-960> ]
Edson Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
[02/Jul/07 03:29 PM] The problem is that SpringAOP is generating a proxy
whose methods equals() and hashCode() are "final". As drools must either
override these methods in the shadow proxy or not shadow the fact at all,
I'm disabling shadow proxy generation for this use case. It is really
important to note that if you are asserting SpringAOP proxies as facts into
the working memory, you will not be able to change any field value whose
field is constrained in rules or you may incur in a memory leak and
non-deterministic behavior by the rules engine. Unfortunately there is
nothing we can do about, since when SpringAOP makes the methods equals and
hashcode final, we can't override them anymore and as so, we can't shadow
them.
Although I'm not using SpringAOP, I believe my facts are not being
shadowed.
Is it true that not using shadow facts may lead to non-deterministic
behavior? Prior to shadow facts, the engine seemed to handle it. Any
chance of reverting back to the old style of truth maintenance in the case
of not using shadow facts.
I apologize if I'm not on the right track here. My only test case for my
problem is the entire application right now, so I cannot offer it for
discussion. Any advice would be greatly appreciated.
Thanks,
-Chris West
------------------------------
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
2:08 p.m.
you only need to use modifyRetract if the object is inserted. The reason
for this is if you change field values on your facts we will not be able
to remove them from our various internal hashmaps; thus the need to
remove first prior to any changes, then make the changes and then insert
it again. We can't allow users to just call update() as we have no idea
what the old values where, thus we cannot find the objects in our hashmaps.
Mark
Chris West wrote:
Mark,
Using modifyRetract and modifyInsert seems to fix the problem (at
least in my test case I finally created). I'll try this on my real code.
My only concern here is that it puts the burden on the rule author to
know whether things are being shadowed or not. For shadowing that is
explicitly turned off this is ok. But for implicit non-shadowing
based on a class being final, this is not at all obvious to the rule
auther.
Is there any way to have this hidden such that I can still call
"update" but have it use "modifyRetract" and "modifyInsert"
instead?
Also, I'm curious why I have to call modifyRetract before I start
modifing the object, since the engine does not know about my
modifications anyway until I call update or modifyInsert? By the way,
I was unable to use the block setter approach in the rule consequence
due to not having set methods for modifying my objects.
Thanks,
-Chris West
On 7/17/07, *Mark Proctor* <mproctor(a)codehaus.org
<mailto:mproctor@codehaus.org>> wrote:
If you do not have shadow facts you cannot use the update()
method, it will leave the working memory corrupted. Instead you
must manage this yourself, before you change any values on the
object you must call modifyRetract() and after you hvae finished
your changes ot hte object call modifyInsert() - luckily if you
are doing this in the consequence you can use the MVEL modify
keyword combined with the block setter and it does this for you:
modify ( person ) { age += 1, location = "london" }
Mark
Chris West wrote:
> Hello,
>
> With prior versions of JBoss Rules (3.0.5) I have been using JDK
> generated dynamic proxies as facts, and they have been working
> fine. However, after upgrading to JBoss Rules 4.0.0MR3, I cannot
> seem to get the dynamic proxies to work as facts. It seems that
> even though a rule fires that changes a field on the proxy, a
> second rule that should not be activated after the update still
> fires.
>
> According to the JDK javadoc documentation, dynamic proxies are
> created as final. My assumption is that JBoss Rules is not
> creating Shadow facts for these since they are final. After
> reading the JIRA at
> http://jira.jboss.com/jira/browse/JBRULES-960, I now am
> questioning what the effect of not using shadow facts is on the
> engine. The relevant part of that is:
>
> "The problem is that SpringAOP is generating a proxy whose
> methods equals() and hashCode() are "final". As drools must
> either override these methods in the shadow proxy or not shadow
> the fact at all, I'm disabling shadow proxy generation for this
> use case.
> It is really important to note that if you are asserting
> SpringAOP proxies as facts into the working memory, you will not
> be able to change any field value whose field is constrained in
> rules or you may incur in a memory leak and non-deterministic
> behavior by the rules engine. Unfortunately there is nothing we
> can do about, since when SpringAOP makes the methods equals and
> hashcode final, we can't override them anymore and as so, we
> can't shadow them."
> [ Show » <http://jira.jboss.com/jira/browse/JBRULES-960> ]
> Edson Tirelli
> <http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirelli>
> [02/Jul/07 03:29 PM] The problem is that SpringAOP is generating
> a proxy whose methods equals() and hashCode() are "final". As
> drools must either override these methods in the shadow proxy or
> not shadow the fact at all, I'm disabling shadow proxy generation
> for this use case. It is really important to note that if you are
> asserting SpringAOP proxies as facts into the working memory, you
> will not be able to change any field value whose field is
> constrained in rules or you may incur in a memory leak and
> non-deterministic behavior by the rules engine. Unfortunately
> there is nothing we can do about, since when SpringAOP makes the
> methods equals and hashcode final, we can't override them anymore
> and as so, we can't shadow them.
>
> Although I'm not using SpringAOP, I believe my facts are not
> being shadowed.
>
> Is it true that not using shadow facts may lead to
> non-deterministic behavior? Prior to shadow facts, the engine
> seemed to handle it. Any chance of reverting back to the old
> style of truth maintenance in the case of not using shadow facts.
>
> I apologize if I'm not on the right track here. My only test
> case for my problem is the entire application right now, so I
> cannot offer it for discussion. Any advice would be greatly
> appreciated.
>
> Thanks,
> -Chris West
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> <mailto:rules-users@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
------------------------------------------------------------------------
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
3:55 p.m.
Is that still true if the equals() and hashcode() methods are only based on
the identity fields of the object (which cannot change)?
-Chris West
On 7/17/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
you only need to use modifyRetract if the object is inserted. The reason
for this is if you change field values on your facts we will not be able to
remove them from our various internal hashmaps; thus the need to remove
first prior to any changes, then make the changes and then insert it again.
We can't allow users to just call update() as we have no idea what the old
values where, thus we cannot find the objects in our hashmaps.
Mark
Chris West wrote:
Mark,
Using modifyRetract and modifyInsert seems to fix the problem (at least in
my test case I finally created). I'll try this on my real code.
My only concern here is that it puts the burden on the rule author to know
whether things are being shadowed or not. For shadowing that is explicitly
turned off this is ok. But for implicit non-shadowing based on a class
being final, this is not at all obvious to the rule auther.
Is there any way to have this hidden such that I can still call "update"
but have it use "modifyRetract" and "modifyInsert" instead?
Also, I'm curious why I have to call modifyRetract before I start modifing
the object, since the engine does not know about my modifications anyway
until I call update or modifyInsert? By the way, I was unable to use the
block setter approach in the rule consequence due to not having set methods
for modifying my objects.
Thanks,
-Chris West
On 7/17/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
>
> If you do not have shadow facts you cannot use the update() method, it
> will leave the working memory corrupted. Instead you must manage this
> yourself, before you change any values on the object you must call
> modifyRetract() and after you hvae finished your changes ot hte object call
> modifyInsert() - luckily if you are doing this in the consequence you can
> use the MVEL modify keyword combined with the block setter and it does this
> for you:
> modify ( person ) { age += 1, location = "london" }
>
> Mark
> Chris West wrote:
>
> Hello,
>
> With prior versions of JBoss Rules (3.0.5) I have been using JDK
> generated dynamic proxies as facts, and they have been working fine.
> However, after upgrading to JBoss Rules 4.0.0MR3, I cannot seem to get
> the dynamic proxies to work as facts. It seems that even though a rule
> fires that changes a field on the proxy, a second rule that should not be
> activated after the update still fires.
>
> According to the JDK javadoc documentation, dynamic proxies are created
> as final. My assumption is that JBoss Rules is not creating Shadow facts
> for these since they are final. After reading the JIRA at
> http://jira.jboss.com/jira/browse/JBRULES-960, I now am questioning what
> the effect of not using shadow facts is on the engine. The relevant part of
> that is:
>
> "The problem is that SpringAOP is generating a proxy whose methods
> equals() and hashCode() are "final". As drools must either override these
> methods in the shadow proxy or not shadow the fact at all, I'm disabling
> shadow proxy generation for this use case.
> It is really important to note that if you are asserting SpringAOP
> proxies as facts into the working memory, you will not be able to change any
> field value whose field is constrained in rules or you may incur in a memory
> leak and non-deterministic behavior by the rules engine. Unfortunately there
> is nothing we can do about, since when SpringAOP makes the methods equals
> and hashcode final, we can't override them anymore and as so, we can't
> shadow them."
> [ Show » <http://jira.jboss.com/jira/browse/JBRULES-960> ]
> Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> [02/Jul/07 03:29 PM] The problem is that SpringAOP is generating a proxy
> whose methods equals() and hashCode() are "final". As drools must either
> override these methods in the shadow proxy or not shadow the fact at all,
> I'm disabling shadow proxy generation for this use case. It is really
> important to note that if you are asserting SpringAOP proxies as facts into
> the working memory, you will not be able to change any field value whose
> field is constrained in rules or you may incur in a memory leak and
> non-deterministic behavior by the rules engine. Unfortunately there is
> nothing we can do about, since when SpringAOP makes the methods equals and
> hashcode final, we can't override them anymore and as so, we can't shadow
> them.
>
> Although I'm not using SpringAOP, I believe my facts are not being
> shadowed.
>
> Is it true that not using shadow facts may lead to non-deterministic
> behavior? Prior to shadow facts, the engine seemed to handle it. Any
> chance of reverting back to the old style of truth maintenance in the case
> of not using shadow facts.
>
> I apologize if I'm not on the right track here. My only test case for
> my problem is the entire application right now, so I cannot offer it for
> discussion. Any advice would be greatly appreciated.
>
> Thanks,
> -Chris West
>
> ------------------------------
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
------------------------------
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
9:24 p.m.
Chris,
I found and developed an intermediate solution that shall work for your
proxies.
If it is not possible to create a shadow fact for a class that is
asserted (because the class is final or whatever), the engine goes up in the
class hierarchy, looking for a class or interface for which is possible to
create the proxy, but that still matches all ObjectTypes available in the
rule base matched by the original class. The analysis is a bit complex,
specially because new rules with new object types can be dynamically added
to the rule base, but I believe the solution will work for JDK proxies and
the most common proxy frameworks out there, that usually don't proxy
multiple unrelated interfaces at once.
So, I ask you please to get latest snapshot from the repository and try
it out for your use case and report back to the list the results, since
seems there are a few other people using similar things.
Thanks,
Edson
2007/7/17, Chris West <crayzfishr(a)gmail.com>:
Is that still true if the equals() and hashcode() methods are only based
on the identity fields of the object (which cannot change)?
-Chris West
On 7/17/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
>
> you only need to use modifyRetract if the object is inserted. The
> reason for this is if you change field values on your facts we will not be
> able to remove them from our various internal hashmaps; thus the need to
> remove first prior to any changes, then make the changes and then insert it
> again. We can't allow users to just call update() as we have no idea what
> the old values where, thus we cannot find the objects in our hashmaps.
>
> Mark
> Chris West wrote:
>
> Mark,
>
> Using modifyRetract and modifyInsert seems to fix the problem (at least
> in my test case I finally created). I'll try this on my real code.
>
> My only concern here is that it puts the burden on the rule author to
> know whether things are being shadowed or not. For shadowing that is
> explicitly turned off this is ok. But for implicit non-shadowing based on a
> class being final, this is not at all obvious to the rule auther.
>
> Is there any way to have this hidden such that I can still call "update"
> but have it use "modifyRetract" and "modifyInsert" instead?
>
> Also, I'm curious why I have to call modifyRetract before I start
> modifing the object, since the engine does not know about my modifications
> anyway until I call update or modifyInsert? By the way, I was unable to use
> the block setter approach in the rule consequence due to not having set
> methods for modifying my objects.
>
> Thanks,
> -Chris West
>
> On 7/17/07, Mark Proctor <mproctor(a)codehaus.org > wrote:
> >
> > If you do not have shadow facts you cannot use the update() method, it
> > will leave the working memory corrupted. Instead you must manage this
> > yourself, before you change any values on the object you must call
> > modifyRetract() and after you hvae finished your changes ot hte object call
> > modifyInsert() - luckily if you are doing this in the consequence you can
> > use the MVEL modify keyword combined with the block setter and it does this
> > for you:
> > modify ( person ) { age += 1, location = "london" }
> >
> > Mark
> > Chris West wrote:
> >
> > Hello,
> >
> > With prior versions of JBoss Rules (3.0.5) I have been using JDK
> > generated dynamic proxies as facts, and they have been working fine.
> > However, after upgrading to JBoss Rules 4.0.0MR3, I cannot seem to get
> > the dynamic proxies to work as facts. It seems that even though a rule
> > fires that changes a field on the proxy, a second rule that should not be
> > activated after the update still fires.
> >
> > According to the JDK javadoc documentation, dynamic proxies are
> > created as final. My assumption is that JBoss Rules is not creating Shadow
> > facts for these since they are final. After reading the JIRA at
> > http://jira.jboss.com/jira/browse/JBRULES-960, I now am questioning
> > what the effect of not using shadow facts is on the engine. The relevant
> > part of that is:
> >
> > "The problem is that SpringAOP is generating a proxy whose methods
> > equals() and hashCode() are "final". As drools must either override
these
> > methods in the shadow proxy or not shadow the fact at all, I'm disabling
> > shadow proxy generation for this use case.
> > It is really important to note that if you are asserting SpringAOP
> > proxies as facts into the working memory, you will not be able to change any
> > field value whose field is constrained in rules or you may incur in a memory
> > leak and non-deterministic behavior by the rules engine. Unfortunately there
> > is nothing we can do about, since when SpringAOP makes the methods equals
> > and hashcode final, we can't override them anymore and as so, we can't
> > shadow them."
> > [ Show » <http://jira.jboss.com/jira/browse/JBRULES-960> ]
> > Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> > [02/Jul/07 03:29 PM] The problem is that SpringAOP is generating a
> > proxy whose methods equals() and hashCode() are "final". As drools
must
> > either override these methods in the shadow proxy or not shadow the fact at
> > all, I'm disabling shadow proxy generation for this use case. It is really
> > important to note that if you are asserting SpringAOP proxies as facts into
> > the working memory, you will not be able to change any field value whose
> > field is constrained in rules or you may incur in a memory leak and
> > non-deterministic behavior by the rules engine. Unfortunately there is
> > nothing we can do about, since when SpringAOP makes the methods equals and
> > hashcode final, we can't override them anymore and as so, we can't
shadow
> > them.
> >
> > Although I'm not using SpringAOP, I believe my facts are not being
> > shadowed.
> >
> > Is it true that not using shadow facts may lead to non-deterministic
> > behavior? Prior to shadow facts, the engine seemed to handle it. Any
> > chance of reverting back to the old style of truth maintenance in the case
> > of not using shadow facts.
> >
> > I apologize if I'm not on the right track here. My only test case for
> > my problem is the entire application right now, so I cannot offer it for
> > discussion. Any advice would be greatly appreciated.
> >
> > Thanks,
> > -Chris West
> >
> > ------------------------------
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> >
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
> ------------------------------
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
9:27 a.m.
Edson,
I downloaded and built the latest from the trunk of the repository. I
applied this new build toward my test case, and it seemed to fix the
problem. However, when I applied it to my real project, it still exhibits
the problem. If I discover more information about the problem I'll let you
know.
Thanks,
Chris West
On 7/17/07, Edson Tirelli <tirelli(a)post.com> wrote:
Chris,
I found and developed an intermediate solution that shall work for your
proxies.
If it is not possible to create a shadow fact for a class that is
asserted (because the class is final or whatever), the engine goes up in the
class hierarchy, looking for a class or interface for which is possible to
create the proxy, but that still matches all ObjectTypes available in the
rule base matched by the original class. The analysis is a bit complex,
specially because new rules with new object types can be dynamically added
to the rule base, but I believe the solution will work for JDK proxies and
the most common proxy frameworks out there, that usually don't proxy
multiple unrelated interfaces at once.
So, I ask you please to get latest snapshot from the repository and try
it out for your use case and report back to the list the results, since
seems there are a few other people using similar things.
Thanks,
Edson
2007/7/17, Chris West <crayzfishr(a)gmail.com>:
>
> Is that still true if the equals() and hashcode() methods are only based
> on the identity fields of the object (which cannot change)?
>
> -Chris West
>
> On 7/17/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
> >
> > you only need to use modifyRetract if the object is inserted. The
> > reason for this is if you change field values on your facts we will not be
> > able to remove them from our various internal hashmaps; thus the need to
> > remove first prior to any changes, then make the changes and then insert it
> > again. We can't allow users to just call update() as we have no idea what
> > the old values where, thus we cannot find the objects in our hashmaps.
> >
> > Mark
> > Chris West wrote:
> >
> > Mark,
> >
> > Using modifyRetract and modifyInsert seems to fix the problem (at
> > least in my test case I finally created). I'll try this on my real code.
> >
> > My only concern here is that it puts the burden on the rule author to
> > know whether things are being shadowed or not. For shadowing that is
> > explicitly turned off this is ok. But for implicit non-shadowing based on a
> > class being final, this is not at all obvious to the rule auther.
> >
> > Is there any way to have this hidden such that I can still call
> > "update" but have it use "modifyRetract" and
"modifyInsert" instead?
> >
> > Also, I'm curious why I have to call modifyRetract before I start
> > modifing the object, since the engine does not know about my modifications
> > anyway until I call update or modifyInsert? By the way, I was unable to use
> > the block setter approach in the rule consequence due to not having set
> > methods for modifying my objects.
> >
> > Thanks,
> > -Chris West
> >
> > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org > wrote:
> > >
> > > If you do not have shadow facts you cannot use the update() method,
> > > it will leave the working memory corrupted. Instead you must manage this
> > > yourself, before you change any values on the object you must call
> > > modifyRetract() and after you hvae finished your changes ot hte object
call
> > > modifyInsert() - luckily if you are doing this in the consequence you can
> > > use the MVEL modify keyword combined with the block setter and it does
this
> > > for you:
> > > modify ( person ) { age += 1, location = "london" }
> > >
> > > Mark
> > > Chris West wrote:
> > >
> > > Hello,
> > >
> > > With prior versions of JBoss Rules (3.0.5) I have been using JDK
> > > generated dynamic proxies as facts, and they have been working fine.
> > > However, after upgrading to JBoss Rules 4.0.0MR3, I cannot seem to
> > > get the dynamic proxies to work as facts. It seems that even though a
rule
> > > fires that changes a field on the proxy, a second rule that should not be
> > > activated after the update still fires.
> > >
> > > According to the JDK javadoc documentation, dynamic proxies are
> > > created as final. My assumption is that JBoss Rules is not creating
Shadow
> > > facts for these since they are final. After reading the JIRA at
> > > http://jira.jboss.com/jira/browse/JBRULES-960, I now am questioning
> > > what the effect of not using shadow facts is on the engine. The relevant
> > > part of that is:
> > >
> > > "The problem is that SpringAOP is generating a proxy whose methods
> > > equals() and hashCode() are "final". As drools must either
override these
> > > methods in the shadow proxy or not shadow the fact at all, I'm
disabling
> > > shadow proxy generation for this use case.
> > > It is really important to note that if you are asserting SpringAOP
> > > proxies as facts into the working memory, you will not be able to change
any
> > > field value whose field is constrained in rules or you may incur in a
memory
> > > leak and non-deterministic behavior by the rules engine. Unfortunately
there
> > > is nothing we can do about, since when SpringAOP makes the methods equals
> > > and hashcode final, we can't override them anymore and as so, we
can't
> > > shadow them."
> > > [ Show » <http://jira.jboss.com/jira/browse/JBRULES-960> ]
> > > Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> > > [02/Jul/07 03:29 PM] The problem is that SpringAOP is generating a
> > > proxy whose methods equals() and hashCode() are "final". As
drools must
> > > either override these methods in the shadow proxy or not shadow the fact
at
> > > all, I'm disabling shadow proxy generation for this use case. It is
really
> > > important to note that if you are asserting SpringAOP proxies as facts
into
> > > the working memory, you will not be able to change any field value whose
> > > field is constrained in rules or you may incur in a memory leak and
> > > non-deterministic behavior by the rules engine. Unfortunately there is
> > > nothing we can do about, since when SpringAOP makes the methods equals
and
> > > hashcode final, we can't override them anymore and as so, we can't
shadow
> > > them.
> > >
> > > Although I'm not using SpringAOP, I believe my facts are not being
> > > shadowed.
> > >
> > > Is it true that not using shadow facts may lead to non-deterministic
> > > behavior? Prior to shadow facts, the engine seemed to handle it. Any
> > > chance of reverting back to the old style of truth maintenance in the
case
> > > of not using shadow facts.
> > >
> > > I apologize if I'm not on the right track here. My only test case
> > > for my problem is the entire application right now, so I cannot offer it
for
> > > discussion. Any advice would be greatly appreciated.
> > >
> > > Thanks,
> > > -Chris West
> > >
> > > ------------------------------
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > >
> > >
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> > ------------------------------
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> >
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
10:44 a.m.
Edson,
After further investigation, I found that I was still manually setting the
property "drools.shadowProxyExcludes" to exclude my proxies from being
shadowed (even thought they would not have been shadowed anyway in 4.0.0MR3.
After removing this property, the latest snapshot from the trunk seems to
shadow my proxy based facts. However, I crash later in my code with the
following exception:
Exception in thread "main" java.lang.ClassCastException:
ascc.status.FlightOpsStatusBoard$LaunchRecoveryStatusShadowProxy
at
org.drools.base.ascc.status.AirPlanStatusBoard$SortieStatus$getState.getValue(Unknown
Source)
at org.drools.base.ClassFieldExtractor.getValue(ClassFieldExtractor.java
:94)
at
org.drools.base.evaluators.ObjectFactory$ObjectEqualEvaluator.evaluate(
ObjectFactory.java:103)
at org.drools.rule.LiteralRestriction.isAllowed(LiteralRestriction.java
:61)
at org.drools.rule.LiteralConstraint.isAllowed(LiteralConstraint.java
:82)
at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:122)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(
CompositeObjectSinkAdapter.java:308)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java
:168)
at org.drools.reteoo.Rete.assertObject(Rete.java:166)
at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java
:190)
at org.drools.reteoo.ReteooWorkingMemory.doInsert(
ReteooWorkingMemory.java:70)
at org.drools.common.AbstractWorkingMemory.update(
AbstractWorkingMemory.java:1209)
at org.drools.common.AbstractWorkingMemory.update(
AbstractWorkingMemory.java:1129)
at ascc.rules.AbstractRulesCoordinator.statusChanged(
AbstractRulesCoordinator.java:324)
at ascc.rules.AbstractRulesCoordinator.processSend(
AbstractRulesCoordinator.java:300)
at csf.engine.AbstractModelComponent.processSend(
AbstractModelComponent.java:213)
at csf.engine.SimulationEngine$SchedulerThread.run(SimulationEngine.java
:680)
I see the name LaunchRecoveryStatusShadowProxy above, which indicates a cast
is trying to occur that cannot. Could this be related to the change you
made to shadow proxies? If not, any ideas what might be occuring? I don't
have a simple test case for this problem.
Thanks,
-Chris West
On 7/18/07, Chris West <crayzfishr(a)gmail.com> wrote:
Edson,
I downloaded and built the latest from the trunk of the repository. I
applied this new build toward my test case, and it seemed to fix the
problem. However, when I applied it to my real project, it still exhibits
the problem. If I discover more information about the problem I'll let you
know.
Thanks,
Chris West
On 7/17/07, Edson Tirelli <tirelli(a)post.com> wrote:
>
>
> Chris,
>
> I found and developed an intermediate solution that shall work for
> your proxies.
> If it is not possible to create a shadow fact for a class that is
> asserted (because the class is final or whatever), the engine goes up in the
> class hierarchy, looking for a class or interface for which is possible to
> create the proxy, but that still matches all ObjectTypes available in the
> rule base matched by the original class. The analysis is a bit complex,
> specially because new rules with new object types can be dynamically added
> to the rule base, but I believe the solution will work for JDK proxies and
> the most common proxy frameworks out there, that usually don't proxy
> multiple unrelated interfaces at once.
>
> So, I ask you please to get latest snapshot from the repository and
> try it out for your use case and report back to the list the results, since
> seems there are a few other people using similar things.
>
> Thanks,
> Edson
>
>
> 2007/7/17, Chris West < crayzfishr(a)gmail.com>:
> >
> > Is that still true if the equals() and hashcode() methods are only
> > based on the identity fields of the object (which cannot change)?
> >
> > -Chris West
> >
> > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
> > >
> > > you only need to use modifyRetract if the object is inserted. The
> > > reason for this is if you change field values on your facts we will not
be
> > > able to remove them from our various internal hashmaps; thus the need to
> > > remove first prior to any changes, then make the changes and then insert
it
> > > again. We can't allow users to just call update() as we have no idea
what
> > > the old values where, thus we cannot find the objects in our hashmaps.
> > >
> > > Mark
> > > Chris West wrote:
> > >
> > > Mark,
> > >
> > > Using modifyRetract and modifyInsert seems to fix the problem (at
> > > least in my test case I finally created). I'll try this on my real
code.
> > >
> > > My only concern here is that it puts the burden on the rule author
> > > to know whether things are being shadowed or not. For shadowing that is
> > > explicitly turned off this is ok. But for implicit non-shadowing based on
a
> > > class being final, this is not at all obvious to the rule auther.
> > >
> > > Is there any way to have this hidden such that I can still call
> > > "update" but have it use "modifyRetract" and
"modifyInsert" instead?
> > >
> > > Also, I'm curious why I have to call modifyRetract before I start
> > > modifing the object, since the engine does not know about my
modifications
> > > anyway until I call update or modifyInsert? By the way, I was unable to
use
> > > the block setter approach in the rule consequence due to not having set
> > > methods for modifying my objects.
> > >
> > > Thanks,
> > > -Chris West
> > >
> > > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org > wrote:
> > > >
> > > > If you do not have shadow facts you cannot use the update()
> > > > method, it will leave the working memory corrupted. Instead you must
manage
> > > > this yourself, before you change any values on the object you must
call
> > > > modifyRetract() and after you hvae finished your changes ot hte
object call
> > > > modifyInsert() - luckily if you are doing this in the consequence you
can
> > > > use the MVEL modify keyword combined with the block setter and it
does this
> > > > for you:
> > > > modify ( person ) { age += 1, location = "london" }
> > > >
> > > > Mark
> > > > Chris West wrote:
> > > >
> > > > Hello,
> > > >
> > > > With prior versions of JBoss Rules (3.0.5) I have been using JDK
> > > > generated dynamic proxies as facts, and they have been working fine.
> > > > However, after upgrading to JBoss Rules 4.0.0MR3, I cannot seem to
> > > > get the dynamic proxies to work as facts. It seems that even though
a rule
> > > > fires that changes a field on the proxy, a second rule that should
not be
> > > > activated after the update still fires.
> > > >
> > > > According to the JDK javadoc documentation, dynamic proxies are
> > > > created as final. My assumption is that JBoss Rules is not creating
Shadow
> > > > facts for these since they are final. After reading the JIRA at
> > > > http://jira.jboss.com/jira/browse/JBRULES-960, I now am
> > > > questioning what the effect of not using shadow facts is on the
engine. The
> > > > relevant part of that is:
> > > >
> > > > "The problem is that SpringAOP is generating a proxy whose
methods
> > > > equals() and hashCode() are "final". As drools must either
override these
> > > > methods in the shadow proxy or not shadow the fact at all, I'm
disabling
> > > > shadow proxy generation for this use case.
> > > > It is really important to note that if you are asserting SpringAOP
> > > > proxies as facts into the working memory, you will not be able to
change any
> > > > field value whose field is constrained in rules or you may incur in a
memory
> > > > leak and non-deterministic behavior by the rules engine.
Unfortunately there
> > > > is nothing we can do about, since when SpringAOP makes the methods
equals
> > > > and hashcode final, we can't override them anymore and as so, we
can't
> > > > shadow them."
> > > > [ Show » <http://jira.jboss.com/jira/browse/JBRULES-960> ]
> > > > Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> > > > [02/Jul/07 03:29 PM] The problem is that SpringAOP is generating a
> > > > proxy whose methods equals() and hashCode() are "final". As
drools must
> > > > either override these methods in the shadow proxy or not shadow the
fact at
> > > > all, I'm disabling shadow proxy generation for this use case. It
is really
> > > > important to note that if you are asserting SpringAOP proxies as
facts into
> > > > the working memory, you will not be able to change any field value
whose
> > > > field is constrained in rules or you may incur in a memory leak and
> > > > non-deterministic behavior by the rules engine. Unfortunately there
is
> > > > nothing we can do about, since when SpringAOP makes the methods
equals and
> > > > hashcode final, we can't override them anymore and as so, we
can't shadow
> > > > them.
> > > >
> > > > Although I'm not using SpringAOP, I believe my facts are not
being
> > > > shadowed.
> > > >
> > > > Is it true that not using shadow facts may lead to
> > > > non-deterministic behavior? Prior to shadow facts, the engine seemed
to
> > > > handle it. Any chance of reverting back to the old style of truth
> > > > maintenance in the case of not using shadow facts.
> > > >
> > > > I apologize if I'm not on the right track here. My only test
case
> > > > for my problem is the entire application right now, so I cannot offer
it for
> > > > discussion. Any advice would be greatly appreciated.
> > > >
> > > > Thanks,
> > > > -Chris West
> > > >
> > > > ------------------------------
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > >
> > > >
> > > >
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > > ------------------------------
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > >
> > >
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
>
> --
> Edson Tirelli
> Software Engineer - JBoss Rules Core Developer
> Office: +55 11 3529-6000
> Mobile: +55 11 9287-5646
> JBoss, a division of Red Hat @ www.jboss.com
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
11:30 a.m.
Chris,
It is probably related. Can you isolate that in a self contained test
and send me? If it is proprietary code, you may send direct to me instead of
the list and I will not disclose. If we can fix that today, we may be able
to include it in final release as a bug fix.
[]s
Edson
2007/7/18, Chris West <crayzfishr(a)gmail.com>:
Edson,
After further investigation, I found that I was still manually setting the
property "drools.shadowProxyExcludes" to exclude my proxies from being
shadowed (even thought they would not have been shadowed anyway in
4.0.0MR3. After removing this property, the latest snapshot from the
trunk seems to shadow my proxy based facts. However, I crash later in my
code with the following exception:
Exception in thread "main" java.lang.ClassCastException:
ascc.status.FlightOpsStatusBoard$LaunchRecoveryStatusShadowProxy
at
org.drools.base.ascc.status.AirPlanStatusBoard$SortieStatus$getState.getValue(Unknown
Source)
at org.drools.base.ClassFieldExtractor.getValue (
ClassFieldExtractor.java:94)
at
org.drools.base.evaluators.ObjectFactory$ObjectEqualEvaluator.evaluate(
ObjectFactory.java:103)
at org.drools.rule.LiteralRestriction.isAllowed(
LiteralRestriction.java:61)
at org.drools.rule.LiteralConstraint.isAllowed(LiteralConstraint.java
:82)
at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:122)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(
CompositeObjectSinkAdapter.java:308)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java
:168)
at org.drools.reteoo.Rete.assertObject(Rete.java:166)
at org.drools.reteoo.ReteooRuleBase.assertObject (ReteooRuleBase.java
:190)
at org.drools.reteoo.ReteooWorkingMemory.doInsert(
ReteooWorkingMemory.java:70)
at org.drools.common.AbstractWorkingMemory.update(
AbstractWorkingMemory.java:1209)
at org.drools.common.AbstractWorkingMemory.update (
AbstractWorkingMemory.java:1129)
at ascc.rules.AbstractRulesCoordinator.statusChanged(
AbstractRulesCoordinator.java:324)
at ascc.rules.AbstractRulesCoordinator.processSend(
AbstractRulesCoordinator.java:300)
at csf.engine.AbstractModelComponent.processSend(
AbstractModelComponent.java:213)
at csf.engine.SimulationEngine$SchedulerThread.run(
SimulationEngine.java:680)
I see the name LaunchRecoveryStatusShadowProxy above, which indicates a
cast is trying to occur that cannot. Could this be related to the change
you made to shadow proxies? If not, any ideas what might be occuring? I
don't have a simple test case for this problem.
Thanks,
-Chris West
On 7/18/07, Chris West <crayzfishr(a)gmail.com> wrote:
>
> Edson,
>
> I downloaded and built the latest from the trunk of the repository. I
> applied this new build toward my test case, and it seemed to fix the
> problem. However, when I applied it to my real project, it still exhibits
> the problem. If I discover more information about the problem I'll let you
> know.
>
> Thanks,
> Chris West
>
> On 7/17/07, Edson Tirelli < tirelli(a)post.com> wrote:
> >
> >
> > Chris,
> >
> > I found and developed an intermediate solution that shall work for
> > your proxies.
> > If it is not possible to create a shadow fact for a class that is
> > asserted (because the class is final or whatever), the engine goes up in the
> > class hierarchy, looking for a class or interface for which is possible to
> > create the proxy, but that still matches all ObjectTypes available in the
> > rule base matched by the original class. The analysis is a bit complex,
> > specially because new rules with new object types can be dynamically added
> > to the rule base, but I believe the solution will work for JDK proxies and
> > the most common proxy frameworks out there, that usually don't proxy
> > multiple unrelated interfaces at once.
> >
> > So, I ask you please to get latest snapshot from the repository and
> > try it out for your use case and report back to the list the results, since
> > seems there are a few other people using similar things.
> >
> > Thanks,
> > Edson
> >
> >
> > 2007/7/17, Chris West < crayzfishr(a)gmail.com>:
> > >
> > > Is that still true if the equals() and hashcode() methods are only
> > > based on the identity fields of the object (which cannot change)?
> > >
> > > -Chris West
> > >
> > > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
> > > >
> > > > you only need to use modifyRetract if the object is inserted. The
> > > > reason for this is if you change field values on your facts we will
not be
> > > > able to remove them from our various internal hashmaps; thus the need
to
> > > > remove first prior to any changes, then make the changes and then
insert it
> > > > again. We can't allow users to just call update() as we have no
idea what
> > > > the old values where, thus we cannot find the objects in our
hashmaps.
> > > >
> > > > Mark
> > > > Chris West wrote:
> > > >
> > > > Mark,
> > > >
> > > > Using modifyRetract and modifyInsert seems to fix the problem (at
> > > > least in my test case I finally created). I'll try this on my
real code.
> > > >
> > > > My only concern here is that it puts the burden on the rule author
> > > > to know whether things are being shadowed or not. For shadowing that
is
> > > > explicitly turned off this is ok. But for implicit non-shadowing
based on a
> > > > class being final, this is not at all obvious to the rule auther.
> > > >
> > > > Is there any way to have this hidden such that I can still call
> > > > "update" but have it use "modifyRetract" and
"modifyInsert" instead?
> > > >
> > > > Also, I'm curious why I have to call modifyRetract before I
start
> > > > modifing the object, since the engine does not know about my
modifications
> > > > anyway until I call update or modifyInsert? By the way, I was unable
to use
> > > > the block setter approach in the rule consequence due to not having
set
> > > > methods for modifying my objects.
> > > >
> > > > Thanks,
> > > > -Chris West
> > > >
> > > > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org > wrote:
> > > > >
> > > > > If you do not have shadow facts you cannot use the update()
> > > > > method, it will leave the working memory corrupted. Instead you
must manage
> > > > > this yourself, before you change any values on the object you
must call
> > > > > modifyRetract() and after you hvae finished your changes ot hte
object call
> > > > > modifyInsert() - luckily if you are doing this in the
consequence you can
> > > > > use the MVEL modify keyword combined with the block setter and
it does this
> > > > > for you:
> > > > > modify ( person ) { age += 1, location = "london" }
> > > > >
> > > > > Mark
> > > > > Chris West wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > With prior versions of JBoss Rules (3.0.5) I have been using
JDK
> > > > > generated dynamic proxies as facts, and they have been working
fine.
> > > > > However, after upgrading to JBoss Rules 4.0.0MR3, I cannot seem
> > > > > to get the dynamic proxies to work as facts. It seems that even
though a
> > > > > rule fires that changes a field on the proxy, a second rule that
should not
> > > > > be activated after the update still fires.
> > > > >
> > > > > According to the JDK javadoc documentation, dynamic proxies are
> > > > > created as final. My assumption is that JBoss Rules is not
creating Shadow
> > > > > facts for these since they are final. After reading the JIRA
at
> > > > > http://jira.jboss.com/jira/browse/JBRULES-960, I now am
> > > > > questioning what the effect of not using shadow facts is on the
engine. The
> > > > > relevant part of that is:
> > > > >
> > > > > "The problem is that SpringAOP is generating a proxy whose
> > > > > methods equals() and hashCode() are "final". As drools
must either override
> > > > > these methods in the shadow proxy or not shadow the fact at all,
I'm
> > > > > disabling shadow proxy generation for this use case.
> > > > > It is really important to note that if you are asserting
> > > > > SpringAOP proxies as facts into the working memory, you will not
be able to
> > > > > change any field value whose field is constrained in rules or
you may incur
> > > > > in a memory leak and non-deterministic behavior by the rules
engine.
> > > > > Unfortunately there is nothing we can do about, since when
SpringAOP makes
> > > > > the methods equals and hashcode final, we can't override
them anymore and as
> > > > > so, we can't shadow them."
> > > > > [ Show » <http://jira.jboss.com/jira/browse/JBRULES-960>
]
> > > > > Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> > > > > [02/Jul/07 03:29 PM] The problem is that SpringAOP is
generating
> > > > > a proxy whose methods equals() and hashCode() are
"final". As drools must
> > > > > either override these methods in the shadow proxy or not shadow
the fact at
> > > > > all, I'm disabling shadow proxy generation for this use
case. It is really
> > > > > important to note that if you are asserting SpringAOP proxies as
facts into
> > > > > the working memory, you will not be able to change any field
value whose
> > > > > field is constrained in rules or you may incur in a memory leak
and
> > > > > non-deterministic behavior by the rules engine. Unfortunately
there is
> > > > > nothing we can do about, since when SpringAOP makes the methods
equals and
> > > > > hashcode final, we can't override them anymore and as so, we
can't shadow
> > > > > them.
> > > > >
> > > > > Although I'm not using SpringAOP, I believe my facts are
not
> > > > > being shadowed.
> > > > >
> > > > > Is it true that not using shadow facts may lead to
> > > > > non-deterministic behavior? Prior to shadow facts, the engine
seemed to
> > > > > handle it. Any chance of reverting back to the old style of
truth
> > > > > maintenance in the case of not using shadow facts.
> > > > >
> > > > > I apologize if I'm not on the right track here. My only
test
> > > > > case for my problem is the entire application right now, so I
cannot offer
> > > > > it for discussion. Any advice would be greatly appreciated.
> > > > >
> > > > > Thanks,
> > > > > -Chris West
> > > > >
> > > > > ------------------------------
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users(a)lists.jboss.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users(a)lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > >
> > > > >
> > > > ------------------------------
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > >
> > > >
> > > >
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> >
> >
> > --
> > Edson Tirelli
> > Software Engineer - JBoss Rules Core Developer
> > Office: +55 11 3529-6000
> > Mobile: +55 11 9287-5646
> > JBoss, a division of Red Hat @ www.jboss.com
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
11:43 a.m.
Edson,
I'll try to re-create the problem in a self contained test, but my rules are
very complex and very numerous, so I'm having a hard time pinpointed what
exactly triggers the condition.
As far as my code goes, my company will not let me disclose any of it.
Thanks for the suggestion, however.
Thanks,
-Chris West
On 7/18/07, Edson Tirelli <tirelli(a)post.com> wrote:
Chris,
It is probably related. Can you isolate that in a self contained test
and send me? If it is proprietary code, you may send direct to me instead of
the list and I will not disclose. If we can fix that today, we may be able
to include it in final release as a bug fix.
[]s
Edson
2007/7/18, Chris West <crayzfishr(a)gmail.com>:
>
> Edson,
>
> After further investigation, I found that I was still manually setting
> the property "drools.shadowProxyExcludes" to exclude my proxies from
> being shadowed (even thought they would not have been shadowed anyway in
> 4.0.0MR3. After removing this property, the latest snapshot from the
> trunk seems to shadow my proxy based facts. However, I crash later in my
> code with the following exception:
>
> Exception in thread "main" java.lang.ClassCastException:
> ascc.status.FlightOpsStatusBoard$LaunchRecoveryStatusShadowProxy
> at
>
org.drools.base.ascc.status.AirPlanStatusBoard$SortieStatus$getState.getValue(Unknown
> Source)
> at org.drools.base.ClassFieldExtractor.getValue (
> ClassFieldExtractor.java:94)
> at
> org.drools.base.evaluators.ObjectFactory$ObjectEqualEvaluator.evaluate(
> ObjectFactory.java:103)
> at org.drools.rule.LiteralRestriction.isAllowed(
> LiteralRestriction.java:61)
> at org.drools.rule.LiteralConstraint.isAllowed(
> LiteralConstraint.java:82)
> at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:122)
> at
> org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject (
> CompositeObjectSinkAdapter.java:308)
> at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java
> :168)
> at org.drools.reteoo.Rete.assertObject(Rete.java:166)
> at org.drools.reteoo.ReteooRuleBase.assertObject (
> ReteooRuleBase.java:190)
> at org.drools.reteoo.ReteooWorkingMemory.doInsert(
> ReteooWorkingMemory.java:70)
> at org.drools.common.AbstractWorkingMemory.update(
> AbstractWorkingMemory.java:1209)
> at org.drools.common.AbstractWorkingMemory.update (
> AbstractWorkingMemory.java:1129)
> at ascc.rules.AbstractRulesCoordinator.statusChanged(
> AbstractRulesCoordinator.java:324)
> at ascc.rules.AbstractRulesCoordinator.processSend(
> AbstractRulesCoordinator.java:300)
> at csf.engine.AbstractModelComponent.processSend(
> AbstractModelComponent.java:213)
> at csf.engine.SimulationEngine$SchedulerThread.run(
> SimulationEngine.java:680)
>
> I see the name LaunchRecoveryStatusShadowProxy above, which indicates a
> cast is trying to occur that cannot. Could this be related to the change
> you made to shadow proxies? If not, any ideas what might be occuring? I
> don't have a simple test case for this problem.
>
> Thanks,
> -Chris West
>
>
> On 7/18/07, Chris West < crayzfishr(a)gmail.com> wrote:
> >
> > Edson,
> >
> > I downloaded and built the latest from the trunk of the repository. I
> > applied this new build toward my test case, and it seemed to fix the
> > problem. However, when I applied it to my real project, it still exhibits
> > the problem. If I discover more information about the problem I'll let
you
> > know.
> >
> > Thanks,
> > Chris West
> >
> > On 7/17/07, Edson Tirelli < tirelli(a)post.com> wrote:
> > >
> > >
> > > Chris,
> > >
> > > I found and developed an intermediate solution that shall work
> > > for your proxies.
> > > If it is not possible to create a shadow fact for a class that is
> > > asserted (because the class is final or whatever), the engine goes up in
the
> > > class hierarchy, looking for a class or interface for which is possible
to
> > > create the proxy, but that still matches all ObjectTypes available in the
> > > rule base matched by the original class. The analysis is a bit complex,
> > > specially because new rules with new object types can be dynamically
added
> > > to the rule base, but I believe the solution will work for JDK proxies
and
> > > the most common proxy frameworks out there, that usually don't proxy
> > > multiple unrelated interfaces at once.
> > >
> > > So, I ask you please to get latest snapshot from the repository
> > > and try it out for your use case and report back to the list the results,
> > > since seems there are a few other people using similar things.
> > >
> > > Thanks,
> > > Edson
> > >
> > >
> > > 2007/7/17, Chris West < crayzfishr(a)gmail.com>:
> > > >
> > > > Is that still true if the equals() and hashcode() methods are only
> > > > based on the identity fields of the object (which cannot change)?
> > > >
> > > > -Chris West
> > > >
> > > > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
> > > > >
> > > > > you only need to use modifyRetract if the object is inserted.
> > > > > The reason for this is if you change field values on your facts
we will not
> > > > > be able to remove them from our various internal hashmaps; thus
the need to
> > > > > remove first prior to any changes, then make the changes and
then insert it
> > > > > again. We can't allow users to just call update() as we have
no idea what
> > > > > the old values where, thus we cannot find the objects in our
hashmaps.
> > > > >
> > > > > Mark
> > > > > Chris West wrote:
> > > > >
> > > > > Mark,
> > > > >
> > > > > Using modifyRetract and modifyInsert seems to fix the problem
> > > > > (at least in my test case I finally created). I'll try this
on my real
> > > > > code.
> > > > >
> > > > > My only concern here is that it puts the burden on the rule
> > > > > author to know whether things are being shadowed or not. For
shadowing that
> > > > > is explicitly turned off this is ok. But for implicit
non-shadowing based
> > > > > on a class being final, this is not at all obvious to the rule
auther.
> > > > >
> > > > > Is there any way to have this hidden such that I can still call
> > > > > "update" but have it use "modifyRetract" and
"modifyInsert" instead?
> > > > >
> > > > > Also, I'm curious why I have to call modifyRetract before I
> > > > > start modifing the object, since the engine does not know about
my
> > > > > modifications anyway until I call update or modifyInsert? By
the way, I was
> > > > > unable to use the block setter approach in the rule consequence
due to not
> > > > > having set methods for modifying my objects.
> > > > >
> > > > > Thanks,
> > > > > -Chris West
> > > > >
> > > > > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org > wrote:
> > > > > >
> > > > > > If you do not have shadow facts you cannot use the
update()
> > > > > > method, it will leave the working memory corrupted. Instead
you must manage
> > > > > > this yourself, before you change any values on the object
you must call
> > > > > > modifyRetract() and after you hvae finished your changes ot
hte object call
> > > > > > modifyInsert() - luckily if you are doing this in the
consequence you can
> > > > > > use the MVEL modify keyword combined with the block setter
and it does this
> > > > > > for you:
> > > > > > modify ( person ) { age += 1, location = "london"
}
> > > > > >
> > > > > > Mark
> > > > > > Chris West wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > With prior versions of JBoss Rules (3.0.5) I have been
using
> > > > > > JDK generated dynamic proxies as facts, and they have been
working fine.
> > > > > > However, after upgrading to JBoss Rules 4.0.0MR3, I cannot
> > > > > > seem to get the dynamic proxies to work as facts. It seems
that even though
> > > > > > a rule fires that changes a field on the proxy, a second
rule that should
> > > > > > not be activated after the update still fires.
> > > > > >
> > > > > > According to the JDK javadoc documentation, dynamic
proxies
> > > > > > are created as final. My assumption is that JBoss Rules is
not creating
> > > > > > Shadow facts for these since they are final. After reading
the JIRA at
> > > > > > http://jira.jboss.com/jira/browse/JBRULES-960, I now am
> > > > > > questioning what the effect of not using shadow facts is on
the engine. The
> > > > > > relevant part of that is:
> > > > > >
> > > > > > "The problem is that SpringAOP is generating a proxy
whose
> > > > > > methods equals() and hashCode() are "final". As
drools must either override
> > > > > > these methods in the shadow proxy or not shadow the fact at
all, I'm
> > > > > > disabling shadow proxy generation for this use case.
> > > > > > It is really important to note that if you are asserting
> > > > > > SpringAOP proxies as facts into the working memory, you
will not be able to
> > > > > > change any field value whose field is constrained in rules
or you may incur
> > > > > > in a memory leak and non-deterministic behavior by the
rules engine.
> > > > > > Unfortunately there is nothing we can do about, since when
SpringAOP makes
> > > > > > the methods equals and hashcode final, we can't
override them anymore and as
> > > > > > so, we can't shadow them."
> > > > > > [ Show »
<http://jira.jboss.com/jira/browse/JBRULES-960> ]
> > > > > > Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> > > > > > [02/Jul/07 03:29 PM] The problem is that SpringAOP is
> > > > > > generating a proxy whose methods equals() and hashCode()
are "final". As
> > > > > > drools must either override these methods in the shadow
proxy or not shadow
> > > > > > the fact at all, I'm disabling shadow proxy generation
for this use case. It
> > > > > > is really important to note that if you are asserting
SpringAOP proxies as
> > > > > > facts into the working memory, you will not be able to
change any field
> > > > > > value whose field is constrained in rules or you may incur
in a memory leak
> > > > > > and non-deterministic behavior by the rules engine.
Unfortunately there is
> > > > > > nothing we can do about, since when SpringAOP makes the
methods equals and
> > > > > > hashcode final, we can't override them anymore and as
so, we can't shadow
> > > > > > them.
> > > > > >
> > > > > > Although I'm not using SpringAOP, I believe my facts
are not
> > > > > > being shadowed.
> > > > > >
> > > > > > Is it true that not using shadow facts may lead to
> > > > > > non-deterministic behavior? Prior to shadow facts, the
engine seemed to
> > > > > > handle it. Any chance of reverting back to the old style
of truth
> > > > > > maintenance in the case of not using shadow facts.
> > > > > >
> > > > > > I apologize if I'm not on the right track here. My
only test
> > > > > > case for my problem is the entire application right now, so
I cannot offer
> > > > > > it for discussion. Any advice would be greatly
appreciated.
> > > > > >
> > > > > > Thanks,
> > > > > > -Chris West
> > > > > >
> > > > > > ------------------------------
> > > > > >
> > > > > > _______________________________________________
> > > > > > rules-users mailing list
> > > > > > rules-users(a)lists.jboss.org
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > rules-users mailing list
> > > > > > rules-users(a)lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > > ------------------------------
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users(a)lists.jboss.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users(a)lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > >
> > >
> > > --
> > > Edson Tirelli
> > > Software Engineer - JBoss Rules Core Developer
> > > Office: +55 11 3529-6000
> > > Mobile: +55 11 9287-5646
> > > JBoss, a division of Red Hat @ www.jboss.com
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
12:10 p.m.
Chris,
By the stack trace, the problem is triggered by a rule where you are
comparing (using ==) the "state" attribute of an
AirPlanStatusBoard.SortieStatus object...
[]s
Edson
2007/7/18, Chris West <crayzfishr(a)gmail.com>:
Edson,
I'll try to re-create the problem in a self contained test, but my rules
are very complex and very numerous, so I'm having a hard time pinpointed
what exactly triggers the condition.
As far as my code goes, my company will not let me disclose any of it.
Thanks for the suggestion, however.
Thanks,
-Chris West
On 7/18/07, Edson Tirelli <tirelli(a)post.com> wrote:
>
>
> Chris,
>
> It is probably related. Can you isolate that in a self contained
> test and send me? If it is proprietary code, you may send direct to me
> instead of the list and I will not disclose. If we can fix that today, we
> may be able to include it in final release as a bug fix.
>
> []s
> Edson
>
> 2007/7/18, Chris West <crayzfishr(a)gmail.com >:
> >
> > Edson,
> >
> > After further investigation, I found that I was still manually setting
> > the property "drools.shadowProxyExcludes" to exclude my proxies from
> > being shadowed (even thought they would not have been shadowed anyway in
> > 4.0.0MR3. After removing this property, the latest snapshot from the
> > trunk seems to shadow my proxy based facts. However, I crash later in my
> > code with the following exception:
> >
> > Exception in thread "main" java.lang.ClassCastException:
> > ascc.status.FlightOpsStatusBoard$LaunchRecoveryStatusShadowProxy
> > at
> >
org.drools.base.ascc.status.AirPlanStatusBoard$SortieStatus$getState.getValue(Unknown
> > Source)
> > at org.drools.base.ClassFieldExtractor.getValue (
> > ClassFieldExtractor.java:94)
> > at
> > org.drools.base.evaluators.ObjectFactory$ObjectEqualEvaluator.evaluate
> > (ObjectFactory.java:103)
> > at org.drools.rule.LiteralRestriction.isAllowed(
> > LiteralRestriction.java:61)
> > at org.drools.rule.LiteralConstraint.isAllowed(
> > LiteralConstraint.java:82)
> > at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:122)
> > at
> > org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject (
> > CompositeObjectSinkAdapter.java:308)
> > at org.drools.reteoo.ObjectTypeNode.assertObject(
> > ObjectTypeNode.java:168)
> > at org.drools.reteoo.Rete.assertObject(Rete.java:166)
> > at org.drools.reteoo.ReteooRuleBase.assertObject (
> > ReteooRuleBase.java:190)
> > at org.drools.reteoo.ReteooWorkingMemory.doInsert(
> > ReteooWorkingMemory.java:70)
> > at org.drools.common.AbstractWorkingMemory.update(
> > AbstractWorkingMemory.java:1209)
> > at org.drools.common.AbstractWorkingMemory.update (
> > AbstractWorkingMemory.java:1129)
> > at ascc.rules.AbstractRulesCoordinator.statusChanged(
> > AbstractRulesCoordinator.java:324)
> > at ascc.rules.AbstractRulesCoordinator.processSend(
> > AbstractRulesCoordinator.java:300)
> > at csf.engine.AbstractModelComponent.processSend(
> > AbstractModelComponent.java:213)
> > at csf.engine.SimulationEngine$SchedulerThread.run(
> > SimulationEngine.java:680)
> >
> > I see the name LaunchRecoveryStatusShadowProxy above, which indicates
> > a cast is trying to occur that cannot. Could this be related to the change
> > you made to shadow proxies? If not, any ideas what might be occuring? I
> > don't have a simple test case for this problem.
> >
> > Thanks,
> > -Chris West
> >
> >
> > On 7/18/07, Chris West < crayzfishr(a)gmail.com> wrote:
> > >
> > > Edson,
> > >
> > > I downloaded and built the latest from the trunk of the repository.
> > > I applied this new build toward my test case, and it seemed to fix the
> > > problem. However, when I applied it to my real project, it still
exhibits
> > > the problem. If I discover more information about the problem I'll
let you
> > > know.
> > >
> > > Thanks,
> > > Chris West
> > >
> > > On 7/17/07, Edson Tirelli < tirelli(a)post.com> wrote:
> > > >
> > > >
> > > > Chris,
> > > >
> > > > I found and developed an intermediate solution that shall work
> > > > for your proxies.
> > > > If it is not possible to create a shadow fact for a class that
> > > > is asserted (because the class is final or whatever), the engine goes
up in
> > > > the class hierarchy, looking for a class or interface for which is
possible
> > > > to create the proxy, but that still matches all ObjectTypes available
in the
> > > > rule base matched by the original class. The analysis is a bit
complex,
> > > > specially because new rules with new object types can be dynamically
added
> > > > to the rule base, but I believe the solution will work for JDK
proxies and
> > > > the most common proxy frameworks out there, that usually don't
proxy
> > > > multiple unrelated interfaces at once.
> > > >
> > > > So, I ask you please to get latest snapshot from the repository
> > > > and try it out for your use case and report back to the list the
results,
> > > > since seems there are a few other people using similar things.
> > > >
> > > > Thanks,
> > > > Edson
> > > >
> > > >
> > > > 2007/7/17, Chris West < crayzfishr(a)gmail.com>:
> > > > >
> > > > > Is that still true if the equals() and hashcode() methods are
> > > > > only based on the identity fields of the object (which cannot
change)?
> > > > >
> > > > > -Chris West
> > > > >
> > > > > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
> > > > > >
> > > > > > you only need to use modifyRetract if the object is
inserted.
> > > > > > The reason for this is if you change field values on your
facts we will not
> > > > > > be able to remove them from our various internal hashmaps;
thus the need to
> > > > > > remove first prior to any changes, then make the changes
and then insert it
> > > > > > again. We can't allow users to just call update() as we
have no idea what
> > > > > > the old values where, thus we cannot find the objects in
our hashmaps.
> > > > > >
> > > > > > Mark
> > > > > > Chris West wrote:
> > > > > >
> > > > > > Mark,
> > > > > >
> > > > > > Using modifyRetract and modifyInsert seems to fix the
problem
> > > > > > (at least in my test case I finally created). I'll try
this on my real
> > > > > > code.
> > > > > >
> > > > > > My only concern here is that it puts the burden on the
rule
> > > > > > author to know whether things are being shadowed or not.
For shadowing that
> > > > > > is explicitly turned off this is ok. But for implicit
non-shadowing based
> > > > > > on a class being final, this is not at all obvious to the
rule auther.
> > > > > >
> > > > > > Is there any way to have this hidden such that I can still
> > > > > > call "update" but have it use
"modifyRetract" and "modifyInsert" instead?
> > > > > >
> > > > > > Also, I'm curious why I have to call modifyRetract
before I
> > > > > > start modifing the object, since the engine does not know
about my
> > > > > > modifications anyway until I call update or modifyInsert?
By the way, I was
> > > > > > unable to use the block setter approach in the rule
consequence due to not
> > > > > > having set methods for modifying my objects.
> > > > > >
> > > > > > Thanks,
> > > > > > -Chris West
> > > > > >
> > > > > > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org >
wrote:
> > > > > > >
> > > > > > > If you do not have shadow facts you cannot use the
update()
> > > > > > > method, it will leave the working memory corrupted.
Instead you must manage
> > > > > > > this yourself, before you change any values on the
object you must call
> > > > > > > modifyRetract() and after you hvae finished your
changes ot hte object call
> > > > > > > modifyInsert() - luckily if you are doing this in the
consequence you can
> > > > > > > use the MVEL modify keyword combined with the block
setter and it does this
> > > > > > > for you:
> > > > > > > modify ( person ) { age += 1, location =
"london" }
> > > > > > >
> > > > > > > Mark
> > > > > > > Chris West wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > With prior versions of JBoss Rules (3.0.5) I have been
using
> > > > > > > JDK generated dynamic proxies as facts, and they have
been working fine.
> > > > > > > However, after upgrading to JBoss Rules 4.0.0MR3, I
cannot
> > > > > > > seem to get the dynamic proxies to work as facts. It
seems that even though
> > > > > > > a rule fires that changes a field on the proxy, a
second rule that should
> > > > > > > not be activated after the update still fires.
> > > > > > >
> > > > > > > According to the JDK javadoc documentation, dynamic
proxies
> > > > > > > are created as final. My assumption is that JBoss
Rules is not creating
> > > > > > > Shadow facts for these since they are final. After
reading the JIRA at
> > > > > > > http://jira.jboss.com/jira/browse/JBRULES-960, I now
am
> > > > > > > questioning what the effect of not using shadow facts
is on the engine. The
> > > > > > > relevant part of that is:
> > > > > > >
> > > > > > > "The problem is that SpringAOP is generating a
proxy whose
> > > > > > > methods equals() and hashCode() are "final".
As drools must either override
> > > > > > > these methods in the shadow proxy or not shadow the
fact at all, I'm
> > > > > > > disabling shadow proxy generation for this use case.
> > > > > > > It is really important to note that if you are
asserting
> > > > > > > SpringAOP proxies as facts into the working memory,
you will not be able to
> > > > > > > change any field value whose field is constrained in
rules or you may incur
> > > > > > > in a memory leak and non-deterministic behavior by the
rules engine.
> > > > > > > Unfortunately there is nothing we can do about, since
when SpringAOP makes
> > > > > > > the methods equals and hashcode final, we can't
override them anymore and as
> > > > > > > so, we can't shadow them."
> > > > > > > [ Show »
<http://jira.jboss.com/jira/browse/JBRULES-960> ]
> > > > > > >
> > > > > > > Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> > > > > > > [02/Jul/07 03:29 PM] The problem is that SpringAOP is
> > > > > > > generating a proxy whose methods equals() and
hashCode() are "final". As
> > > > > > > drools must either override these methods in the
shadow proxy or not shadow
> > > > > > > the fact at all, I'm disabling shadow proxy
generation for this use case. It
> > > > > > > is really important to note that if you are asserting
SpringAOP proxies as
> > > > > > > facts into the working memory, you will not be able to
change any field
> > > > > > > value whose field is constrained in rules or you may
incur in a memory leak
> > > > > > > and non-deterministic behavior by the rules engine.
Unfortunately there is
> > > > > > > nothing we can do about, since when SpringAOP makes
the methods equals and
> > > > > > > hashcode final, we can't override them anymore and
as so, we can't shadow
> > > > > > > them.
> > > > > > >
> > > > > > > Although I'm not using SpringAOP, I believe my
facts are not
> > > > > > > being shadowed.
> > > > > > >
> > > > > > > Is it true that not using shadow facts may lead to
> > > > > > > non-deterministic behavior? Prior to shadow facts,
the engine seemed to
> > > > > > > handle it. Any chance of reverting back to the old
style of truth
> > > > > > > maintenance in the case of not using shadow facts.
> > > > > > >
> > > > > > > I apologize if I'm not on the right track here.
My only
> > > > > > > test case for my problem is the entire application
right now, so I cannot
> > > > > > > offer it for discussion. Any advice would be greatly
appreciated.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > -Chris West
> > > > > > >
> > > > > > > ------------------------------
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > rules-users mailing list
> > > > > > > rules-users(a)lists.jboss.org
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > rules-users mailing list
> > > > > > > rules-users(a)lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > >
> > > > > > >
> > > > > > ------------------------------
> > > > > >
> > > > > > _______________________________________________
> > > > > > rules-users mailing list
> > > > > > rules-users(a)lists.jboss.org
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > rules-users mailing list
> > > > > > rules-users(a)lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users(a)lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Edson Tirelli
> > > > Software Engineer - JBoss Rules Core Developer
> > > > Office: +55 11 3529-6000
> > > > Mobile: +55 11 9287-5646
> > > > JBoss, a division of Red Hat @ www.jboss.com
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
>
> --
> Edson Tirelli
> Software Engineer - JBoss Rules Core Developer
> Office: +55 11 3529-6000
> Mobile: +55 11 9287-5646
> JBoss, a division of Red Hat @ www.jboss.com
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
2:48 p.m.
New subject: disable shadowing facts in MR3
Folks,
I need to disable shadowing for the facts, trying to use
"drools.shadowProxyExcludes" property like this:
---
final PackageBuilder builder = new PackageBuilder();
builder.addPackageFromDrl( new InputStreamReader(
DroolsTest2.class.getResourceAsStream( "/rules.drl" ) ) );
Properties prop = new Properties();
prop.setProperty("drools.shadowProxyExcludes",
"mypackage.MyClass");
RuleBaseConfiguration ruleBaseConfig = new
RuleBaseConfiguration(prop);
final RuleBase ruleBase =
RuleBaseFactory.newRuleBase(RuleBase.RETEOO, ruleBaseConfig);
ruleBase.addPackage( builder.getPackage() );
final StatefulSession session =
ruleBase.newStatefulSession();
session.insert(before);
session.fireAllRules(new MyClass());
---
Doesn't have any effect, my class gets still shadowed to become :
mypackage.MyClassShadowProxy
How can I disable shadowing???
Thanks,
-Sergey
**********************
** LEGAL DISCLAIMER **
**********************
This E-mail message and any attachments may contain
legally privileged, confidential or proprietary
information. If you are not the intended recipient(s),
or the employee or agent responsible for delivery of
this message to the intended recipient(s), you are
hereby notified that any dissemination, distribution
or copying of this E-mail message is strictly
prohibited. If you have received this message in
error, please immediately notify the sender and
delete this E-mail message from your computer.
4:05 p.m.
New subject: disable shadowing facts in MR3
You need to use trunk... that was not available in MR3 I think.
2007/7/18, Manukyan, Sergey <SManukyan(a)lear.com>:
Folks,
I need to disable shadowing for the facts, trying to use "
drools.shadowProxyExcludes" property like this:
---
*final* PackageBuilder builder = *new* PackageBuilder();
builder.addPackageFromDrl( *new* InputStreamReader(
DroolsTest2.*class*.getResourceAsStream( "/rules.drl" ) ) );
Properties prop = *new* Properties();
prop.setProperty("drools.shadowProxyExcludes", "
mypackage.MyClass");
RuleBaseConfiguration ruleBaseConfig = *new*RuleBaseConfiguration(
prop);
*final* RuleBase ruleBase = RuleBaseFactory.*newRuleBase*
(RuleBase.*RETEOO*, ruleBaseConfig);
ruleBase.addPackage( builder.getPackage() );
*final* StatefulSession session = ruleBase.newStatefulSession
();
session.insert(before);
session.fireAllRules(new MyClass());
---
Doesn't have any effect, my class gets still shadowed to become :
mypackage.MyClassShadowProxy
How can I disable shadowing???
Thanks,
-Sergey
**********************
** LEGAL DISCLAIMER **
**********************
This E-mail message and any attachments may contain
legally privileged, confidential or proprietary
information. If you are not the intended recipient(s),
or the employee or agent responsible for delivery of
this message to the intended recipient(s), you are
hereby notified that any dissemination, distribution
or copying of this E-mail message is strictly
prohibited. If you have received this message in
error, please immediately notify the sender and
delete this E-mail message from your computer.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
11:15 a.m.
Chris,
For the solution to work, it is important that a superclass or interface
matches all the ObjectTypes in your rulebase that your final class (proxy)
matches... I guess that is the case with JDK proxies, isn't it?
[]s
Edson
2007/7/18, Chris West <crayzfishr(a)gmail.com>:
Edson,
I downloaded and built the latest from the trunk of the repository. I
applied this new build toward my test case, and it seemed to fix the
problem. However, when I applied it to my real project, it still exhibits
the problem. If I discover more information about the problem I'll let you
know.
Thanks,
Chris West
On 7/17/07, Edson Tirelli <tirelli(a)post.com> wrote:
>
>
> Chris,
>
> I found and developed an intermediate solution that shall work for
> your proxies.
> If it is not possible to create a shadow fact for a class that is
> asserted (because the class is final or whatever), the engine goes up in the
> class hierarchy, looking for a class or interface for which is possible to
> create the proxy, but that still matches all ObjectTypes available in the
> rule base matched by the original class. The analysis is a bit complex,
> specially because new rules with new object types can be dynamically added
> to the rule base, but I believe the solution will work for JDK proxies and
> the most common proxy frameworks out there, that usually don't proxy
> multiple unrelated interfaces at once.
>
> So, I ask you please to get latest snapshot from the repository and
> try it out for your use case and report back to the list the results, since
> seems there are a few other people using similar things.
>
> Thanks,
> Edson
>
>
> 2007/7/17, Chris West < crayzfishr(a)gmail.com>:
> >
> > Is that still true if the equals() and hashcode() methods are only
> > based on the identity fields of the object (which cannot change)?
> >
> > -Chris West
> >
> > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
> > >
> > > you only need to use modifyRetract if the object is inserted. The
> > > reason for this is if you change field values on your facts we will not
be
> > > able to remove them from our various internal hashmaps; thus the need to
> > > remove first prior to any changes, then make the changes and then insert
it
> > > again. We can't allow users to just call update() as we have no idea
what
> > > the old values where, thus we cannot find the objects in our hashmaps.
> > >
> > > Mark
> > > Chris West wrote:
> > >
> > > Mark,
> > >
> > > Using modifyRetract and modifyInsert seems to fix the problem (at
> > > least in my test case I finally created). I'll try this on my real
code.
> > >
> > > My only concern here is that it puts the burden on the rule author
> > > to know whether things are being shadowed or not. For shadowing that is
> > > explicitly turned off this is ok. But for implicit non-shadowing based on
a
> > > class being final, this is not at all obvious to the rule auther.
> > >
> > > Is there any way to have this hidden such that I can still call
> > > "update" but have it use "modifyRetract" and
"modifyInsert" instead?
> > >
> > > Also, I'm curious why I have to call modifyRetract before I start
> > > modifing the object, since the engine does not know about my
modifications
> > > anyway until I call update or modifyInsert? By the way, I was unable to
use
> > > the block setter approach in the rule consequence due to not having set
> > > methods for modifying my objects.
> > >
> > > Thanks,
> > > -Chris West
> > >
> > > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org > wrote:
> > > >
> > > > If you do not have shadow facts you cannot use the update()
> > > > method, it will leave the working memory corrupted. Instead you must
manage
> > > > this yourself, before you change any values on the object you must
call
> > > > modifyRetract() and after you hvae finished your changes ot hte
object call
> > > > modifyInsert() - luckily if you are doing this in the consequence you
can
> > > > use the MVEL modify keyword combined with the block setter and it
does this
> > > > for you:
> > > > modify ( person ) { age += 1, location = "london" }
> > > >
> > > > Mark
> > > > Chris West wrote:
> > > >
> > > > Hello,
> > > >
> > > > With prior versions of JBoss Rules (3.0.5) I have been using JDK
> > > > generated dynamic proxies as facts, and they have been working fine.
> > > > However, after upgrading to JBoss Rules 4.0.0MR3, I cannot seem to
> > > > get the dynamic proxies to work as facts. It seems that even though
a rule
> > > > fires that changes a field on the proxy, a second rule that should
not be
> > > > activated after the update still fires.
> > > >
> > > > According to the JDK javadoc documentation, dynamic proxies are
> > > > created as final. My assumption is that JBoss Rules is not creating
Shadow
> > > > facts for these since they are final. After reading the JIRA at
> > > > http://jira.jboss.com/jira/browse/JBRULES-960, I now am
> > > > questioning what the effect of not using shadow facts is on the
engine. The
> > > > relevant part of that is:
> > > >
> > > > "The problem is that SpringAOP is generating a proxy whose
methods
> > > > equals() and hashCode() are "final". As drools must either
override these
> > > > methods in the shadow proxy or not shadow the fact at all, I'm
disabling
> > > > shadow proxy generation for this use case.
> > > > It is really important to note that if you are asserting SpringAOP
> > > > proxies as facts into the working memory, you will not be able to
change any
> > > > field value whose field is constrained in rules or you may incur in a
memory
> > > > leak and non-deterministic behavior by the rules engine.
Unfortunately there
> > > > is nothing we can do about, since when SpringAOP makes the methods
equals
> > > > and hashcode final, we can't override them anymore and as so, we
can't
> > > > shadow them."
> > > > [ Show » <http://jira.jboss.com/jira/browse/JBRULES-960> ]
> > > > Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> > > > [02/Jul/07 03:29 PM] The problem is that SpringAOP is generating a
> > > > proxy whose methods equals() and hashCode() are "final". As
drools must
> > > > either override these methods in the shadow proxy or not shadow the
fact at
> > > > all, I'm disabling shadow proxy generation for this use case. It
is really
> > > > important to note that if you are asserting SpringAOP proxies as
facts into
> > > > the working memory, you will not be able to change any field value
whose
> > > > field is constrained in rules or you may incur in a memory leak and
> > > > non-deterministic behavior by the rules engine. Unfortunately there
is
> > > > nothing we can do about, since when SpringAOP makes the methods
equals and
> > > > hashcode final, we can't override them anymore and as so, we
can't shadow
> > > > them.
> > > >
> > > > Although I'm not using SpringAOP, I believe my facts are not
being
> > > > shadowed.
> > > >
> > > > Is it true that not using shadow facts may lead to
> > > > non-deterministic behavior? Prior to shadow facts, the engine seemed
to
> > > > handle it. Any chance of reverting back to the old style of truth
> > > > maintenance in the case of not using shadow facts.
> > > >
> > > > I apologize if I'm not on the right track here. My only test
case
> > > > for my problem is the entire application right now, so I cannot offer
it for
> > > > discussion. Any advice would be greatly appreciated.
> > > >
> > > > Thanks,
> > > > -Chris West
> > > >
> > > > ------------------------------
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > >
> > > >
> > > >
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > > ------------------------------
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > >
> > >
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
>
> --
> Edson Tirelli
> Software Engineer - JBoss Rules Core Developer
> Office: +55 11 3529-6000
> Mobile: +55 11 9287-5646
> JBoss, a division of Red Hat @ www.jboss.com
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
11:38 a.m.
Edson,
It is certainly possible to create a JDK proxy with only some of the
interfaces that are present on the delegate object that you are proxying,
but in my case, my proxies have all the interfaces of the underlying object.
The top two lines of the call stack I sent shows the following:
Exception in thread "main" java.lang.ClassCastException:
ascc.status.FlightOpsStatusBoard$LaunchRecoveryStatusShadowProxy
at
org.drools.base.ascc.status.AirPlanStatusBoard$SortieStatus$getState.getValue(Unknown
Source)
What's strange here is that the ClassCastException seems to be caused by
casting an object of type SortieStatus to type
LaunchRecoveryStatusShadowProxy, if I'm reading that right. The types
SortieStatus and LaunchRecoveryStatus are both interfaces in my code, and
they never appear on the same fact object (so no SortieStatus will ever be a
LaunchRecoveryStatus and vice-versa). So I'm wondering why the cast is
occuring, since it is not possible to work.
The unfortunate part is I cannot see into the class where the cast is
occurring, as it is a generated class created by drools.
-Chris West
On 7/18/07, Edson Tirelli <tirelli(a)post.com> wrote:
Chris,
For the solution to work, it is important that a superclass or
interface matches all the ObjectTypes in your rulebase that your final class
(proxy) matches... I guess that is the case with JDK proxies, isn't it?
[]s
Edson
2007/7/18, Chris West <crayzfishr(a)gmail.com>:
>
> Edson,
>
> I downloaded and built the latest from the trunk of the repository. I
> applied this new build toward my test case, and it seemed to fix the
> problem. However, when I applied it to my real project, it still exhibits
> the problem. If I discover more information about the problem I'll let you
> know.
>
> Thanks,
> Chris West
>
> On 7/17/07, Edson Tirelli < tirelli(a)post.com> wrote:
> >
> >
> > Chris,
> >
> > I found and developed an intermediate solution that shall work for
> > your proxies.
> > If it is not possible to create a shadow fact for a class that is
> > asserted (because the class is final or whatever), the engine goes up in the
> > class hierarchy, looking for a class or interface for which is possible to
> > create the proxy, but that still matches all ObjectTypes available in the
> > rule base matched by the original class. The analysis is a bit complex,
> > specially because new rules with new object types can be dynamically added
> > to the rule base, but I believe the solution will work for JDK proxies and
> > the most common proxy frameworks out there, that usually don't proxy
> > multiple unrelated interfaces at once.
> >
> > So, I ask you please to get latest snapshot from the repository and
> > try it out for your use case and report back to the list the results, since
> > seems there are a few other people using similar things.
> >
> > Thanks,
> > Edson
> >
> >
> > 2007/7/17, Chris West < crayzfishr(a)gmail.com>:
> > >
> > > Is that still true if the equals() and hashcode() methods are only
> > > based on the identity fields of the object (which cannot change)?
> > >
> > > -Chris West
> > >
> > > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
> > > >
> > > > you only need to use modifyRetract if the object is inserted. The
> > > > reason for this is if you change field values on your facts we will
not be
> > > > able to remove them from our various internal hashmaps; thus the need
to
> > > > remove first prior to any changes, then make the changes and then
insert it
> > > > again. We can't allow users to just call update() as we have no
idea what
> > > > the old values where, thus we cannot find the objects in our
hashmaps.
> > > >
> > > > Mark
> > > > Chris West wrote:
> > > >
> > > > Mark,
> > > >
> > > > Using modifyRetract and modifyInsert seems to fix the problem (at
> > > > least in my test case I finally created). I'll try this on my
real code.
> > > >
> > > > My only concern here is that it puts the burden on the rule author
> > > > to know whether things are being shadowed or not. For shadowing that
is
> > > > explicitly turned off this is ok. But for implicit non-shadowing
based on a
> > > > class being final, this is not at all obvious to the rule auther.
> > > >
> > > > Is there any way to have this hidden such that I can still call
> > > > "update" but have it use "modifyRetract" and
"modifyInsert" instead?
> > > >
> > > > Also, I'm curious why I have to call modifyRetract before I
start
> > > > modifing the object, since the engine does not know about my
modifications
> > > > anyway until I call update or modifyInsert? By the way, I was unable
to use
> > > > the block setter approach in the rule consequence due to not having
set
> > > > methods for modifying my objects.
> > > >
> > > > Thanks,
> > > > -Chris West
> > > >
> > > > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org > wrote:
> > > > >
> > > > > If you do not have shadow facts you cannot use the update()
> > > > > method, it will leave the working memory corrupted. Instead you
must manage
> > > > > this yourself, before you change any values on the object you
must call
> > > > > modifyRetract() and after you hvae finished your changes ot hte
object call
> > > > > modifyInsert() - luckily if you are doing this in the
consequence you can
> > > > > use the MVEL modify keyword combined with the block setter and
it does this
> > > > > for you:
> > > > > modify ( person ) { age += 1, location = "london" }
> > > > >
> > > > > Mark
> > > > > Chris West wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > With prior versions of JBoss Rules (3.0.5) I have been using
JDK
> > > > > generated dynamic proxies as facts, and they have been working
fine.
> > > > > However, after upgrading to JBoss Rules 4.0.0MR3, I cannot seem
> > > > > to get the dynamic proxies to work as facts. It seems that even
though a
> > > > > rule fires that changes a field on the proxy, a second rule that
should not
> > > > > be activated after the update still fires.
> > > > >
> > > > > According to the JDK javadoc documentation, dynamic proxies are
> > > > > created as final. My assumption is that JBoss Rules is not
creating Shadow
> > > > > facts for these since they are final. After reading the JIRA
at
> > > > > http://jira.jboss.com/jira/browse/JBRULES-960, I now am
> > > > > questioning what the effect of not using shadow facts is on the
engine. The
> > > > > relevant part of that is:
> > > > >
> > > > > "The problem is that SpringAOP is generating a proxy whose
> > > > > methods equals() and hashCode() are "final". As drools
must either override
> > > > > these methods in the shadow proxy or not shadow the fact at all,
I'm
> > > > > disabling shadow proxy generation for this use case.
> > > > > It is really important to note that if you are asserting
> > > > > SpringAOP proxies as facts into the working memory, you will not
be able to
> > > > > change any field value whose field is constrained in rules or
you may incur
> > > > > in a memory leak and non-deterministic behavior by the rules
engine.
> > > > > Unfortunately there is nothing we can do about, since when
SpringAOP makes
> > > > > the methods equals and hashcode final, we can't override
them anymore and as
> > > > > so, we can't shadow them."
> > > > > [ Show » <http://jira.jboss.com/jira/browse/JBRULES-960>
]
> > > > > Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> > > > > [02/Jul/07 03:29 PM] The problem is that SpringAOP is
generating
> > > > > a proxy whose methods equals() and hashCode() are
"final". As drools must
> > > > > either override these methods in the shadow proxy or not shadow
the fact at
> > > > > all, I'm disabling shadow proxy generation for this use
case. It is really
> > > > > important to note that if you are asserting SpringAOP proxies as
facts into
> > > > > the working memory, you will not be able to change any field
value whose
> > > > > field is constrained in rules or you may incur in a memory leak
and
> > > > > non-deterministic behavior by the rules engine. Unfortunately
there is
> > > > > nothing we can do about, since when SpringAOP makes the methods
equals and
> > > > > hashcode final, we can't override them anymore and as so, we
can't shadow
> > > > > them.
> > > > >
> > > > > Although I'm not using SpringAOP, I believe my facts are
not
> > > > > being shadowed.
> > > > >
> > > > > Is it true that not using shadow facts may lead to
> > > > > non-deterministic behavior? Prior to shadow facts, the engine
seemed to
> > > > > handle it. Any chance of reverting back to the old style of
truth
> > > > > maintenance in the case of not using shadow facts.
> > > > >
> > > > > I apologize if I'm not on the right track here. My only
test
> > > > > case for my problem is the entire application right now, so I
cannot offer
> > > > > it for discussion. Any advice would be greatly appreciated.
> > > > >
> > > > > Thanks,
> > > > > -Chris West
> > > > >
> > > > > ------------------------------
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users(a)lists.jboss.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users(a)lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > >
> > > > >
> > > > ------------------------------
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > >
> > > >
> > > >
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> >
> >
> > --
> > Edson Tirelli
> > Software Engineer - JBoss Rules Core Developer
> > Office: +55 11 3529-6000
> > Mobile: +55 11 9287-5646
> > JBoss, a division of Red Hat @ www.jboss.com
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
12:03 p.m.
Chris,
What seems to be happening us that your SortieStatus interface has a
state attribute. Drools is trying to read this attribute value and cast it
to LaunchRecoveryStatusShadowProxy what is causing the problems...
Best way to solve would be to have the code so I can debug. Is it
possible to isolate it and send me?
[]s
Edson
2007/7/18, Chris West <crayzfishr(a)gmail.com>:
Edson,
It is certainly possible to create a JDK proxy with only some of the
interfaces that are present on the delegate object that you are proxying,
but in my case, my proxies have all the interfaces of the underlying object.
The top two lines of the call stack I sent shows the following:
Exception in thread "main" java.lang.ClassCastException:
ascc.status.FlightOpsStatusBoard$LaunchRecoveryStatusShadowProxy
at
org.drools.base.ascc.status.AirPlanStatusBoard$SortieStatus$getState.getValue(Unknown
Source)
What's strange here is that the ClassCastException seems to be caused by
casting an object of type SortieStatus to type
LaunchRecoveryStatusShadowProxy, if I'm reading that right. The types
SortieStatus and LaunchRecoveryStatus are both interfaces in my code, and
they never appear on the same fact object (so no SortieStatus will ever be a
LaunchRecoveryStatus and vice-versa). So I'm wondering why the cast is
occuring, since it is not possible to work.
The unfortunate part is I cannot see into the class where the cast is
occurring, as it is a generated class created by drools.
-Chris West
On 7/18/07, Edson Tirelli <tirelli(a)post.com> wrote:
>
>
> Chris,
>
> For the solution to work, it is important that a superclass or
> interface matches all the ObjectTypes in your rulebase that your final class
> (proxy) matches... I guess that is the case with JDK proxies, isn't it?
>
> []s
> Edson
>
> 2007/7/18, Chris West <crayzfishr(a)gmail.com >:
> >
> > Edson,
> >
> > I downloaded and built the latest from the trunk of the repository. I
> > applied this new build toward my test case, and it seemed to fix the
> > problem. However, when I applied it to my real project, it still exhibits
> > the problem. If I discover more information about the problem I'll let
you
> > know.
> >
> > Thanks,
> > Chris West
> >
> > On 7/17/07, Edson Tirelli < tirelli(a)post.com> wrote:
> > >
> > >
> > > Chris,
> > >
> > > I found and developed an intermediate solution that shall work
> > > for your proxies.
> > > If it is not possible to create a shadow fact for a class that is
> > > asserted (because the class is final or whatever), the engine goes up in
the
> > > class hierarchy, looking for a class or interface for which is possible
to
> > > create the proxy, but that still matches all ObjectTypes available in the
> > > rule base matched by the original class. The analysis is a bit complex,
> > > specially because new rules with new object types can be dynamically
added
> > > to the rule base, but I believe the solution will work for JDK proxies
and
> > > the most common proxy frameworks out there, that usually don't proxy
> > > multiple unrelated interfaces at once.
> > >
> > > So, I ask you please to get latest snapshot from the repository
> > > and try it out for your use case and report back to the list the results,
> > > since seems there are a few other people using similar things.
> > >
> > > Thanks,
> > > Edson
> > >
> > >
> > > 2007/7/17, Chris West < crayzfishr(a)gmail.com>:
> > > >
> > > > Is that still true if the equals() and hashcode() methods are only
> > > > based on the identity fields of the object (which cannot change)?
> > > >
> > > > -Chris West
> > > >
> > > > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
> > > > >
> > > > > you only need to use modifyRetract if the object is inserted.
> > > > > The reason for this is if you change field values on your facts
we will not
> > > > > be able to remove them from our various internal hashmaps; thus
the need to
> > > > > remove first prior to any changes, then make the changes and
then insert it
> > > > > again. We can't allow users to just call update() as we have
no idea what
> > > > > the old values where, thus we cannot find the objects in our
hashmaps.
> > > > >
> > > > > Mark
> > > > > Chris West wrote:
> > > > >
> > > > > Mark,
> > > > >
> > > > > Using modifyRetract and modifyInsert seems to fix the problem
> > > > > (at least in my test case I finally created). I'll try this
on my real
> > > > > code.
> > > > >
> > > > > My only concern here is that it puts the burden on the rule
> > > > > author to know whether things are being shadowed or not. For
shadowing that
> > > > > is explicitly turned off this is ok. But for implicit
non-shadowing based
> > > > > on a class being final, this is not at all obvious to the rule
auther.
> > > > >
> > > > > Is there any way to have this hidden such that I can still call
> > > > > "update" but have it use "modifyRetract" and
"modifyInsert" instead?
> > > > >
> > > > > Also, I'm curious why I have to call modifyRetract before I
> > > > > start modifing the object, since the engine does not know about
my
> > > > > modifications anyway until I call update or modifyInsert? By
the way, I was
> > > > > unable to use the block setter approach in the rule consequence
due to not
> > > > > having set methods for modifying my objects.
> > > > >
> > > > > Thanks,
> > > > > -Chris West
> > > > >
> > > > > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org > wrote:
> > > > > >
> > > > > > If you do not have shadow facts you cannot use the
update()
> > > > > > method, it will leave the working memory corrupted. Instead
you must manage
> > > > > > this yourself, before you change any values on the object
you must call
> > > > > > modifyRetract() and after you hvae finished your changes ot
hte object call
> > > > > > modifyInsert() - luckily if you are doing this in the
consequence you can
> > > > > > use the MVEL modify keyword combined with the block setter
and it does this
> > > > > > for you:
> > > > > > modify ( person ) { age += 1, location = "london"
}
> > > > > >
> > > > > > Mark
> > > > > > Chris West wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > With prior versions of JBoss Rules (3.0.5) I have been
using
> > > > > > JDK generated dynamic proxies as facts, and they have been
working fine.
> > > > > > However, after upgrading to JBoss Rules 4.0.0MR3, I cannot
> > > > > > seem to get the dynamic proxies to work as facts. It seems
that even though
> > > > > > a rule fires that changes a field on the proxy, a second
rule that should
> > > > > > not be activated after the update still fires.
> > > > > >
> > > > > > According to the JDK javadoc documentation, dynamic
proxies
> > > > > > are created as final. My assumption is that JBoss Rules is
not creating
> > > > > > Shadow facts for these since they are final. After reading
the JIRA at
> > > > > > http://jira.jboss.com/jira/browse/JBRULES-960, I now am
> > > > > > questioning what the effect of not using shadow facts is on
the engine. The
> > > > > > relevant part of that is:
> > > > > >
> > > > > > "The problem is that SpringAOP is generating a proxy
whose
> > > > > > methods equals() and hashCode() are "final". As
drools must either override
> > > > > > these methods in the shadow proxy or not shadow the fact at
all, I'm
> > > > > > disabling shadow proxy generation for this use case.
> > > > > > It is really important to note that if you are asserting
> > > > > > SpringAOP proxies as facts into the working memory, you
will not be able to
> > > > > > change any field value whose field is constrained in rules
or you may incur
> > > > > > in a memory leak and non-deterministic behavior by the
rules engine.
> > > > > > Unfortunately there is nothing we can do about, since when
SpringAOP makes
> > > > > > the methods equals and hashcode final, we can't
override them anymore and as
> > > > > > so, we can't shadow them."
> > > > > > [ Show »
<http://jira.jboss.com/jira/browse/JBRULES-960> ]
> > > > > > Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> > > > > > [02/Jul/07 03:29 PM] The problem is that SpringAOP is
> > > > > > generating a proxy whose methods equals() and hashCode()
are "final". As
> > > > > > drools must either override these methods in the shadow
proxy or not shadow
> > > > > > the fact at all, I'm disabling shadow proxy generation
for this use case. It
> > > > > > is really important to note that if you are asserting
SpringAOP proxies as
> > > > > > facts into the working memory, you will not be able to
change any field
> > > > > > value whose field is constrained in rules or you may incur
in a memory leak
> > > > > > and non-deterministic behavior by the rules engine.
Unfortunately there is
> > > > > > nothing we can do about, since when SpringAOP makes the
methods equals and
> > > > > > hashcode final, we can't override them anymore and as
so, we can't shadow
> > > > > > them.
> > > > > >
> > > > > > Although I'm not using SpringAOP, I believe my facts
are not
> > > > > > being shadowed.
> > > > > >
> > > > > > Is it true that not using shadow facts may lead to
> > > > > > non-deterministic behavior? Prior to shadow facts, the
engine seemed to
> > > > > > handle it. Any chance of reverting back to the old style
of truth
> > > > > > maintenance in the case of not using shadow facts.
> > > > > >
> > > > > > I apologize if I'm not on the right track here. My
only test
> > > > > > case for my problem is the entire application right now, so
I cannot offer
> > > > > > it for discussion. Any advice would be greatly
appreciated.
> > > > > >
> > > > > > Thanks,
> > > > > > -Chris West
> > > > > >
> > > > > > ------------------------------
> > > > > >
> > > > > > _______________________________________________
> > > > > > rules-users mailing list
> > > > > > rules-users(a)lists.jboss.org
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > rules-users mailing list
> > > > > > rules-users(a)lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > > ------------------------------
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users(a)lists.jboss.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users(a)lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > >
> > >
> > > --
> > > Edson Tirelli
> > > Software Engineer - JBoss Rules Core Developer
> > > Office: +55 11 3529-6000
> > > Mobile: +55 11 9287-5646
> > > JBoss, a division of Red Hat @ www.jboss.com
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
>
> --
> Edson Tirelli
> Software Engineer - JBoss Rules Core Developer
> Office: +55 11 3529-6000
> Mobile: +55 11 9287-5646
> JBoss, a division of Red Hat @ www.jboss.com
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
11:27 a.m.
Edson,
I think I've discovered the problem. In the file Rete.java, in the method
"assertObject", there is a check for shadow proxy like below:
Class cls = object.getClass();
if ( object instanceof ShadowProxy ) {
cls = cls.getSuperclass();
}
If the class being proxied was final, and your new logic chose an interface
of that class to build a proxy from, then the superclass is Object.class.
This leads to an incorrect selection of cachedNodes further down in the
method.
I've traced this through the debugger with my object types, and it does show
that a node for a SortieStatus is being given an object of type
LaunchRecoveryStatusShadowProxy, which is not compatible.
Perhaps theres a different way to determine the type of object such that
type LaunchRecoveryStatusShadowProxy will return LaunchRecoveryStatus rather
than Object.
Please take a look and let me know if I need to provide more info.
Thanks,
-Chris West
On 7/18/07, Edson Tirelli <tirelli(a)post.com> wrote:
Chris,
What seems to be happening us that your SortieStatus interface has a
state attribute. Drools is trying to read this attribute value and cast it
to LaunchRecoveryStatusShadowProxy what is causing the problems...
Best way to solve would be to have the code so I can debug. Is it
possible to isolate it and send me?
[]s
Edson
2007/7/18, Chris West < crayzfishr(a)gmail.com>:
>
> Edson,
>
> It is certainly possible to create a JDK proxy with only some of the
> interfaces that are present on the delegate object that you are proxying,
> but in my case, my proxies have all the interfaces of the underlying object.
>
>
> The top two lines of the call stack I sent shows the following:
>
> Exception in thread "main" java.lang.ClassCastException:
> ascc.status.FlightOpsStatusBoard$LaunchRecoveryStatusShadowProxy
> at
>
org.drools.base.ascc.status.AirPlanStatusBoard$SortieStatus$getState.getValue(Unknown
> Source)
>
> What's strange here is that the ClassCastException seems to be caused by
> casting an object of type SortieStatus to type
> LaunchRecoveryStatusShadowProxy, if I'm reading that right. The types
> SortieStatus and LaunchRecoveryStatus are both interfaces in my code, and
> they never appear on the same fact object (so no SortieStatus will ever be a
> LaunchRecoveryStatus and vice-versa). So I'm wondering why the cast is
> occuring, since it is not possible to work.
>
> The unfortunate part is I cannot see into the class where the cast is
> occurring, as it is a generated class created by drools.
>
> -Chris West
>
> On 7/18/07, Edson Tirelli <tirelli(a)post.com> wrote:
> >
> >
> > Chris,
> >
> > For the solution to work, it is important that a superclass or
> > interface matches all the ObjectTypes in your rulebase that your final class
> > (proxy) matches... I guess that is the case with JDK proxies, isn't it?
> >
> > []s
> > Edson
> >
> > 2007/7/18, Chris West <crayzfishr(a)gmail.com >:
> > >
> > > Edson,
> > >
> > > I downloaded and built the latest from the trunk of the repository.
> > > I applied this new build toward my test case, and it seemed to fix the
> > > problem. However, when I applied it to my real project, it still
exhibits
> > > the problem. If I discover more information about the problem I'll
let you
> > > know.
> > >
> > > Thanks,
> > > Chris West
> > >
> > > On 7/17/07, Edson Tirelli < tirelli(a)post.com> wrote:
> > > >
> > > >
> > > > Chris,
> > > >
> > > > I found and developed an intermediate solution that shall work
> > > > for your proxies.
> > > > If it is not possible to create a shadow fact for a class that
> > > > is asserted (because the class is final or whatever), the engine goes
up in
> > > > the class hierarchy, looking for a class or interface for which is
possible
> > > > to create the proxy, but that still matches all ObjectTypes available
in the
> > > > rule base matched by the original class. The analysis is a bit
complex,
> > > > specially because new rules with new object types can be dynamically
added
> > > > to the rule base, but I believe the solution will work for JDK
proxies and
> > > > the most common proxy frameworks out there, that usually don't
proxy
> > > > multiple unrelated interfaces at once.
> > > >
> > > > So, I ask you please to get latest snapshot from the repository
> > > > and try it out for your use case and report back to the list the
results,
> > > > since seems there are a few other people using similar things.
> > > >
> > > > Thanks,
> > > > Edson
> > > >
> > > >
> > > > 2007/7/17, Chris West < crayzfishr(a)gmail.com>:
> > > > >
> > > > > Is that still true if the equals() and hashcode() methods are
> > > > > only based on the identity fields of the object (which cannot
change)?
> > > > >
> > > > > -Chris West
> > > > >
> > > > > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
> > > > > >
> > > > > > you only need to use modifyRetract if the object is
inserted.
> > > > > > The reason for this is if you change field values on your
facts we will not
> > > > > > be able to remove them from our various internal hashmaps;
thus the need to
> > > > > > remove first prior to any changes, then make the changes
and then insert it
> > > > > > again. We can't allow users to just call update() as we
have no idea what
> > > > > > the old values where, thus we cannot find the objects in
our hashmaps.
> > > > > >
> > > > > > Mark
> > > > > > Chris West wrote:
> > > > > >
> > > > > > Mark,
> > > > > >
> > > > > > Using modifyRetract and modifyInsert seems to fix the
problem
> > > > > > (at least in my test case I finally created). I'll try
this on my real
> > > > > > code.
> > > > > >
> > > > > > My only concern here is that it puts the burden on the
rule
> > > > > > author to know whether things are being shadowed or not.
For shadowing that
> > > > > > is explicitly turned off this is ok. But for implicit
non-shadowing based
> > > > > > on a class being final, this is not at all obvious to the
rule auther.
> > > > > >
> > > > > > Is there any way to have this hidden such that I can still
> > > > > > call "update" but have it use
"modifyRetract" and "modifyInsert" instead?
> > > > > >
> > > > > > Also, I'm curious why I have to call modifyRetract
before I
> > > > > > start modifing the object, since the engine does not know
about my
> > > > > > modifications anyway until I call update or modifyInsert?
By the way, I was
> > > > > > unable to use the block setter approach in the rule
consequence due to not
> > > > > > having set methods for modifying my objects.
> > > > > >
> > > > > > Thanks,
> > > > > > -Chris West
> > > > > >
> > > > > > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org >
wrote:
> > > > > > >
> > > > > > > If you do not have shadow facts you cannot use the
update()
> > > > > > > method, it will leave the working memory corrupted.
Instead you must manage
> > > > > > > this yourself, before you change any values on the
object you must call
> > > > > > > modifyRetract() and after you hvae finished your
changes ot hte object call
> > > > > > > modifyInsert() - luckily if you are doing this in the
consequence you can
> > > > > > > use the MVEL modify keyword combined with the block
setter and it does this
> > > > > > > for you:
> > > > > > > modify ( person ) { age += 1, location =
"london" }
> > > > > > >
> > > > > > > Mark
> > > > > > > Chris West wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > With prior versions of JBoss Rules (3.0.5) I have been
using
> > > > > > > JDK generated dynamic proxies as facts, and they have
been working fine.
> > > > > > > However, after upgrading to JBoss Rules 4.0.0MR3, I
cannot
> > > > > > > seem to get the dynamic proxies to work as facts. It
seems that even though
> > > > > > > a rule fires that changes a field on the proxy, a
second rule that should
> > > > > > > not be activated after the update still fires.
> > > > > > >
> > > > > > > According to the JDK javadoc documentation, dynamic
proxies
> > > > > > > are created as final. My assumption is that JBoss
Rules is not creating
> > > > > > > Shadow facts for these since they are final. After
reading the JIRA at
> > > > > > > http://jira.jboss.com/jira/browse/JBRULES-960, I now
am
> > > > > > > questioning what the effect of not using shadow facts
is on the engine. The
> > > > > > > relevant part of that is:
> > > > > > >
> > > > > > > "The problem is that SpringAOP is generating a
proxy whose
> > > > > > > methods equals() and hashCode() are "final".
As drools must either override
> > > > > > > these methods in the shadow proxy or not shadow the
fact at all, I'm
> > > > > > > disabling shadow proxy generation for this use case.
> > > > > > > It is really important to note that if you are
asserting
> > > > > > > SpringAOP proxies as facts into the working memory,
you will not be able to
> > > > > > > change any field value whose field is constrained in
rules or you may incur
> > > > > > > in a memory leak and non-deterministic behavior by the
rules engine.
> > > > > > > Unfortunately there is nothing we can do about, since
when SpringAOP makes
> > > > > > > the methods equals and hashcode final, we can't
override them anymore and as
> > > > > > > so, we can't shadow them."
> > > > > > > [ Show »
<http://jira.jboss.com/jira/browse/JBRULES-960> ]
> > > > > > >
> > > > > > > Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> > > > > > > [02/Jul/07 03:29 PM] The problem is that SpringAOP is
> > > > > > > generating a proxy whose methods equals() and
hashCode() are "final". As
> > > > > > > drools must either override these methods in the
shadow proxy or not shadow
> > > > > > > the fact at all, I'm disabling shadow proxy
generation for this use case. It
> > > > > > > is really important to note that if you are asserting
SpringAOP proxies as
> > > > > > > facts into the working memory, you will not be able to
change any field
> > > > > > > value whose field is constrained in rules or you may
incur in a memory leak
> > > > > > > and non-deterministic behavior by the rules engine.
Unfortunately there is
> > > > > > > nothing we can do about, since when SpringAOP makes
the methods equals and
> > > > > > > hashcode final, we can't override them anymore and
as so, we can't shadow
> > > > > > > them.
> > > > > > >
> > > > > > > Although I'm not using SpringAOP, I believe my
facts are not
> > > > > > > being shadowed.
> > > > > > >
> > > > > > > Is it true that not using shadow facts may lead to
> > > > > > > non-deterministic behavior? Prior to shadow facts,
the engine seemed to
> > > > > > > handle it. Any chance of reverting back to the old
style of truth
> > > > > > > maintenance in the case of not using shadow facts.
> > > > > > >
> > > > > > > I apologize if I'm not on the right track here.
My only
> > > > > > > test case for my problem is the entire application
right now, so I cannot
> > > > > > > offer it for discussion. Any advice would be greatly
appreciated.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > -Chris West
> > > > > > >
> > > > > > > ------------------------------
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > rules-users mailing list
> > > > > > > rules-users(a)lists.jboss.org
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > rules-users mailing list
> > > > > > > rules-users(a)lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > >
> > > > > > >
> > > > > > ------------------------------
> > > > > >
> > > > > > _______________________________________________
> > > > > > rules-users mailing list
> > > > > > rules-users(a)lists.jboss.org
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > rules-users mailing list
> > > > > > rules-users(a)lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users(a)lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Edson Tirelli
> > > > Software Engineer - JBoss Rules Core Developer
> > > > Office: +55 11 3529-6000
> > > > Mobile: +55 11 9287-5646
> > > > JBoss, a division of Red Hat @ www.jboss.com
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> >
> >
> > --
> > Edson Tirelli
> > Software Engineer - JBoss Rules Core Developer
> > Office: +55 11 3529-6000
> > Mobile: +55 11 9287-5646
> > JBoss, a division of Red Hat @ www.jboss.com
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
12:28 p.m.
Chris,
Right on the spot. I changed other references, but this one passed
unnoticed. The correct is:
Class cls = null;
if ( object instanceof ShadowProxy ) {
cls = ((ShadowProxy)object).getShadowedObject().getClass();
} else {
cls = object.getClass();
}
I made a text search this time and found no other occurence of this
problem.
I commited the fix in revision #13637. Take a look and let me know if you
still has problems.
Thank you a lot,
Edson
2007/7/19, Chris West <crayzfishr(a)gmail.com>:
Edson,
I think I've discovered the problem. In the file Rete.java, in the method
"assertObject", there is a check for shadow proxy like below:
Class cls = object.getClass();
if ( object instanceof ShadowProxy ) {
cls = cls.getSuperclass();
}
If the class being proxied was final, and your new logic chose an
interface of that class to build a proxy from, then the superclass is
Object.class.
This leads to an incorrect selection of cachedNodes further down in the
method.
I've traced this through the debugger with my object types, and it does
show that a node for a SortieStatus is being given an object of type
LaunchRecoveryStatusShadowProxy, which is not compatible.
Perhaps theres a different way to determine the type of object such that
type LaunchRecoveryStatusShadowProxy will return LaunchRecoveryStatus rather
than Object.
Please take a look and let me know if I need to provide more info.
Thanks,
-Chris West
On 7/18/07, Edson Tirelli <tirelli(a)post.com> wrote:
>
>
> Chris,
>
> What seems to be happening us that your SortieStatus interface has a
> state attribute. Drools is trying to read this attribute value and cast it
> to LaunchRecoveryStatusShadowProxy what is causing the problems...
> Best way to solve would be to have the code so I can debug. Is it
> possible to isolate it and send me?
>
> []s
> Edson
>
>
>
> 2007/7/18, Chris West < crayzfishr(a)gmail.com>:
> >
> > Edson,
> >
> > It is certainly possible to create a JDK proxy with only some of the
> > interfaces that are present on the delegate object that you are proxying,
> > but in my case, my proxies have all the interfaces of the underlying object.
> >
> >
> > The top two lines of the call stack I sent shows the following:
> >
> > Exception in thread "main" java.lang.ClassCastException:
> > ascc.status.FlightOpsStatusBoard$LaunchRecoveryStatusShadowProxy
> > at
> >
org.drools.base.ascc.status.AirPlanStatusBoard$SortieStatus$getState.getValue(Unknown
> > Source)
> >
> > What's strange here is that the ClassCastException seems to be caused
> > by casting an object of type SortieStatus to type
> > LaunchRecoveryStatusShadowProxy, if I'm reading that right. The types
> > SortieStatus and LaunchRecoveryStatus are both interfaces in my code, and
> > they never appear on the same fact object (so no SortieStatus will ever be a
> > LaunchRecoveryStatus and vice-versa). So I'm wondering why the cast is
> > occuring, since it is not possible to work.
> >
> > The unfortunate part is I cannot see into the class where the cast is
> > occurring, as it is a generated class created by drools.
> >
> > -Chris West
> >
> > On 7/18/07, Edson Tirelli <tirelli(a)post.com> wrote:
> > >
> > >
> > > Chris,
> > >
> > > For the solution to work, it is important that a superclass or
> > > interface matches all the ObjectTypes in your rulebase that your final
class
> > > (proxy) matches... I guess that is the case with JDK proxies, isn't
it?
> > >
> > > []s
> > > Edson
> > >
> > > 2007/7/18, Chris West <crayzfishr(a)gmail.com >:
> > > >
> > > > Edson,
> > > >
> > > > I downloaded and built the latest from the trunk of the
> > > > repository. I applied this new build toward my test case, and it
seemed to
> > > > fix the problem. However, when I applied it to my real project, it
still
> > > > exhibits the problem. If I discover more information about the
problem I'll
> > > > let you know.
> > > >
> > > > Thanks,
> > > > Chris West
> > > >
> > > > On 7/17/07, Edson Tirelli < tirelli(a)post.com> wrote:
> > > > >
> > > > >
> > > > > Chris,
> > > > >
> > > > > I found and developed an intermediate solution that shall
> > > > > work for your proxies.
> > > > > If it is not possible to create a shadow fact for a class
> > > > > that is asserted (because the class is final or whatever), the
engine goes
> > > > > up in the class hierarchy, looking for a class or interface for
which is
> > > > > possible to create the proxy, but that still matches all
ObjectTypes
> > > > > available in the rule base matched by the original class. The
analysis is a
> > > > > bit complex, specially because new rules with new object types
can be
> > > > > dynamically added to the rule base, but I believe the solution
will work for
> > > > > JDK proxies and the most common proxy frameworks out there, that
usually
> > > > > don't proxy multiple unrelated interfaces at once.
> > > > >
> > > > > So, I ask you please to get latest snapshot from the
> > > > > repository and try it out for your use case and report back to
the list the
> > > > > results, since seems there are a few other people using similar
things.
> > > > >
> > > > > Thanks,
> > > > > Edson
> > > > >
> > > > >
> > > > > 2007/7/17, Chris West < crayzfishr(a)gmail.com>:
> > > > > >
> > > > > > Is that still true if the equals() and hashcode() methods
are
> > > > > > only based on the identity fields of the object (which
cannot change)?
> > > > > >
> > > > > > -Chris West
> > > > > >
> > > > > > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org>
wrote:
> > > > > > >
> > > > > > > you only need to use modifyRetract if the object is
> > > > > > > inserted. The reason for this is if you change field
values on your facts we
> > > > > > > will not be able to remove them from our various
internal hashmaps; thus the
> > > > > > > need to remove first prior to any changes, then make
the changes and then
> > > > > > > insert it again. We can't allow users to just call
update() as we have no
> > > > > > > idea what the old values where, thus we cannot find
the objects in our
> > > > > > > hashmaps.
> > > > > > >
> > > > > > > Mark
> > > > > > > Chris West wrote:
> > > > > > >
> > > > > > > Mark,
> > > > > > >
> > > > > > > Using modifyRetract and modifyInsert seems to fix the
> > > > > > > problem (at least in my test case I finally created).
I'll try this on my
> > > > > > > real code.
> > > > > > >
> > > > > > > My only concern here is that it puts the burden on the
rule
> > > > > > > author to know whether things are being shadowed or
not. For shadowing that
> > > > > > > is explicitly turned off this is ok. But for implicit
non-shadowing based
> > > > > > > on a class being final, this is not at all obvious to
the rule auther.
> > > > > > >
> > > > > > > Is there any way to have this hidden such that I can
still
> > > > > > > call "update" but have it use
"modifyRetract" and "modifyInsert" instead?
> > > > > > >
> > > > > > > Also, I'm curious why I have to call modifyRetract
before I
> > > > > > > start modifing the object, since the engine does not
know about my
> > > > > > > modifications anyway until I call update or
modifyInsert? By the way, I was
> > > > > > > unable to use the block setter approach in the rule
consequence due to not
> > > > > > > having set methods for modifying my objects.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > -Chris West
> > > > > > >
> > > > > > > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org
> wrote:
> > > > > > > >
> > > > > > > > If you do not have shadow facts you cannot use
the
> > > > > > > > update() method, it will leave the working memory
corrupted. Instead you
> > > > > > > > must manage this yourself, before you change any
values on the object you
> > > > > > > > must call modifyRetract() and after you hvae
finished your changes ot hte
> > > > > > > > object call modifyInsert() - luckily if you are
doing this in the
> > > > > > > > consequence you can use the MVEL modify keyword
combined with the block
> > > > > > > > setter and it does this for you:
> > > > > > > > modify ( person ) { age += 1, location =
"london" }
> > > > > > > >
> > > > > > > > Mark
> > > > > > > > Chris West wrote:
> > > > > > > >
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > With prior versions of JBoss Rules (3.0.5) I have
been
> > > > > > > > using JDK generated dynamic proxies as facts, and
they have been working
> > > > > > > > fine. However, after upgrading to JBoss Rules
4.0.0MR3, I
> > > > > > > > cannot seem to get the dynamic proxies to work as
facts. It seems that even
> > > > > > > > though a rule fires that changes a field on the
proxy, a second rule that
> > > > > > > > should not be activated after the update still
fires.
> > > > > > > >
> > > > > > > > According to the JDK javadoc documentation,
dynamic
> > > > > > > > proxies are created as final. My assumption is
that JBoss Rules is not
> > > > > > > > creating Shadow facts for these since they are
final. After reading the
> > > > > > > > JIRA at
http://jira.jboss.com/jira/browse/JBRULES-960, I
> > > > > > > > now am questioning what the effect of not using
shadow facts is on the
> > > > > > > > engine. The relevant part of that is:
> > > > > > > >
> > > > > > > > "The problem is that SpringAOP is generating
a proxy whose
> > > > > > > > methods equals() and hashCode() are
"final". As drools must either override
> > > > > > > > these methods in the shadow proxy or not shadow
the fact at all, I'm
> > > > > > > > disabling shadow proxy generation for this use
case.
> > > > > > > > It is really important to note that if you are
asserting
> > > > > > > > SpringAOP proxies as facts into the working
memory, you will not be able to
> > > > > > > > change any field value whose field is constrained
in rules or you may incur
> > > > > > > > in a memory leak and non-deterministic behavior
by the rules engine.
> > > > > > > > Unfortunately there is nothing we can do about,
since when SpringAOP makes
> > > > > > > > the methods equals and hashcode final, we
can't override them anymore and as
> > > > > > > > so, we can't shadow them."
> > > > > > > > [ Show »
<http://jira.jboss.com/jira/browse/JBRULES-960>]
> > > > > > > > Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> > > > > > > > [02/Jul/07 03:29 PM] The problem is that
SpringAOP is
> > > > > > > > generating a proxy whose methods equals() and
hashCode() are "final". As
> > > > > > > > drools must either override these methods in the
shadow proxy or not shadow
> > > > > > > > the fact at all, I'm disabling shadow proxy
generation for this use case. It
> > > > > > > > is really important to note that if you are
asserting SpringAOP proxies as
> > > > > > > > facts into the working memory, you will not be
able to change any field
> > > > > > > > value whose field is constrained in rules or you
may incur in a memory leak
> > > > > > > > and non-deterministic behavior by the rules
engine. Unfortunately there is
> > > > > > > > nothing we can do about, since when SpringAOP
makes the methods equals and
> > > > > > > > hashcode final, we can't override them
anymore and as so, we can't shadow
> > > > > > > > them.
> > > > > > > >
> > > > > > > > Although I'm not using SpringAOP, I believe
my facts are
> > > > > > > > not being shadowed.
> > > > > > > >
> > > > > > > > Is it true that not using shadow facts may lead
to
> > > > > > > > non-deterministic behavior? Prior to shadow
facts, the engine seemed to
> > > > > > > > handle it. Any chance of reverting back to the
old style of truth
> > > > > > > > maintenance in the case of not using shadow
facts.
> > > > > > > >
> > > > > > > > I apologize if I'm not on the right track
here. My only
> > > > > > > > test case for my problem is the entire
application right now, so I cannot
> > > > > > > > offer it for discussion. Any advice would be
greatly appreciated.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > -Chris West
> > > > > > > >
> > > > > > > > ------------------------------
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > rules-users mailing list
> > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > rules-users mailing list
> > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > >
> > > > > > > >
> > > > > > > ------------------------------
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > rules-users mailing list
> > > > > > > rules-users(a)lists.jboss.org
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > rules-users mailing list
> > > > > > > rules-users(a)lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > rules-users mailing list
> > > > > > rules-users(a)lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Edson Tirelli
> > > > > Software Engineer - JBoss Rules Core Developer
> > > > > Office: +55 11 3529-6000
> > > > > Mobile: +55 11 9287-5646
> > > > > JBoss, a division of Red Hat @ www.jboss.com
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users(a)lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > >
> > >
> > > --
> > > Edson Tirelli
> > > Software Engineer - JBoss Rules Core Developer
> > > Office: +55 11 3529-6000
> > > Mobile: +55 11 9287-5646
> > > JBoss, a division of Red Hat @ www.jboss.com
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
>
> --
> Edson Tirelli
> Software Engineer - JBoss Rules Core Developer
> Office: +55 11 3529-6000
> Mobile: +55 11 9287-5646
> JBoss, a division of Red Hat @ www.jboss.com
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
1:01 p.m.
Edson,
Thanks for incorporating this fix. The good news is that it fixes that
problem.
The bad news for me is that I'm now experiencing a different problem (where
my rules are not firing). I'll look into my new problem a little deeper.
Thanks again.
-Chris West
On 7/19/07, Edson Tirelli <tirelli(a)post.com> wrote:
Chris,
Right on the spot. I changed other references, but this one passed
unnoticed. The correct is:
Class cls = null;
if ( object instanceof ShadowProxy ) {
cls =
((ShadowProxy)object).getShadowedObject().getClass();
} else {
cls = object.getClass();
}
I made a text search this time and found no other occurence of this
problem.
I commited the fix in revision #13637. Take a look and let me know if
you still has problems.
Thank you a lot,
Edson
2007/7/19, Chris West < crayzfishr(a)gmail.com>:
>
> Edson,
>
> I think I've discovered the problem. In the file Rete.java, in the
> method "assertObject", there is a check for shadow proxy like below:
>
> Class cls = object.getClass();
> if ( object instanceof ShadowProxy ) {
> cls = cls.getSuperclass();
> }
>
> If the class being proxied was final, and your new logic chose an
> interface of that class to build a proxy from, then the superclass is
> Object.class.
>
> This leads to an incorrect selection of cachedNodes further down in the
> method.
>
> I've traced this through the debugger with my object types, and it does
> show that a node for a SortieStatus is being given an object of type
> LaunchRecoveryStatusShadowProxy, which is not compatible.
>
> Perhaps theres a different way to determine the type of object such that
> type LaunchRecoveryStatusShadowProxy will return LaunchRecoveryStatus rather
> than Object.
>
> Please take a look and let me know if I need to provide more info.
>
> Thanks,
> -Chris West
>
> On 7/18/07, Edson Tirelli < tirelli(a)post.com> wrote:
> >
> >
> > Chris,
> >
> > What seems to be happening us that your SortieStatus interface has
> > a state attribute. Drools is trying to read this attribute value and cast it
> > to LaunchRecoveryStatusShadowProxy what is causing the problems...
> > Best way to solve would be to have the code so I can debug. Is it
> > possible to isolate it and send me?
> >
> > []s
> > Edson
> >
> >
> >
> > 2007/7/18, Chris West < crayzfishr(a)gmail.com>:
> > >
> > > Edson,
> > >
> > > It is certainly possible to create a JDK proxy with only some of the
> > > interfaces that are present on the delegate object that you are proxying,
> > > but in my case, my proxies have all the interfaces of the underlying
object.
> > >
> > >
> > > The top two lines of the call stack I sent shows the following:
> > >
> > > Exception in thread "main" java.lang.ClassCastException:
> > > ascc.status.FlightOpsStatusBoard$LaunchRecoveryStatusShadowProxy
> > > at
> > >
org.drools.base.ascc.status.AirPlanStatusBoard$SortieStatus$getState.getValue(Unknown
> > > Source)
> > >
> > > What's strange here is that the ClassCastException seems to be
> > > caused by casting an object of type SortieStatus to type
> > > LaunchRecoveryStatusShadowProxy, if I'm reading that right. The
types
> > > SortieStatus and LaunchRecoveryStatus are both interfaces in my code, and
> > > they never appear on the same fact object (so no SortieStatus will ever be
a
> > > LaunchRecoveryStatus and vice-versa). So I'm wondering why the cast
is
> > > occuring, since it is not possible to work.
> > >
> > > The unfortunate part is I cannot see into the class where the cast
> > > is occurring, as it is a generated class created by drools.
> > >
> > > -Chris West
> > >
> > > On 7/18/07, Edson Tirelli <tirelli(a)post.com> wrote:
> > > >
> > > >
> > > > Chris,
> > > >
> > > > For the solution to work, it is important that a superclass or
> > > > interface matches all the ObjectTypes in your rulebase that your
final class
> > > > (proxy) matches... I guess that is the case with JDK proxies,
isn't it?
> > > >
> > > > []s
> > > > Edson
> > > >
> > > > 2007/7/18, Chris West <crayzfishr(a)gmail.com >:
> > > > >
> > > > > Edson,
> > > > >
> > > > > I downloaded and built the latest from the trunk of the
> > > > > repository. I applied this new build toward my test case, and
it seemed to
> > > > > fix the problem. However, when I applied it to my real project,
it still
> > > > > exhibits the problem. If I discover more information about the
problem I'll
> > > > > let you know.
> > > > >
> > > > > Thanks,
> > > > > Chris West
> > > > >
> > > > > On 7/17/07, Edson Tirelli < tirelli(a)post.com> wrote:
> > > > > >
> > > > > >
> > > > > > Chris,
> > > > > >
> > > > > > I found and developed an intermediate solution that
shall
> > > > > > work for your proxies.
> > > > > > If it is not possible to create a shadow fact for a
class
> > > > > > that is asserted (because the class is final or whatever),
the engine goes
> > > > > > up in the class hierarchy, looking for a class or interface
for which is
> > > > > > possible to create the proxy, but that still matches all
ObjectTypes
> > > > > > available in the rule base matched by the original class.
The analysis is a
> > > > > > bit complex, specially because new rules with new object
types can be
> > > > > > dynamically added to the rule base, but I believe the
solution will work for
> > > > > > JDK proxies and the most common proxy frameworks out there,
that usually
> > > > > > don't proxy multiple unrelated interfaces at once.
> > > > > >
> > > > > > So, I ask you please to get latest snapshot from the
> > > > > > repository and try it out for your use case and report back
to the list the
> > > > > > results, since seems there are a few other people using
similar things.
> > > > > >
> > > > > > Thanks,
> > > > > > Edson
> > > > > >
> > > > > >
> > > > > > 2007/7/17, Chris West < crayzfishr(a)gmail.com>:
> > > > > > >
> > > > > > > Is that still true if the equals() and hashcode()
methods
> > > > > > > are only based on the identity fields of the object
(which cannot change)?
> > > > > > >
> > > > > > > -Chris West
> > > > > > >
> > > > > > > On 7/17/07, Mark Proctor <mproctor(a)codehaus.org>
wrote:
> > > > > > > >
> > > > > > > > you only need to use modifyRetract if the object
is
> > > > > > > > inserted. The reason for this is if you change
field values on your facts we
> > > > > > > > will not be able to remove them from our various
internal hashmaps; thus the
> > > > > > > > need to remove first prior to any changes, then
make the changes and then
> > > > > > > > insert it again. We can't allow users to just
call update() as we have no
> > > > > > > > idea what the old values where, thus we cannot
find the objects in our
> > > > > > > > hashmaps.
> > > > > > > >
> > > > > > > > Mark
> > > > > > > > Chris West wrote:
> > > > > > > >
> > > > > > > > Mark,
> > > > > > > >
> > > > > > > > Using modifyRetract and modifyInsert seems to fix
the
> > > > > > > > problem (at least in my test case I finally
created). I'll try this on my
> > > > > > > > real code.
> > > > > > > >
> > > > > > > > My only concern here is that it puts the burden
on the
> > > > > > > > rule author to know whether things are being
shadowed or not. For shadowing
> > > > > > > > that is explicitly turned off this is ok. But
for implicit non-shadowing
> > > > > > > > based on a class being final, this is not at all
obvious to the rule auther.
> > > > > > > >
> > > > > > > >
> > > > > > > > Is there any way to have this hidden such that I
can still
> > > > > > > > call "update" but have it use
"modifyRetract" and "modifyInsert" instead?
> > > > > > > >
> > > > > > > > Also, I'm curious why I have to call
modifyRetract before
> > > > > > > > I start modifing the object, since the engine
does not know about my
> > > > > > > > modifications anyway until I call update or
modifyInsert? By the way, I was
> > > > > > > > unable to use the block setter approach in the
rule consequence due to not
> > > > > > > > having set methods for modifying my objects.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > -Chris West
> > > > > > > >
> > > > > > > > On 7/17/07, Mark Proctor
<mproctor(a)codehaus.org > wrote:
> > > > > > > > >
> > > > > > > > > If you do not have shadow facts you cannot
use the
> > > > > > > > > update() method, it will leave the working
memory corrupted. Instead you
> > > > > > > > > must manage this yourself, before you change
any values on the object you
> > > > > > > > > must call modifyRetract() and after you hvae
finished your changes ot hte
> > > > > > > > > object call modifyInsert() - luckily if you
are doing this in the
> > > > > > > > > consequence you can use the MVEL modify
keyword combined with the block
> > > > > > > > > setter and it does this for you:
> > > > > > > > > modify ( person ) { age += 1, location =
"london" }
> > > > > > > > >
> > > > > > > > > Mark
> > > > > > > > > Chris West wrote:
> > > > > > > > >
> > > > > > > > > Hello,
> > > > > > > > >
> > > > > > > > > With prior versions of JBoss Rules (3.0.5) I
have been
> > > > > > > > > using JDK generated dynamic proxies as
facts, and they have been working
> > > > > > > > > fine. However, after upgrading to JBoss
Rules 4.0.0MR3,
> > > > > > > > > I cannot seem to get the dynamic proxies to
work as facts. It seems that
> > > > > > > > > even though a rule fires that changes a
field on the proxy, a second rule
> > > > > > > > > that should not be activated after the
update still fires.
> > > > > > > > >
> > > > > > > > > According to the JDK javadoc documentation,
dynamic
> > > > > > > > > proxies are created as final. My assumption
is that JBoss Rules is not
> > > > > > > > > creating Shadow facts for these since they
are final. After reading the
> > > > > > > > > JIRA at
http://jira.jboss.com/jira/browse/JBRULES-960, I
> > > > > > > > > now am questioning what the effect of not
using shadow facts is on the
> > > > > > > > > engine. The relevant part of that is:
> > > > > > > > >
> > > > > > > > > "The problem is that SpringAOP is
generating a proxy
> > > > > > > > > whose methods equals() and hashCode() are
"final". As drools must either
> > > > > > > > > override these methods in the shadow proxy
or not shadow the fact at all,
> > > > > > > > > I'm disabling shadow proxy generation
for this use case.
> > > > > > > > > It is really important to note that if you
are asserting
> > > > > > > > > SpringAOP proxies as facts into the working
memory, you will not be able to
> > > > > > > > > change any field value whose field is
constrained in rules or you may incur
> > > > > > > > > in a memory leak and non-deterministic
behavior by the rules engine.
> > > > > > > > > Unfortunately there is nothing we can do
about, since when SpringAOP makes
> > > > > > > > > the methods equals and hashcode final, we
can't override them anymore and as
> > > > > > > > > so, we can't shadow them."
> > > > > > > > > [ Show
»<http://jira.jboss.com/jira/browse/JBRULES-960>]
> > > > > > > > > Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> > > > > > > > > [02/Jul/07 03:29 PM] The problem is that
SpringAOP is
> > > > > > > > > generating a proxy whose methods equals()
and hashCode() are "final". As
> > > > > > > > > drools must either override these methods in
the shadow proxy or not shadow
> > > > > > > > > the fact at all, I'm disabling shadow
proxy generation for this use case. It
> > > > > > > > > is really important to note that if you are
asserting SpringAOP proxies as
> > > > > > > > > facts into the working memory, you will not
be able to change any field
> > > > > > > > > value whose field is constrained in rules or
you may incur in a memory leak
> > > > > > > > > and non-deterministic behavior by the rules
engine. Unfortunately there is
> > > > > > > > > nothing we can do about, since when
SpringAOP makes the methods equals and
> > > > > > > > > hashcode final, we can't override them
anymore and as so, we can't shadow
> > > > > > > > > them.
> > > > > > > > >
> > > > > > > > > Although I'm not using SpringAOP, I
believe my facts are
> > > > > > > > > not being shadowed.
> > > > > > > > >
> > > > > > > > > Is it true that not using shadow facts may
lead to
> > > > > > > > > non-deterministic behavior? Prior to shadow
facts, the engine seemed to
> > > > > > > > > handle it. Any chance of reverting back to
the old style of truth
> > > > > > > > > maintenance in the case of not using shadow
facts.
> > > > > > > > >
> > > > > > > > > I apologize if I'm not on the right
track here. My only
> > > > > > > > > test case for my problem is the entire
application right now, so I cannot
> > > > > > > > > offer it for discussion. Any advice would
be greatly appreciated.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > -Chris West
> > > > > > > > >
> > > > > > > > > ------------------------------
> > > > > > > > >
> > > > > > > > >
_______________________________________________
> > > > > > > > > rules-users mailing list
> > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
_______________________________________________
> > > > > > > > > rules-users mailing list
> > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > >
> > > > > > > > >
> > > > > > > > ------------------------------
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > rules-users mailing list
> > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > rules-users mailing list
> > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > rules-users mailing list
> > > > > > > rules-users(a)lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Edson Tirelli
> > > > > > Software Engineer - JBoss Rules Core Developer
> > > > > > Office: +55 11 3529-6000
> > > > > > Mobile: +55 11 9287-5646
> > > > > > JBoss, a division of Red Hat @ www.jboss.com
> > > > > >
> > > > > > _______________________________________________
> > > > > > rules-users mailing list
> > > > > > rules-users(a)lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users(a)lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Edson Tirelli
> > > > Software Engineer - JBoss Rules Core Developer
> > > > Office: +55 11 3529-6000
> > > > Mobile: +55 11 9287-5646
> > > > JBoss, a division of Red Hat @ www.jboss.com
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> >
> >
> > --
> > Edson Tirelli
> > Software Engineer - JBoss Rules Core Developer
> > Office: +55 11 3529-6000
> > Mobile: +55 11 9287-5646
> > JBoss, a division of Red Hat @ www.jboss.com
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
1:21 p.m.
Ouch!
Is all that trouble a result of using JDK proxies in drools? If it is, I
think it is the case of us developing a whole set of unit and integration
tests for this specific scenario, since none of our tests are triggering
errors...
Thanks and please keep me posted of your progress or any problems you
find.
[]s
Edson
2007/7/19, Chris West <crayzfishr(a)gmail.com>:
Edson,
Thanks for incorporating this fix. The good news is that it fixes that
problem.
The bad news for me is that I'm now experiencing a different problem
(where my rules are not firing). I'll look into my new problem a little
deeper.
Thanks again.
-Chris West
On 7/19/07, Edson Tirelli <tirelli(a)post.com> wrote:
>
>
> Chris,
>
> Right on the spot. I changed other references, but this one passed
> unnoticed. The correct is:
>
> Class cls = null;
> if ( object instanceof ShadowProxy ) {
> cls =
> ((ShadowProxy)object).getShadowedObject().getClass();
> } else {
> cls = object.getClass();
> }
>
> I made a text search this time and found no other occurence of this
> problem.
> I commited the fix in revision #13637. Take a look and let me know if
> you still has problems.
>
> Thank you a lot,
> Edson
>
> 2007/7/19, Chris West < crayzfishr(a)gmail.com>:
> >
> > Edson,
> >
> > I think I've discovered the problem. In the file Rete.java, in the
> > method "assertObject", there is a check for shadow proxy like below:
> >
> > Class cls = object.getClass();
> > if ( object instanceof ShadowProxy ) {
> > cls = cls.getSuperclass();
> > }
> >
> > If the class being proxied was final, and your new logic chose an
> > interface of that class to build a proxy from, then the superclass is
> > Object.class.
> >
> > This leads to an incorrect selection of cachedNodes further down in
> > the method.
> >
> > I've traced this through the debugger with my object types, and it
> > does show that a node for a SortieStatus is being given an object of type
> > LaunchRecoveryStatusShadowProxy, which is not compatible.
> >
> > Perhaps theres a different way to determine the type of object such
> > that type LaunchRecoveryStatusShadowProxy will return LaunchRecoveryStatus
> > rather than Object.
> >
> > Please take a look and let me know if I need to provide more info.
> >
> > Thanks,
> > -Chris West
> >
> > On 7/18/07, Edson Tirelli < tirelli(a)post.com> wrote:
> > >
> > >
> > > Chris,
> > >
> > > What seems to be happening us that your SortieStatus interface
> > > has a state attribute. Drools is trying to read this attribute value and
> > > cast it to LaunchRecoveryStatusShadowProxy what is causing the
> > > problems...
> > > Best way to solve would be to have the code so I can debug. Is
> > > it possible to isolate it and send me?
> > >
> > > []s
> > > Edson
> > >
> > >
> > >
> > > 2007/7/18, Chris West < crayzfishr(a)gmail.com>:
> > > >
> > > > Edson,
> > > >
> > > > It is certainly possible to create a JDK proxy with only some of
> > > > the interfaces that are present on the delegate object that you are
> > > > proxying, but in my case, my proxies have all the interfaces of the
> > > > underlying object.
> > > >
> > > > The top two lines of the call stack I sent shows the following:
> > > >
> > > > Exception in thread "main" java.lang.ClassCastException:
> > > > ascc.status.FlightOpsStatusBoard$LaunchRecoveryStatusShadowProxy
> > > > at
> > > >
org.drools.base.ascc.status.AirPlanStatusBoard$SortieStatus$getState.getValue(Unknown
> > > > Source)
> > > >
> > > > What's strange here is that the ClassCastException seems to be
> > > > caused by casting an object of type SortieStatus to type
> > > > LaunchRecoveryStatusShadowProxy, if I'm reading that right. The
types
> > > > SortieStatus and LaunchRecoveryStatus are both interfaces in my code,
and
> > > > they never appear on the same fact object (so no SortieStatus will
ever be a
> > > > LaunchRecoveryStatus and vice-versa). So I'm wondering why the
cast is
> > > > occuring, since it is not possible to work.
> > > >
> > > > The unfortunate part is I cannot see into the class where the cast
> > > > is occurring, as it is a generated class created by drools.
> > > >
> > > > -Chris West
> > > >
> > > > On 7/18/07, Edson Tirelli <tirelli(a)post.com> wrote:
> > > > >
> > > > >
> > > > > Chris,
> > > > >
> > > > > For the solution to work, it is important that a superclass
> > > > > or interface matches all the ObjectTypes in your rulebase that
your final
> > > > > class (proxy) matches... I guess that is the case with JDK
proxies, isn't
> > > > > it?
> > > > >
> > > > > []s
> > > > > Edson
> > > > >
> > > > > 2007/7/18, Chris West <crayzfishr(a)gmail.com >:
> > > > > >
> > > > > > Edson,
> > > > > >
> > > > > > I downloaded and built the latest from the trunk of the
> > > > > > repository. I applied this new build toward my test case,
and it seemed to
> > > > > > fix the problem. However, when I applied it to my real
project, it still
> > > > > > exhibits the problem. If I discover more information about
the problem I'll
> > > > > > let you know.
> > > > > >
> > > > > > Thanks,
> > > > > > Chris West
> > > > > >
> > > > > > On 7/17/07, Edson Tirelli < tirelli(a)post.com> wrote:
> > > > > > >
> > > > > > >
> > > > > > > Chris,
> > > > > > >
> > > > > > > I found and developed an intermediate solution that
shall
> > > > > > > work for your proxies.
> > > > > > > If it is not possible to create a shadow fact for a
class
> > > > > > > that is asserted (because the class is final or
whatever), the engine goes
> > > > > > > up in the class hierarchy, looking for a class or
interface for which is
> > > > > > > possible to create the proxy, but that still matches
all ObjectTypes
> > > > > > > available in the rule base matched by the original
class. The analysis is a
> > > > > > > bit complex, specially because new rules with new
object types can be
> > > > > > > dynamically added to the rule base, but I believe the
solution will work for
> > > > > > > JDK proxies and the most common proxy frameworks out
there, that usually
> > > > > > > don't proxy multiple unrelated interfaces at
once.
> > > > > > >
> > > > > > > So, I ask you please to get latest snapshot from
the
> > > > > > > repository and try it out for your use case and report
back to the list the
> > > > > > > results, since seems there are a few other people
using similar things.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Edson
> > > > > > >
> > > > > > >
> > > > > > > 2007/7/17, Chris West < crayzfishr(a)gmail.com>:
> > > > > > > >
> > > > > > > > Is that still true if the equals() and hashcode()
methods
> > > > > > > > are only based on the identity fields of the
object (which cannot change)?
> > > > > > > >
> > > > > > > > -Chris West
> > > > > > > >
> > > > > > > > On 7/17/07, Mark Proctor
<mproctor(a)codehaus.org> wrote:
> > > > > > > > >
> > > > > > > > > you only need to use modifyRetract if the
object is
> > > > > > > > > inserted. The reason for this is if you
change field values on your facts we
> > > > > > > > > will not be able to remove them from our
various internal hashmaps; thus the
> > > > > > > > > need to remove first prior to any changes,
then make the changes and then
> > > > > > > > > insert it again. We can't allow users to
just call update() as we have no
> > > > > > > > > idea what the old values where, thus we
cannot find the objects in our
> > > > > > > > > hashmaps.
> > > > > > > > >
> > > > > > > > > Mark
> > > > > > > > > Chris West wrote:
> > > > > > > > >
> > > > > > > > > Mark,
> > > > > > > > >
> > > > > > > > > Using modifyRetract and modifyInsert seems
to fix the
> > > > > > > > > problem (at least in my test case I finally
created). I'll try this on my
> > > > > > > > > real code.
> > > > > > > > >
> > > > > > > > > My only concern here is that it puts the
burden on the
> > > > > > > > > rule author to know whether things are being
shadowed or not. For shadowing
> > > > > > > > > that is explicitly turned off this is ok.
But for implicit non-shadowing
> > > > > > > > > based on a class being final, this is not at
all obvious to the rule auther.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Is there any way to have this hidden such
that I can
> > > > > > > > > still call "update" but have it
use "modifyRetract" and "modifyInsert"
> > > > > > > > > instead?
> > > > > > > > >
> > > > > > > > > Also, I'm curious why I have to call
modifyRetract
> > > > > > > > > before I start modifing the object, since
the engine does not know about my
> > > > > > > > > modifications anyway until I call update or
modifyInsert? By the way, I was
> > > > > > > > > unable to use the block setter approach in
the rule consequence due to not
> > > > > > > > > having set methods for modifying my
objects.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > -Chris West
> > > > > > > > >
> > > > > > > > > On 7/17/07, Mark Proctor
<mproctor(a)codehaus.org > wrote:
> > > > > > > > > >
> > > > > > > > > > If you do not have shadow facts you
cannot use the
> > > > > > > > > > update() method, it will leave the
working memory corrupted. Instead you
> > > > > > > > > > must manage this yourself, before you
change any values on the object you
> > > > > > > > > > must call modifyRetract() and after you
hvae finished your changes ot hte
> > > > > > > > > > object call modifyInsert() - luckily if
you are doing this in the
> > > > > > > > > > consequence you can use the MVEL modify
keyword combined with the block
> > > > > > > > > > setter and it does this for you:
> > > > > > > > > > modify ( person ) { age += 1, location
= "london" }
> > > > > > > > > >
> > > > > > > > > > Mark
> > > > > > > > > > Chris West wrote:
> > > > > > > > > >
> > > > > > > > > > Hello,
> > > > > > > > > >
> > > > > > > > > > With prior versions of JBoss Rules
(3.0.5) I have been
> > > > > > > > > > using JDK generated dynamic proxies as
facts, and they have been working
> > > > > > > > > > fine. However, after upgrading to
JBoss Rules
> > > > > > > > > > 4.0.0MR3, I cannot seem to get the
dynamic proxies to
> > > > > > > > > > work as facts. It seems that even
though a rule fires that changes a field
> > > > > > > > > > on the proxy, a second rule that should
not be activated after the update
> > > > > > > > > > still fires.
> > > > > > > > > >
> > > > > > > > > > According to the JDK javadoc
documentation, dynamic
> > > > > > > > > > proxies are created as final. My
assumption is that JBoss Rules is not
> > > > > > > > > > creating Shadow facts for these since
they are final. After reading the
> > > > > > > > > > JIRA at
http://jira.jboss.com/jira/browse/JBRULES-960,
> > > > > > > > > > I now am questioning what the effect of
not using shadow facts is on the
> > > > > > > > > > engine. The relevant part of that is:
> > > > > > > > > >
> > > > > > > > > > "The problem is that SpringAOP is
generating a proxy
> > > > > > > > > > whose methods equals() and hashCode()
are "final". As drools must either
> > > > > > > > > > override these methods in the shadow
proxy or not shadow the fact at all,
> > > > > > > > > > I'm disabling shadow proxy
generation for this use case.
> > > > > > > > > > It is really important to note that if
you are
> > > > > > > > > > asserting SpringAOP proxies as facts
into the working memory, you will not
> > > > > > > > > > be able to change any field value whose
field is constrained in rules or you
> > > > > > > > > > may incur in a memory leak and
non-deterministic behavior by the rules
> > > > > > > > > > engine. Unfortunately there is nothing
we can do about, since when SpringAOP
> > > > > > > > > > makes the methods equals and hashcode
final, we can't override them anymore
> > > > > > > > > > and as so, we can't shadow
them."
> > > > > > > > > > [ Show
»<http://jira.jboss.com/jira/browse/JBRULES-960>]
> > > > > > > > > > Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> > > > > > > > > > [02/Jul/07 03:29 PM] The problem is
that SpringAOP is
> > > > > > > > > > generating a proxy whose methods
equals() and hashCode() are "final". As
> > > > > > > > > > drools must either override these
methods in the shadow proxy or not shadow
> > > > > > > > > > the fact at all, I'm disabling
shadow proxy generation for this use case. It
> > > > > > > > > > is really important to note that if you
are asserting SpringAOP proxies as
> > > > > > > > > > facts into the working memory, you will
not be able to change any field
> > > > > > > > > > value whose field is constrained in
rules or you may incur in a memory leak
> > > > > > > > > > and non-deterministic behavior by the
rules engine. Unfortunately there is
> > > > > > > > > > nothing we can do about, since when
SpringAOP makes the methods equals and
> > > > > > > > > > hashcode final, we can't override
them anymore and as so, we can't shadow
> > > > > > > > > > them.
> > > > > > > > > >
> > > > > > > > > > Although I'm not using SpringAOP, I
believe my facts
> > > > > > > > > > are not being shadowed.
> > > > > > > > > >
> > > > > > > > > > Is it true that not using shadow facts
may lead to
> > > > > > > > > > non-deterministic behavior? Prior to
shadow facts, the engine seemed to
> > > > > > > > > > handle it. Any chance of reverting
back to the old style of truth
> > > > > > > > > > maintenance in the case of not using
shadow facts.
> > > > > > > > > >
> > > > > > > > > > I apologize if I'm not on the right
track here. My
> > > > > > > > > > only test case for my problem is the
entire application right now, so I
> > > > > > > > > > cannot offer it for discussion. Any
advice would be greatly appreciated.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > -Chris West
> > > > > > > > > >
> > > > > > > > > > ------------------------------
> > > > > > > > > >
> > > > > > > > > >
_______________________________________________
> > > > > > > > > > rules-users mailing list
> > > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
_______________________________________________
> > > > > > > > > > rules-users mailing list
> > > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > ------------------------------
> > > > > > > > >
> > > > > > > > >
_______________________________________________
> > > > > > > > > rules-users mailing list
> > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
_______________________________________________
> > > > > > > > > rules-users mailing list
> > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > rules-users mailing list
> > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Edson Tirelli
> > > > > > > Software Engineer - JBoss Rules Core Developer
> > > > > > > Office: +55 11 3529-6000
> > > > > > > Mobile: +55 11 9287-5646
> > > > > > > JBoss, a division of Red Hat @ www.jboss.com
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > rules-users mailing list
> > > > > > > rules-users(a)lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > rules-users mailing list
> > > > > > rules-users(a)lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Edson Tirelli
> > > > > Software Engineer - JBoss Rules Core Developer
> > > > > Office: +55 11 3529-6000
> > > > > Mobile: +55 11 9287-5646
> > > > > JBoss, a division of Red Hat @ www.jboss.com
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users(a)lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > >
> > >
> > > --
> > > Edson Tirelli
> > > Software Engineer - JBoss Rules Core Developer
> > > Office: +55 11 3529-6000
> > > Mobile: +55 11 9287-5646
> > > JBoss, a division of Red Hat @ www.jboss.com
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
>
> --
> Edson Tirelli
> Software Engineer - JBoss Rules Core Developer
> Office: +55 11 3529-6000
> Mobile: +55 11 9287-5646
> JBoss, a division of Red Hat @ www.jboss.com
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
8:40 a.m.
Edson,
It appears that revision #13637 of drools breaks the ability for me to use
one of my existing classes. The attached eclipse project illustrates the
problem. This test works on 4.0.0MR3, but not revision #13637. The
exception is:
org.drools.spi.ConsequenceException: org.drools.RuntimeDroolsException:
Error creating shadow fact for object: NamedList(Hello List): [1, 2, 3]
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java
:549)
at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:509)
at org.drools.common.AbstractWorkingMemory.fireAllRules(
AbstractWorkingMemory.java:430)
at org.drools.common.AbstractWorkingMemory.fireAllRules(
AbstractWorkingMemory.java:392)
at com.sample.DroolsTest.main(DroolsTest.java:29)
Caused by: org.drools.RuntimeDroolsException: Error creating shadow fact for
object: NamedList(Hello List): [1, 2, 3]
at org.drools.reteoo.Rete$ObjectTypeConf.getShadow(Rete.java:458)
at org.drools.reteoo.Rete.assertObject(Rete.java:157)
at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java
:190)
at org.drools.reteoo.ReteooWorkingMemory.doInsert(
ReteooWorkingMemory.java:70)
at org.drools.common.AbstractWorkingMemory.insert(
AbstractWorkingMemory.java:848)
at org.drools.common.AbstractWorkingMemory.insert(
AbstractWorkingMemory.java:822)
at org.drools.base.DefaultKnowledgeHelper.insert(
DefaultKnowledgeHelper.java:60)
at org.drools.base.DefaultKnowledgeHelper.insert(
DefaultKnowledgeHelper.java:54)
at com.sample.Rule_Insert_named_list_0.consequence
(Rule_Insert_named_list_0.java:7)
at com.sample.Rule_Insert_named_list_0ConsequenceInvoker.evaluate
(Rule_Insert_named_list_0ConsequenceInvoker.java:19)
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java
:545)
... 4 more
Caused by: java.lang.NullPointerException
at java.util.ArrayList.ensureCapacity(ArrayList.java:163)
at java.util.ArrayList.addAll(ArrayList.java:475)
at com.sample.NamedListShadowProxy.updateProxy(Unknown Source)
at com.sample.NamedListShadowProxy.setShadowedObject(Unknown Source)
at org.drools.reteoo.Rete$ObjectTypeConf.getShadow(Rete.java:456)
... 14 more
The insert works if you modify my NamedList class to have a no arg
constructor, but the class misbehaves in my rule set (as if shadow is not
working properly).
Please take a look.
Thanks,
-Chris West
On 7/19/07, Edson Tirelli <tirelli(a)post.com> wrote:
Ouch!
Is all that trouble a result of using JDK proxies in drools? If it is,
I think it is the case of us developing a whole set of unit and integration
tests for this specific scenario, since none of our tests are triggering
errors...
Thanks and please keep me posted of your progress or any problems you
find.
[]s
Edson
2007/7/19, Chris West <crayzfishr(a)gmail.com >:
>
> Edson,
>
> Thanks for incorporating this fix. The good news is that it fixes that
> problem.
>
> The bad news for me is that I'm now experiencing a different problem
> (where my rules are not firing). I'll look into my new problem a little
> deeper.
>
> Thanks again.
> -Chris West
>
> On 7/19/07, Edson Tirelli < tirelli(a)post.com> wrote:
> >
> >
> > Chris,
> >
> > Right on the spot. I changed other references, but this one passed
> > unnoticed. The correct is:
> >
> > Class cls = null;
> > if ( object instanceof ShadowProxy ) {
> > cls =
> > ((ShadowProxy)object).getShadowedObject().getClass();
> > } else {
> > cls = object.getClass();
> > }
> >
> > I made a text search this time and found no other occurence of this
> > problem.
> > I commited the fix in revision #13637. Take a look and let me know
> > if you still has problems.
> >
> > Thank you a lot,
> > Edson
> >
> > 2007/7/19, Chris West < crayzfishr(a)gmail.com>:
> > >
> > > Edson,
> > >
> > > I think I've discovered the problem. In the file Rete.java, in the
> > > method "assertObject", there is a check for shadow proxy like
below:
> > >
> > > Class cls = object.getClass();
> > > if ( object instanceof ShadowProxy ) {
> > > cls = cls.getSuperclass();
> > > }
> > >
> > > If the class being proxied was final, and your new logic chose an
> > > interface of that class to build a proxy from, then the superclass is
> > > Object.class.
> > >
> > > This leads to an incorrect selection of cachedNodes further down in
> > > the method.
> > >
> > > I've traced this through the debugger with my object types, and it
> > > does show that a node for a SortieStatus is being given an object of type
> > > LaunchRecoveryStatusShadowProxy, which is not compatible.
> > >
> > > Perhaps theres a different way to determine the type of object such
> > > that type LaunchRecoveryStatusShadowProxy will return
LaunchRecoveryStatus
> > > rather than Object.
> > >
> > > Please take a look and let me know if I need to provide more info.
> > >
> > > Thanks,
> > > -Chris West
> > >
> > > On 7/18/07, Edson Tirelli < tirelli(a)post.com> wrote:
> > > >
> > > >
> > > > Chris,
> > > >
> > > > What seems to be happening us that your SortieStatus interface
> > > > has a state attribute. Drools is trying to read this attribute value
and
> > > > cast it to LaunchRecoveryStatusShadowProxy what is causing the
> > > > problems...
> > > > Best way to solve would be to have the code so I can debug. Is
> > > > it possible to isolate it and send me?
> > > >
> > > > []s
> > > > Edson
> > > >
> > > >
> > > >
> > > > 2007/7/18, Chris West < crayzfishr(a)gmail.com>:
> > > > >
> > > > > Edson,
> > > > >
> > > > > It is certainly possible to create a JDK proxy with only some
of
> > > > > the interfaces that are present on the delegate object that you
are
> > > > > proxying, but in my case, my proxies have all the interfaces of
the
> > > > > underlying object.
> > > > >
> > > > > The top two lines of the call stack I sent shows the following:
> > > > >
> > > > > Exception in thread "main"
java.lang.ClassCastException:
> > > > >
ascc.status.FlightOpsStatusBoard$LaunchRecoveryStatusShadowProxy
> > > > > at
> > > > >
org.drools.base.ascc.status.AirPlanStatusBoard$SortieStatus$getState.getValue(Unknown
> > > > > Source)
> > > > >
> > > > > What's strange here is that the ClassCastException seems to
be
> > > > > caused by casting an object of type SortieStatus to type
> > > > > LaunchRecoveryStatusShadowProxy, if I'm reading that right.
The types
> > > > > SortieStatus and LaunchRecoveryStatus are both interfaces in my
code, and
> > > > > they never appear on the same fact object (so no SortieStatus
will ever be a
> > > > > LaunchRecoveryStatus and vice-versa). So I'm wondering why
the cast is
> > > > > occuring, since it is not possible to work.
> > > > >
> > > > > The unfortunate part is I cannot see into the class where the
> > > > > cast is occurring, as it is a generated class created by
drools.
> > > > >
> > > > > -Chris West
> > > > >
> > > > > On 7/18/07, Edson Tirelli <tirelli(a)post.com> wrote:
> > > > > >
> > > > > >
> > > > > > Chris,
> > > > > >
> > > > > > For the solution to work, it is important that a
> > > > > > superclass or interface matches all the ObjectTypes in your
rulebase that
> > > > > > your final class (proxy) matches... I guess that is the
case with JDK
> > > > > > proxies, isn't it?
> > > > > >
> > > > > > []s
> > > > > > Edson
> > > > > >
> > > > > > 2007/7/18, Chris West <crayzfishr(a)gmail.com >:
> > > > > > >
> > > > > > > Edson,
> > > > > > >
> > > > > > > I downloaded and built the latest from the trunk of
the
> > > > > > > repository. I applied this new build toward my test
case, and it seemed to
> > > > > > > fix the problem. However, when I applied it to my
real project, it still
> > > > > > > exhibits the problem. If I discover more information
about the problem I'll
> > > > > > > let you know.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Chris West
> > > > > > >
> > > > > > > On 7/17/07, Edson Tirelli < tirelli(a)post.com>
wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > Chris,
> > > > > > > >
> > > > > > > > I found and developed an intermediate solution
that
> > > > > > > > shall work for your proxies.
> > > > > > > > If it is not possible to create a shadow fact
for a
> > > > > > > > class that is asserted (because the class is
final or whatever), the engine
> > > > > > > > goes up in the class hierarchy, looking for a
class or interface for which
> > > > > > > > is possible to create the proxy, but that still
matches all ObjectTypes
> > > > > > > > available in the rule base matched by the
original class. The analysis is a
> > > > > > > > bit complex, specially because new rules with new
object types can be
> > > > > > > > dynamically added to the rule base, but I believe
the solution will work for
> > > > > > > > JDK proxies and the most common proxy frameworks
out there, that usually
> > > > > > > > don't proxy multiple unrelated interfaces at
once.
> > > > > > > >
> > > > > > > > So, I ask you please to get latest snapshot
from the
> > > > > > > > repository and try it out for your use case and
report back to the list the
> > > > > > > > results, since seems there are a few other people
using similar things.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Edson
> > > > > > > >
> > > > > > > >
> > > > > > > > 2007/7/17, Chris West <
crayzfishr(a)gmail.com>:
> > > > > > > > >
> > > > > > > > > Is that still true if the equals() and
hashcode()
> > > > > > > > > methods are only based on the identity
fields of the object (which cannot
> > > > > > > > > change)?
> > > > > > > > >
> > > > > > > > > -Chris West
> > > > > > > > >
> > > > > > > > > On 7/17/07, Mark Proctor
<mproctor(a)codehaus.org> wrote:
> > > > > > > > > >
> > > > > > > > > > you only need to use modifyRetract if
the object is
> > > > > > > > > > inserted. The reason for this is if you
change field values on your facts we
> > > > > > > > > > will not be able to remove them from
our various internal hashmaps; thus the
> > > > > > > > > > need to remove first prior to any
changes, then make the changes and then
> > > > > > > > > > insert it again. We can't allow
users to just call update() as we have no
> > > > > > > > > > idea what the old values where, thus we
cannot find the objects in our
> > > > > > > > > > hashmaps.
> > > > > > > > > >
> > > > > > > > > > Mark
> > > > > > > > > > Chris West wrote:
> > > > > > > > > >
> > > > > > > > > > Mark,
> > > > > > > > > >
> > > > > > > > > > Using modifyRetract and modifyInsert
seems to fix the
> > > > > > > > > > problem (at least in my test case I
finally created). I'll try this on my
> > > > > > > > > > real code.
> > > > > > > > > >
> > > > > > > > > > My only concern here is that it puts
the burden on the
> > > > > > > > > > rule author to know whether things are
being shadowed or not. For shadowing
> > > > > > > > > > that is explicitly turned off this is
ok. But for implicit non-shadowing
> > > > > > > > > > based on a class being final, this is
not at all obvious to the rule auther.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Is there any way to have this hidden
such that I can
> > > > > > > > > > still call "update" but have
it use "modifyRetract" and "modifyInsert"
> > > > > > > > > > instead?
> > > > > > > > > >
> > > > > > > > > > Also, I'm curious why I have to
call modifyRetract
> > > > > > > > > > before I start modifing the object,
since the engine does not know about my
> > > > > > > > > > modifications anyway until I call
update or modifyInsert? By the way, I was
> > > > > > > > > > unable to use the block setter approach
in the rule consequence due to not
> > > > > > > > > > having set methods for modifying my
objects.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > -Chris West
> > > > > > > > > >
> > > > > > > > > > On 7/17/07, Mark Proctor
<mproctor(a)codehaus.org >
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > If you do not have shadow facts
you cannot use the
> > > > > > > > > > > update() method, it will leave the
working memory corrupted. Instead you
> > > > > > > > > > > must manage this yourself, before
you change any values on the object you
> > > > > > > > > > > must call modifyRetract() and
after you hvae finished your changes ot hte
> > > > > > > > > > > object call modifyInsert() -
luckily if you are doing this in the
> > > > > > > > > > > consequence you can use the MVEL
modify keyword combined with the block
> > > > > > > > > > > setter and it does this for you:
> > > > > > > > > > > modify ( person ) { age += 1,
location = "london" }
> > > > > > > > > > >
> > > > > > > > > > > Mark
> > > > > > > > > > > Chris West wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hello,
> > > > > > > > > > >
> > > > > > > > > > > With prior versions of JBoss Rules
(3.0.5) I have
> > > > > > > > > > > been using JDK generated dynamic
proxies as facts, and they have been
> > > > > > > > > > > working fine. However, after
upgrading to JBoss Rules
> > > > > > > > > > > 4.0.0MR3, I cannot seem to get the
dynamic proxies
> > > > > > > > > > > to work as facts. It seems that
even though a rule fires that changes a
> > > > > > > > > > > field on the proxy, a second rule
that should not be activated after the
> > > > > > > > > > > update still fires.
> > > > > > > > > > >
> > > > > > > > > > > According to the JDK javadoc
documentation, dynamic
> > > > > > > > > > > proxies are created as final. My
assumption is that JBoss Rules is not
> > > > > > > > > > > creating Shadow facts for these
since they are final. After reading the
> > > > > > > > > > > JIRA at
> > > > > > > > > > >
http://jira.jboss.com/jira/browse/JBRULES-960, I now
> > > > > > > > > > > am questioning what the effect of
not using shadow facts is on the engine.
> > > > > > > > > > > The relevant part of that is:
> > > > > > > > > > >
> > > > > > > > > > > "The problem is that
SpringAOP is generating a proxy
> > > > > > > > > > > whose methods equals() and
hashCode() are "final". As drools must either
> > > > > > > > > > > override these methods in the
shadow proxy or not shadow the fact at all,
> > > > > > > > > > > I'm disabling shadow proxy
generation for this use case.
> > > > > > > > > > > It is really important to note
that if you are
> > > > > > > > > > > asserting SpringAOP proxies as
facts into the working memory, you will not
> > > > > > > > > > > be able to change any field value
whose field is constrained in rules or you
> > > > > > > > > > > may incur in a memory leak and
non-deterministic behavior by the rules
> > > > > > > > > > > engine. Unfortunately there is
nothing we can do about, since when SpringAOP
> > > > > > > > > > > makes the methods equals and
hashcode final, we can't override them anymore
> > > > > > > > > > > and as so, we can't shadow
them."
> > > > > > > > > > > [ Show
»<http://jira.jboss.com/jira/browse/JBRULES-960>]
> > > > > > > > > > > Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> > > > > > > > > > > [02/Jul/07 03:29 PM] The problem
is that SpringAOP
> > > > > > > > > > > is generating a proxy whose
methods equals() and hashCode() are "final". As
> > > > > > > > > > > drools must either override these
methods in the shadow proxy or not shadow
> > > > > > > > > > > the fact at all, I'm disabling
shadow proxy generation for this use case. It
> > > > > > > > > > > is really important to note that
if you are asserting SpringAOP proxies as
> > > > > > > > > > > facts into the working memory, you
will not be able to change any field
> > > > > > > > > > > value whose field is constrained
in rules or you may incur in a memory leak
> > > > > > > > > > > and non-deterministic behavior by
the rules engine. Unfortunately there is
> > > > > > > > > > > nothing we can do about, since
when SpringAOP makes the methods equals and
> > > > > > > > > > > hashcode final, we can't
override them anymore and as so, we can't shadow
> > > > > > > > > > > them.
> > > > > > > > > > >
> > > > > > > > > > > Although I'm not using
SpringAOP, I believe my facts
> > > > > > > > > > > are not being shadowed.
> > > > > > > > > > >
> > > > > > > > > > > Is it true that not using shadow
facts may lead to
> > > > > > > > > > > non-deterministic behavior? Prior
to shadow facts, the engine seemed to
> > > > > > > > > > > handle it. Any chance of
reverting back to the old style of truth
> > > > > > > > > > > maintenance in the case of not
using shadow facts.
> > > > > > > > > > >
> > > > > > > > > > > I apologize if I'm not on the
right track here. My
> > > > > > > > > > > only test case for my problem is
the entire application right now, so I
> > > > > > > > > > > cannot offer it for discussion.
Any advice would be greatly appreciated.
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > > -Chris West
> > > > > > > > > > >
> > > > > > > > > > > ------------------------------
> > > > > > > > > > >
> > > > > > > > > > >
_______________________________________________
> > > > > > > > > > > rules-users mailing list
> > > > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
_______________________________________________
> > > > > > > > > > > rules-users mailing list
> > > > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > ------------------------------
> > > > > > > > > >
> > > > > > > > > >
_______________________________________________
> > > > > > > > > > rules-users mailing list
> > > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
_______________________________________________
> > > > > > > > > > rules-users mailing list
> > > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
_______________________________________________
> > > > > > > > > rules-users mailing list
> > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Edson Tirelli
> > > > > > > > Software Engineer - JBoss Rules Core Developer
> > > > > > > > Office: +55 11 3529-6000
> > > > > > > > Mobile: +55 11 9287-5646
> > > > > > > > JBoss, a division of Red Hat @ www.jboss.com
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > rules-users mailing list
> > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > rules-users mailing list
> > > > > > > rules-users(a)lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Edson Tirelli
> > > > > > Software Engineer - JBoss Rules Core Developer
> > > > > > Office: +55 11 3529-6000
> > > > > > Mobile: +55 11 9287-5646
> > > > > > JBoss, a division of Red Hat @ www.jboss.com
> > > > > >
> > > > > > _______________________________________________
> > > > > > rules-users mailing list
> > > > > > rules-users(a)lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users(a)lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Edson Tirelli
> > > > Software Engineer - JBoss Rules Core Developer
> > > > Office: +55 11 3529-6000
> > > > Mobile: +55 11 9287-5646
> > > > JBoss, a division of Red Hat @ www.jboss.com
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> >
> >
> > --
> > Edson Tirelli
> > Software Engineer - JBoss Rules Core Developer
> > Office: +55 11 3529-6000
> > Mobile: +55 11 9287-5646
> > JBoss, a division of Red Hat @ www.jboss.com
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
2:50 p.m.
Chris,
I know why it happens, but I don't know what to do. Basically, we need to
do a shallow clone of any collections asserted to the working memory to
ensure integrity. So, what I try to do is:
* Check if the collection is cloneable. If it is, use clone method.
* Else, check if the collection has a default no-arg constructor. If so,
create a new instance and use addAll() method to add all previous elements.
* Otherwise, use objenesis to instantiate object without calling the
constructor.
What is happening in your case, as you don't have a default constructor
and apparently is not cloneable, it is falling to the 3rd alternative above,
and as you are extending a java.util.Collection class, it is raising the NPE
because it is not executing the class constructor.
Not sure about how to handle such scenario since we don't get such
exception until it is too late to rollback.
[]s
Edson
2007/7/20, Chris West <crayzfishr(a)gmail.com>:
Edson,
It appears that revision #13637 of drools breaks the ability for me to use
one of my existing classes. The attached eclipse project illustrates the
problem. This test works on 4.0.0MR3, but not revision #13637. The
exception is:
org.drools.spi.ConsequenceException: org.drools.RuntimeDroolsException:
Error creating shadow fact for object: NamedList(Hello List): [1, 2, 3]
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:549)
at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java
:509)
at org.drools.common.AbstractWorkingMemory.fireAllRules(
AbstractWorkingMemory.java:430)
at org.drools.common.AbstractWorkingMemory.fireAllRules (
AbstractWorkingMemory.java:392)
at com.sample.DroolsTest.main(DroolsTest.java:29)
Caused by: org.drools.RuntimeDroolsException: Error creating shadow fact
for object: NamedList(Hello List): [1, 2, 3]
at org.drools.reteoo.Rete$ObjectTypeConf.getShadow(Rete.java:458)
at org.drools.reteoo.Rete.assertObject(Rete.java:157)
at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java
:190)
at org.drools.reteoo.ReteooWorkingMemory.doInsert (
ReteooWorkingMemory.java:70)
at org.drools.common.AbstractWorkingMemory.insert(
AbstractWorkingMemory.java:848)
at org.drools.common.AbstractWorkingMemory.insert(
AbstractWorkingMemory.java:822)
at org.drools.base.DefaultKnowledgeHelper.insert (
DefaultKnowledgeHelper.java:60)
at org.drools.base.DefaultKnowledgeHelper.insert(
DefaultKnowledgeHelper.java:54)
at com.sample.Rule_Insert_named_list_0.consequence
(Rule_Insert_named_list_0.java:7)
at com.sample.Rule_Insert_named_list_0ConsequenceInvoker.evaluate
(Rule_Insert_named_list_0ConsequenceInvoker.java:19)
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java
:545)
... 4 more
Caused by: java.lang.NullPointerException
at java.util.ArrayList.ensureCapacity(ArrayList.java:163)
at java.util.ArrayList.addAll(ArrayList.java:475)
at com.sample.NamedListShadowProxy.updateProxy(Unknown Source)
at com.sample.NamedListShadowProxy.setShadowedObject(Unknown Source)
at org.drools.reteoo.Rete$ObjectTypeConf.getShadow(Rete.java:456)
... 14 more
The insert works if you modify my NamedList class to have a no arg
constructor, but the class misbehaves in my rule set (as if shadow is not
working properly).
Please take a look.
Thanks,
-Chris West
On 7/19/07, Edson Tirelli <tirelli(a)post.com> wrote:
>
>
> Ouch!
> Is all that trouble a result of using JDK proxies in drools? If it
> is, I think it is the case of us developing a whole set of unit and
> integration tests for this specific scenario, since none of our tests are
> triggering errors...
>
> Thanks and please keep me posted of your progress or any problems you
> find.
>
> []s
> Edson
>
> 2007/7/19, Chris West < crayzfishr(a)gmail.com >:
> >
> > Edson,
> >
> > Thanks for incorporating this fix. The good news is that it fixes
> > that problem.
> >
> > The bad news for me is that I'm now experiencing a different problem
> > (where my rules are not firing). I'll look into my new problem a little
> > deeper.
> >
> > Thanks again.
> > -Chris West
> >
> > On 7/19/07, Edson Tirelli < tirelli(a)post.com> wrote:
> > >
> > >
> > > Chris,
> > >
> > > Right on the spot. I changed other references, but this one
> > > passed unnoticed. The correct is:
> > >
> > > Class cls = null;
> > > if ( object instanceof ShadowProxy ) {
> > > cls =
> > > ((ShadowProxy)object).getShadowedObject().getClass();
> > > } else {
> > > cls = object.getClass();
> > > }
> > >
> > > I made a text search this time and found no other occurence of
> > > this problem.
> > > I commited the fix in revision #13637. Take a look and let me
> > > know if you still has problems.
> > >
> > > Thank you a lot,
> > > Edson
> > >
> > > 2007/7/19, Chris West < crayzfishr(a)gmail.com>:
> > > >
> > > > Edson,
> > > >
> > > > I think I've discovered the problem. In the file Rete.java, in
> > > > the method "assertObject", there is a check for shadow
proxy like below:
> > > >
> > > > Class cls = object.getClass();
> > > > if ( object instanceof ShadowProxy ) {
> > > > cls = cls.getSuperclass();
> > > > }
> > > >
> > > > If the class being proxied was final, and your new logic chose an
> > > > interface of that class to build a proxy from, then the superclass
is
> > > > Object.class.
> > > >
> > > > This leads to an incorrect selection of cachedNodes further down
> > > > in the method.
> > > >
> > > > I've traced this through the debugger with my object types, and
it
> > > > does show that a node for a SortieStatus is being given an object of
type
> > > > LaunchRecoveryStatusShadowProxy, which is not compatible.
> > > >
> > > > Perhaps theres a different way to determine the type of object
> > > > such that type LaunchRecoveryStatusShadowProxy will return
> > > > LaunchRecoveryStatus rather than Object.
> > > >
> > > > Please take a look and let me know if I need to provide more info.
> > > >
> > > >
> > > > Thanks,
> > > > -Chris West
> > > >
> > > > On 7/18/07, Edson Tirelli < tirelli(a)post.com> wrote:
> > > > >
> > > > >
> > > > > Chris,
> > > > >
> > > > > What seems to be happening us that your SortieStatus
> > > > > interface has a state attribute. Drools is trying to read this
attribute
> > > > > value and cast it to LaunchRecoveryStatusShadowProxy what is
> > > > > causing the problems...
> > > > > Best way to solve would be to have the code so I can debug.
> > > > > Is it possible to isolate it and send me?
> > > > >
> > > > > []s
> > > > > Edson
> > > > >
> > > > >
> > > > >
> > > > > 2007/7/18, Chris West < crayzfishr(a)gmail.com>:
> > > > > >
> > > > > > Edson,
> > > > > >
> > > > > > It is certainly possible to create a JDK proxy with only
some
> > > > > > of the interfaces that are present on the delegate object
that you are
> > > > > > proxying, but in my case, my proxies have all the
interfaces of the
> > > > > > underlying object.
> > > > > >
> > > > > > The top two lines of the call stack I sent shows the
> > > > > > following:
> > > > > >
> > > > > > Exception in thread "main"
java.lang.ClassCastException:
> > > > > >
ascc.status.FlightOpsStatusBoard$LaunchRecoveryStatusShadowProxy
> > > > > > at
> > > > > >
org.drools.base.ascc.status.AirPlanStatusBoard$SortieStatus$getState.getValue(Unknown
> > > > > > Source)
> > > > > >
> > > > > > What's strange here is that the ClassCastException
seems to be
> > > > > > caused by casting an object of type SortieStatus to type
> > > > > > LaunchRecoveryStatusShadowProxy, if I'm reading that
right. The types
> > > > > > SortieStatus and LaunchRecoveryStatus are both interfaces
in my code, and
> > > > > > they never appear on the same fact object (so no
SortieStatus will ever be a
> > > > > > LaunchRecoveryStatus and vice-versa). So I'm wondering
why the cast is
> > > > > > occuring, since it is not possible to work.
> > > > > >
> > > > > > The unfortunate part is I cannot see into the class where
the
> > > > > > cast is occurring, as it is a generated class created by
drools.
> > > > > >
> > > > > > -Chris West
> > > > > >
> > > > > > On 7/18/07, Edson Tirelli <tirelli(a)post.com> wrote:
> > > > > > >
> > > > > > >
> > > > > > > Chris,
> > > > > > >
> > > > > > > For the solution to work, it is important that a
> > > > > > > superclass or interface matches all the ObjectTypes in
your rulebase that
> > > > > > > your final class (proxy) matches... I guess that is
the case with JDK
> > > > > > > proxies, isn't it?
> > > > > > >
> > > > > > > []s
> > > > > > > Edson
> > > > > > >
> > > > > > > 2007/7/18, Chris West <crayzfishr(a)gmail.com >:
> > > > > > > >
> > > > > > > > Edson,
> > > > > > > >
> > > > > > > > I downloaded and built the latest from the trunk
of the
> > > > > > > > repository. I applied this new build toward my
test case, and it seemed to
> > > > > > > > fix the problem. However, when I applied it to
my real project, it still
> > > > > > > > exhibits the problem. If I discover more
information about the problem I'll
> > > > > > > > let you know.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Chris West
> > > > > > > >
> > > > > > > > On 7/17/07, Edson Tirelli <
tirelli(a)post.com> wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Chris,
> > > > > > > > >
> > > > > > > > > I found and developed an intermediate
solution that
> > > > > > > > > shall work for your proxies.
> > > > > > > > > If it is not possible to create a shadow
fact for a
> > > > > > > > > class that is asserted (because the class is
final or whatever), the engine
> > > > > > > > > goes up in the class hierarchy, looking for
a class or interface for which
> > > > > > > > > is possible to create the proxy, but that
still matches all ObjectTypes
> > > > > > > > > available in the rule base matched by the
original class. The analysis is a
> > > > > > > > > bit complex, specially because new rules
with new object types can be
> > > > > > > > > dynamically added to the rule base, but I
believe the solution will work for
> > > > > > > > > JDK proxies and the most common proxy
frameworks out there, that usually
> > > > > > > > > don't proxy multiple unrelated
interfaces at once.
> > > > > > > > >
> > > > > > > > > So, I ask you please to get latest
snapshot from the
> > > > > > > > > repository and try it out for your use case
and report back to the list the
> > > > > > > > > results, since seems there are a few other
people using similar things.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Edson
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 2007/7/17, Chris West <
crayzfishr(a)gmail.com>:
> > > > > > > > > >
> > > > > > > > > > Is that still true if the equals() and
hashcode()
> > > > > > > > > > methods are only based on the identity
fields of the object (which cannot
> > > > > > > > > > change)?
> > > > > > > > > >
> > > > > > > > > > -Chris West
> > > > > > > > > >
> > > > > > > > > > On 7/17/07, Mark Proctor
<mproctor(a)codehaus.org>
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > you only need to use
modifyRetract if the object is
> > > > > > > > > > > inserted. The reason for this is
if you change field values on your facts we
> > > > > > > > > > > will not be able to remove them
from our various internal hashmaps; thus the
> > > > > > > > > > > need to remove first prior to any
changes, then make the changes and then
> > > > > > > > > > > insert it again. We can't
allow users to just call update() as we have no
> > > > > > > > > > > idea what the old values where,
thus we cannot find the objects in our
> > > > > > > > > > > hashmaps.
> > > > > > > > > > >
> > > > > > > > > > > Mark
> > > > > > > > > > > Chris West wrote:
> > > > > > > > > > >
> > > > > > > > > > > Mark,
> > > > > > > > > > >
> > > > > > > > > > > Using modifyRetract and
modifyInsert seems to fix
> > > > > > > > > > > the problem (at least in my test
case I finally created). I'll try this on
> > > > > > > > > > > my real code.
> > > > > > > > > > >
> > > > > > > > > > > My only concern here is that it
puts the burden on
> > > > > > > > > > > the rule author to know whether
things are being shadowed or not. For
> > > > > > > > > > > shadowing that is explicitly
turned off this is ok. But for implicit
> > > > > > > > > > > non-shadowing based on a class
being final, this is not at all obvious to
> > > > > > > > > > > the rule auther.
> > > > > > > > > > >
> > > > > > > > > > > Is there any way to have this
hidden such that I can
> > > > > > > > > > > still call "update" but
have it use "modifyRetract" and "modifyInsert"
> > > > > > > > > > > instead?
> > > > > > > > > > >
> > > > > > > > > > > Also, I'm curious why I have
to call modifyRetract
> > > > > > > > > > > before I start modifing the
object, since the engine does not know about my
> > > > > > > > > > > modifications anyway until I call
update or modifyInsert? By the way, I was
> > > > > > > > > > > unable to use the block setter
approach in the rule consequence due to not
> > > > > > > > > > > having set methods for modifying
my objects.
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > > -Chris West
> > > > > > > > > > >
> > > > > > > > > > > On 7/17/07, Mark Proctor
<mproctor(a)codehaus.org >
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > If you do not have shadow
facts you cannot use the
> > > > > > > > > > > > update() method, it will
leave the working memory corrupted. Instead you
> > > > > > > > > > > > must manage this yourself,
before you change any values on the object you
> > > > > > > > > > > > must call modifyRetract() and
after you hvae finished your changes ot hte
> > > > > > > > > > > > object call modifyInsert() -
luckily if you are doing this in the
> > > > > > > > > > > > consequence you can use the
MVEL modify keyword combined with the block
> > > > > > > > > > > > setter and it does this for
you:
> > > > > > > > > > > > modify ( person ) { age += 1,
location = "london"
> > > > > > > > > > > > }
> > > > > > > > > > > >
> > > > > > > > > > > > Mark
> > > > > > > > > > > > Chris West wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hello,
> > > > > > > > > > > >
> > > > > > > > > > > > With prior versions of JBoss
Rules (3.0.5) I have
> > > > > > > > > > > > been using JDK generated
dynamic proxies as facts, and they have been
> > > > > > > > > > > > working fine. However, after
upgrading to JBoss Rules
> > > > > > > > > > > > 4.0.0MR3, I cannot seem to
get the dynamic proxies
> > > > > > > > > > > > to work as facts. It seems
that even though a rule fires that changes a
> > > > > > > > > > > > field on the proxy, a second
rule that should not be activated after the
> > > > > > > > > > > > update still fires.
> > > > > > > > > > > >
> > > > > > > > > > > > According to the JDK javadoc
documentation,
> > > > > > > > > > > > dynamic proxies are created
as final. My assumption is that JBoss Rules is
> > > > > > > > > > > > not creating Shadow facts for
these since they are final. After reading the
> > > > > > > > > > > > JIRA at
> > > > > > > > > > > >
http://jira.jboss.com/jira/browse/JBRULES-960, I
> > > > > > > > > > > > now am questioning what the
effect of not using shadow facts is on the
> > > > > > > > > > > > engine. The relevant part of
that is:
> > > > > > > > > > > >
> > > > > > > > > > > > "The problem is that
SpringAOP is generating a
> > > > > > > > > > > > proxy whose methods equals()
and hashCode() are "final". As drools must
> > > > > > > > > > > > either override these methods
in the shadow proxy or not shadow the fact at
> > > > > > > > > > > > all, I'm disabling shadow
proxy generation for this use case.
> > > > > > > > > > > > It is really important to
note that if you are
> > > > > > > > > > > > asserting SpringAOP proxies
as facts into the working memory, you will not
> > > > > > > > > > > > be able to change any field
value whose field is constrained in rules or you
> > > > > > > > > > > > may incur in a memory leak
and non-deterministic behavior by the rules
> > > > > > > > > > > > engine. Unfortunately there
is nothing we can do about, since when SpringAOP
> > > > > > > > > > > > makes the methods equals and
hashcode final, we can't override them anymore
> > > > > > > > > > > > and as so, we can't
shadow them."
> > > > > > > > > > > > [ Show
»<http://jira.jboss.com/jira/browse/JBRULES-960>]
> > > > > > > > > > > > Edson
Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirell...
> > > > > > > > > > > > [02/Jul/07 03:29 PM] The
problem is that SpringAOP
> > > > > > > > > > > > is generating a proxy whose
methods equals() and hashCode() are "final". As
> > > > > > > > > > > > drools must either override
these methods in the shadow proxy or not shadow
> > > > > > > > > > > > the fact at all, I'm
disabling shadow proxy generation for this use case. It
> > > > > > > > > > > > is really important to note
that if you are asserting SpringAOP proxies as
> > > > > > > > > > > > facts into the working
memory, you will not be able to change any field
> > > > > > > > > > > > value whose field is
constrained in rules or you may incur in a memory leak
> > > > > > > > > > > > and non-deterministic
behavior by the rules engine. Unfortunately there is
> > > > > > > > > > > > nothing we can do about,
since when SpringAOP makes the methods equals and
> > > > > > > > > > > > hashcode final, we can't
override them anymore and as so, we can't shadow
> > > > > > > > > > > > them.
> > > > > > > > > > > >
> > > > > > > > > > > > Although I'm not using
SpringAOP, I believe my
> > > > > > > > > > > > facts are not being
shadowed.
> > > > > > > > > > > >
> > > > > > > > > > > > Is it true that not using
shadow facts may lead to
> > > > > > > > > > > > non-deterministic behavior?
Prior to shadow facts, the engine seemed to
> > > > > > > > > > > > handle it. Any chance of
reverting back to the old style of truth
> > > > > > > > > > > > maintenance in the case of
not using shadow facts.
> > > > > > > > > > > >
> > > > > > > > > > > > I apologize if I'm not on
the right track here.
> > > > > > > > > > > > My only test case for my
problem is the entire application right now, so I
> > > > > > > > > > > > cannot offer it for
discussion. Any advice would be greatly appreciated.
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks,
> > > > > > > > > > > > -Chris West
> > > > > > > > > > > >
> > > > > > > > > > > >
------------------------------
> > > > > > > > > > > >
> > > > > > > > > > > >
_______________________________________________
> > > > > > > > > > > > rules-users mailing list
> > > > > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
_______________________________________________
> > > > > > > > > > > > rules-users mailing list
> > > > > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > > > > >
> > > > > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > ------------------------------
> > > > > > > > > > >
> > > > > > > > > > >
_______________________________________________
> > > > > > > > > > > rules-users mailing list
> > > > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
_______________________________________________
> > > > > > > > > > > rules-users mailing list
> > > > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
_______________________________________________
> > > > > > > > > > rules-users mailing list
> > > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Edson Tirelli
> > > > > > > > > Software Engineer - JBoss Rules Core
Developer
> > > > > > > > > Office: +55 11 3529-6000
> > > > > > > > > Mobile: +55 11 9287-5646
> > > > > > > > > JBoss, a division of Red Hat @
www.jboss.com
> > > > > > > > >
> > > > > > > > >
_______________________________________________
> > > > > > > > > rules-users mailing list
> > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > rules-users mailing list
> > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Edson Tirelli
> > > > > > > Software Engineer - JBoss Rules Core Developer
> > > > > > > Office: +55 11 3529-6000
> > > > > > > Mobile: +55 11 9287-5646
> > > > > > > JBoss, a division of Red Hat @ www.jboss.com
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > rules-users mailing list
> > > > > > > rules-users(a)lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > rules-users mailing list
> > > > > > rules-users(a)lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Edson Tirelli
> > > > > Software Engineer - JBoss Rules Core Developer
> > > > > Office: +55 11 3529-6000
> > > > > Mobile: +55 11 9287-5646
> > > > > JBoss, a division of Red Hat @ www.jboss.com
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users(a)lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > >
> > >
> > > --
> > > Edson Tirelli
> > > Software Engineer - JBoss Rules Core Developer
> > > Office: +55 11 3529-6000
> > > Mobile: +55 11 9287-5646
> > > JBoss, a division of Red Hat @ www.jboss.com
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
>
> --
> Edson Tirelli
> Software Engineer - JBoss Rules Core Developer
> Office: +55 11 3529-6000
> Mobile: +55 11 9287-5646
> JBoss, a division of Red Hat @ www.jboss.com
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
9:09 p.m.
Hello,
I got same problem to Chris's. Java classes are generated from XML schema (using
XMLBean). And the problem occurs when I try to assert objects of those classes into
working memory. The exception is:
java.lang.VerifyError: class b2BContext.impl.UserImplShadowProxy overrides final method
hashCode.()I
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
at
org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:40)
at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:59)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.drools.reteoo.Rete$ObjectTypeConf.<init>(Rete.java:352)
at org.drools.reteoo.Rete.assertObject(Rete.java:152)
at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:772)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:584)
at
org.drools.jsr94.rules.StatefulRuleSessionImpl.addObject(StatefulRuleSessionImpl.java:162)
at
org.drools.jsr94.rules.StatefulRuleSessionImpl.addObjects(StatefulRuleSessionImpl.java:185)
I am new to JBoss Rule, so may you show me how to disable Shadow. Please help.
Thanks,
Anthony.
Edson Tirelli <tirelli(a)post.com> wrote:
Chris,
I know why it happens, but I don't know what to do. Basically, we need to do a
shallow clone of any collections asserted to the working memory to ensure integrity. So,
what I try to do is:
* Check if the collection is cloneable. If it is, use clone method.
* Else, check if the collection has a default no-arg constructor. If so, create a new
instance and use addAll() method to add all previous elements.
* Otherwise, use objenesis to instantiate object without calling the constructor.
What is happening in your case, as you don't have a default constructor and
apparently is not cloneable, it is falling to the 3rd alternative above, and as you are
extending a java.util.Collection class, it is raising the NPE because it is not executing
the class constructor.
Not sure about how to handle such scenario since we don't get such exception until
it is too late to rollback.
[]s
Edson
2007/7/20, Chris West <crayzfishr(a)gmail.com>: Edson,
It appears that revision #13637 of drools breaks the ability for me to use one of my
existing classes. The attached eclipse project illustrates the problem. This test works
on 4.0.0MR3, but not revision #13637. The exception is:
org.drools.spi.ConsequenceException: org.drools.RuntimeDroolsException: Error creating
shadow fact for object: NamedList(Hello List): [1, 2, 3]
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java :549)
at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:509)
at
org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:430)
at org.drools.common.AbstractWorkingMemory.fireAllRules
(AbstractWorkingMemory.java:392)
at com.sample.DroolsTest.main(DroolsTest.java:29)
Caused by: org.drools.RuntimeDroolsException: Error creating shadow fact for object:
NamedList(Hello List): [1, 2, 3]
at org.drools.reteoo.Rete$ObjectTypeConf.getShadow(Rete.java:458)
at org.drools.reteoo.Rete.assertObject(Rete.java:157)
at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
at org.drools.reteoo.ReteooWorkingMemory.doInsert (ReteooWorkingMemory.java:70)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
at org.drools.base.DefaultKnowledgeHelper.insert (DefaultKnowledgeHelper.java:60)
at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:54)
at com.sample.Rule_Insert_named_list_0.consequence(Rule_Insert_named_list_0.java:7)
at
com.sample.Rule_Insert_named_list_0ConsequenceInvoker.evaluate(Rule_Insert_named_list_0ConsequenceInvoker.java:19)
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:545)
... 4 more
Caused by: java.lang.NullPointerException
at java.util.ArrayList.ensureCapacity(ArrayList.java:163)
at java.util.ArrayList.addAll(ArrayList.java:475)
at com.sample.NamedListShadowProxy.updateProxy(Unknown Source)
at com.sample.NamedListShadowProxy.setShadowedObject(Unknown Source)
at org.drools.reteoo.Rete$ObjectTypeConf.getShadow(Rete.java:456)
... 14 more
The insert works if you modify my NamedList class to have a no arg constructor, but the
class misbehaves in my rule set (as if shadow is not working properly).
Please take a look.
Thanks,
-Chris West
On 7/19/07, Edson Tirelli <tirelli(a)post.com> wrote:
Ouch!
Is all that trouble a result of using JDK proxies in drools? If it is, I think it is
the case of us developing a whole set of unit and integration tests for this specific
scenario, since none of our tests are triggering errors...
Thanks and please keep me posted of your progress or any problems you find.
[]s
Edson
2007/7/19, Chris West < crayzfishr(a)gmail.com >:Edson,
Thanks for incorporating this fix. The good news is that it fixes that problem.
The bad news for me is that I'm now experiencing a different problem (where my rules
are not firing). I'll look into my new problem a little deeper.
Thanks again.
-Chris West
On 7/19/07, Edson Tirelli < tirelli(a)post.com> wrote:
Chris,
Right on the spot. I changed other references, but this one passed unnoticed. The
correct is:
Class cls = null;
if ( object instanceof ShadowProxy ) {
cls = ((ShadowProxy)object).getShadowedObject().getClass();
} else {
cls = object.getClass();
}
I made a text search this time and found no other occurence of this problem.
I commited the fix in revision #13637. Take a look and let me know if you still has
problems.
Thank you a lot,
Edson
2007/7/19, Chris West < crayzfishr@gmail.com>:Edson,
I think I've discovered the problem. In the file Rete.java, in the method
"assertObject", there is a check for shadow proxy like below:
Class cls = object.getClass();
if ( object instanceof ShadowProxy ) {
cls = cls.getSuperclass();
}
If the class being proxied was final, and your new logic chose an interface of that class
to build a proxy from, then the superclass is Object.class.
This leads to an incorrect selection of cachedNodes further down in the method.
I've traced this through the debugger with my object types, and it does show that a
node for a SortieStatus is being given an object of type LaunchRecoveryStatusShadowProxy,
which is not compatible.
Perhaps theres a different way to determine the type of object such that type
LaunchRecoveryStatusShadowProxy will return LaunchRecoveryStatus rather than Object.
Please take a look and let me know if I need to provide more info.
Thanks,
-Chris West
On 7/18/07, Edson Tirelli < tirelli(a)post.com> wrote:
Chris,
What seems to be happening us that your SortieStatus interface has a state attribute.
Drools is trying to read this attribute value and cast it to
LaunchRecoveryStatusShadowProxy what is causing the problems...
Best way to solve would be to have the code so I can debug. Is it possible to isolate
it and send me?
[]s
Edson
2007/7/18, Chris West < crayzfishr@gmail.com>:Edson,
It is certainly possible to create a JDK proxy with only some of the interfaces that are
present on the delegate object that you are proxying, but in my case, my proxies have all
the interfaces of the underlying object.
The top two lines of the call stack I sent shows the following:
Exception in thread "main" java.lang.ClassCastException:
ascc.status.FlightOpsStatusBoard$LaunchRecoveryStatusShadowProxy
at
org.drools.base.ascc.status.AirPlanStatusBoard$SortieStatus$getState.getValue(Unknown
Source)
What's strange here is that the ClassCastException seems to be caused by casting an
object of type SortieStatus to type LaunchRecoveryStatusShadowProxy, if I'm reading
that right. The types SortieStatus and LaunchRecoveryStatus are both interfaces in my
code, and they never appear on the same fact object (so no SortieStatus will ever be a
LaunchRecoveryStatus and vice-versa). So I'm wondering why the cast is occuring,
since it is not possible to work.
The unfortunate part is I cannot see into the class where the cast is occurring, as it is
a generated class created by drools.
-Chris West
On 7/18/07, Edson Tirelli <tirelli(a)post.com> wrote:
Chris,
For the solution to work, it is important that a superclass or interface matches all
the ObjectTypes in your rulebase that your final class (proxy) matches... I guess that is
the case with JDK proxies, isn't it?
[]s
Edson
2007/7/18, Chris West <crayzfishr(a)gmail.com >: Edson,
I downloaded and built the latest from the trunk of the repository. I applied this new
build toward my test case, and it seemed to fix the problem. However, when I applied it
to my real project, it still exhibits the problem. If I discover more information about
the problem I'll let you know.
Thanks,
Chris West
On 7/17/07, Edson Tirelli < tirelli(a)post.com> wrote:
Chris,
I found and developed an intermediate solution that shall work for your proxies.
If it is not possible to create a shadow fact for a class that is asserted (because the
class is final or whatever), the engine goes up in the class hierarchy, looking for a
class or interface for which is possible to create the proxy, but that still matches all
ObjectTypes available in the rule base matched by the original class. The analysis is a
bit complex, specially because new rules with new object types can be dynamically added to
the rule base, but I believe the solution will work for JDK proxies and the most common
proxy frameworks out there, that usually don't proxy multiple unrelated interfaces at
once.
So, I ask you please to get latest snapshot from the repository and try it out for your
use case and report back to the list the results, since seems there are a few other people
using similar things.
Thanks,
Edson
2007/7/17, Chris West < crayzfishr(a)gmail.com>: Is that still true if the equals()
and hashcode() methods are only based on the identity fields of the object (which cannot
change)?
-Chris West
On 7/17/07, Mark Proctor <mproctor(a)codehaus.org> wrote: you
only need to use modifyRetract if the object is inserted. The reason for this is if you
change field values on your facts we will not be able to remove them from our various
internal hashmaps; thus the need to remove first prior to any changes, then make the
changes and then insert it again. We can't allow users to just call update() as we
have no idea what the old values where, thus we cannot find the objects in our hashmaps.
Mark
Chris West wrote: Mark,
Using modifyRetract and modifyInsert seems to fix the problem (at least in my test case I
finally created). I'll try this on my real code.
My only concern here is that it puts the burden on the rule author to know whether things
are being shadowed or not. For shadowing that is explicitly turned off this is ok. But
for implicit non-shadowing based on a class being final, this is not at all obvious to the
rule auther.
Is there any way to have this hidden such that I can still call "update" but
have it use "modifyRetract" and "modifyInsert" instead?
Also, I'm curious why I have to call modifyRetract before I start modifing the
object, since the engine does not know about my modifications anyway until I call update
or modifyInsert? By the way, I was unable to use the block setter approach in the rule
consequence due to not having set methods for modifying my objects.
Thanks,
-Chris West
On 7/17/07, Mark Proctor <mproctor(a)codehaus.org > wrote: If you do not
have shadow facts you cannot use the update() method, it will leave the working memory
corrupted. Instead you must manage this yourself, before you change any values on the
object you must call modifyRetract() and after you hvae finished your changes ot hte
object call modifyInsert() - luckily if you are doing this in the consequence you can use
the MVEL modify keyword combined with the block setter and it does this for you:
modify ( person ) { age += 1, location = "london" }
Mark
Chris West wrote: Hello,
With prior versions of JBoss Rules (3.0.5) I have been using JDK generated dynamic
proxies as facts, and they have been working fine. However, after upgrading to JBoss
Rules 4.0.0MR3, I cannot seem to get the dynamic proxies to work as facts. It seems that
even though a rule fires that changes a field on the proxy, a second rule that should not
be activated after the update still fires.
According to the JDK javadoc documentation, dynamic proxies are created as final. My
assumption is that JBoss Rules is not creating Shadow facts for these since they are
final. After reading the JIRA at http://jira.jboss.com/jira/browse/JBRULES-960, I now am
questioning what the effect of not using shadow facts is on the engine. The relevant part
of that is:
"The problem is that SpringAOP is generating a proxy whose methods equals() and
hashCode() are "final". As drools must either override these methods in the
shadow proxy or not shadow the fact at all, I'm disabling shadow proxy generation for
this use case.
It is really important to note that if you are asserting SpringAOP proxies as facts
into the working memory, you will not be able to change any field value whose field is
constrained in rules or you may incur in a memory leak and non-deterministic behavior by
the rules engine. Unfortunately there is nothing we can do about, since when SpringAOP
makes the methods equals and hashcode final, we can't override them anymore and as so,
we can't shadow them."
[ Show » ]
Edson Tirelli [02/Jul/07 03:29 PM] The problem is that SpringAOP is
generating a proxy whose methods equals() and hashCode() are "final". As drools
must either override these methods in the shadow proxy or not shadow the fact at all,
I'm disabling shadow proxy generation for this use case. It is really important to
note that if you are asserting SpringAOP proxies as facts into the working memory, you
will not be able to change any field value whose field is constrained in rules or you may
incur in a memory leak and non-deterministic behavior by the rules engine. Unfortunately
there is nothing we can do about, since when SpringAOP makes the methods equals and
hashcode final, we can't override them anymore and as so, we can't shadow them.
Although I'm not using SpringAOP, I believe my facts are not being shadowed.
Is it true that not using shadow facts may lead to non-deterministic behavior? Prior to
shadow facts, the engine seemed to handle it. Any chance of reverting back to the old
style of truth maintenance in the case of not using shadow facts.
I apologize if I'm not on the right track here. My only test case for my problem is
the entire application right now, so I cannot offer it for discussion. Any advice would
be greatly appreciated.
Thanks,
-Chris West
---------------------------------
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
---------------------------------
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
---------------------------------
Be a better Globetrotter. Get better travel answers from someone who knows.
Yahoo! Answers - Check it out.
9:19 p.m.
Anthony,
If you have a choice on your binding framework, I might suggesting
switching to Castor. I had the same problem you experienced and
switched to Castor and it worked like a champ.
Ron
On 7/23/07, trandinh tho <tdtho_cs(a)yahoo.com> wrote:
Hello,
I got same problem to Chris's. Java classes are generated from XML schema
(using XMLBean). And the problem occurs when I try to assert objects of
those classes into working memory. The exception is:
java.lang.VerifyError: class
b2BContext.impl.UserImplShadowProxy overrides final method
hashCode.()I
at java.lang.ClassLoader.defineClass1(Native
Method)
at
java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
java.lang.ClassLoader.defineClass(ClassLoader.java:465)
at
org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:40)
at
org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:59)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
org.drools.reteoo.Rete$ObjectTypeConf.<init>(Rete.java:352)
at
org.drools.reteoo.Rete.assertObject(Rete.java:152)
at
org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
at
org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)
at
org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:772)
at
org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:584)
at
org.drools.jsr94.rules.StatefulRuleSessionImpl.addObject(StatefulRuleSessionImpl.java:162)
at
org.drools.jsr94.rules.StatefulRuleSessionImpl.addObjects(StatefulRuleSessionImpl.java:185)
I am new to JBoss Rule, so may you show me how to disable Shadow. Please
help.
Thanks,
Anthony.
Edson Tirelli <tirelli(a)post.com> wrote:
Chris,
I know why it happens, but I don't know what to do. Basically, we need to
do a shallow clone of any collections asserted to the working memory to
ensure integrity. So, what I try to do is:
* Check if the collection is cloneable. If it is, use clone method.
* Else, check if the collection has a default no-arg constructor. If so,
create a new instance and use addAll() method to add all previous elements.
* Otherwise, use objenesis to instantiate object without calling the
constructor.
What is happening in your case, as you don't have a default constructor
and apparently is not cloneable, it is falling to the 3rd alternative above,
and as you are extending a java.util.Collection class, it is raising the NPE
because it is not executing the class constructor.
Not sure about how to handle such scenario since we don't get such
exception until it is too late to rollback.
[]s
Edson
2007/7/20, Chris West <crayzfishr(a)gmail.com>:
> Edson,
>
> It appears that revision #13637 of drools breaks the ability for me to use
one of my existing classes. The attached eclipse project illustrates the
problem. This test works on 4.0.0MR3, but not revision #13637. The
exception is:
>
> org.drools.spi.ConsequenceException:
org.drools.RuntimeDroolsException: Error creating shadow
fact for object: NamedList(Hello List): [1, 2, 3]
> at
org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java
:549)
> at
org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:509)
> at
org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:430)
> at
org.drools.common.AbstractWorkingMemory.fireAllRules
(AbstractWorkingMemory.java:392)
> at com.sample.DroolsTest.main(DroolsTest.java:29)
> Caused by: org.drools.RuntimeDroolsException: Error
creating shadow fact for object: NamedList(Hello List): [1, 2, 3]
> at
org.drools.reteoo.Rete$ObjectTypeConf.getShadow(Rete.java:458)
> at org.drools.reteoo.Rete.assertObject(Rete.java:157)
> at
org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
> at org.drools.reteoo.ReteooWorkingMemory.doInsert
(ReteooWorkingMemory.java:70)
> at
org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:848)
> at
org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822)
> at org.drools.base.DefaultKnowledgeHelper.insert
(DefaultKnowledgeHelper.java:60)
> at
org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:54)
> at
com.sample.Rule_Insert_named_list_0.consequence(Rule_Insert_named_list_0.java:7)
> at
com.sample.Rule_Insert_named_list_0ConsequenceInvoker.evaluate(Rule_Insert_named_list_0ConsequenceInvoker.java:19)
> at
org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:545)
> ... 4 more
> Caused by: java.lang.NullPointerException
> at
java.util.ArrayList.ensureCapacity(ArrayList.java:163)
> at java.util.ArrayList.addAll(ArrayList.java:475)
> at
com.sample.NamedListShadowProxy.updateProxy(Unknown Source)
> at
com.sample.NamedListShadowProxy.setShadowedObject(Unknown
Source)
> at
org.drools.reteoo.Rete$ObjectTypeConf.getShadow(Rete.java:456)
> ... 14 more
>
> The insert works if you modify my NamedList class to have a no arg
constructor, but the class misbehaves in my rule set (as if shadow is not
working properly).
>
> Please take a look.
>
> Thanks,
> -Chris West
>
>
>
>
> On 7/19/07, Edson Tirelli <tirelli(a)post.com> wrote:
> >
> > Ouch!
> > Is all that trouble a result of using JDK proxies in drools? If it
is, I think it is the case of us developing a whole set of unit and
integration tests for this specific scenario, since none of our tests are
triggering errors...
> >
> > Thanks and please keep me posted of your progress or any problems you
find.
> >
> > []s
> >
> > Edson
> >
> >
> > 2007/7/19, Chris West < crayzfishr(a)gmail.com >:
> > > Edson,
> > >
> > > Thanks for incorporating this fix. The good news is that it fixes
that problem.
> > >
> > > The bad news for me is that I'm now experiencing a different problem
(where my rules are not firing). I'll look into my new problem a little
deeper.
> > >
> > > Thanks again.
> > > -Chris West
> > >
> > >
> > >
> > > On 7/19/07, Edson Tirelli < tirelli(a)post.com> wrote:
> > > >
> > > > Chris,
> > > >
> > > > Right on the spot. I changed other references, but this one
passed unnoticed. The correct is:
> > > >
> > > > Class cls = null;
> > > > if ( object instanceof ShadowProxy ) {
> > > > cls =
((ShadowProxy)object).getShadowedObject().getClass();
> > > > } else {
> > > > cls = object.getClass();
> > > > }
> > > >
> > > > I made a text search this time and found no other occurence of
this problem.
> > > > I commited the fix in revision #13637. Take a look and let me
know if you still has problems.
> > > >
> > > > Thank you a lot,
> > > > Edson
> > > >
> > > >
> > > > 2007/7/19, Chris West < crayzfishr(a)gmail.com>:
> > > >
> > > > > Edson,
> > > > >
> > > > > I think I've discovered the problem. In the file Rete.java,
in
the method "assertObject", there is a check for shadow proxy like below:
> > > > >
> > > > > Class cls = object.getClass();
> > > > > if ( object instanceof ShadowProxy ) {
> > > > > cls = cls.getSuperclass();
> > > > > }
> > > > >
> > > > > If the class being proxied was final, and your new logic chose
an
interface of that class to build a proxy from, then the superclass is
Object.class.
> > > > >
> > > > > This leads to an incorrect selection of cachedNodes further
down
in the method.
> > > > >
> > > > > I've traced this through the debugger with my object types,
and it
does show that a node for a SortieStatus is being given an object of type
LaunchRecoveryStatusShadowProxy, which is not compatible.
> > > > >
> > > > > Perhaps theres a different way to determine the type of object
such that type LaunchRecoveryStatusShadowProxy will return
LaunchRecoveryStatus rather than Object.
> > > > >
> > > > > Please take a look and let me know if I need to provide more
info.
> > > > >
> > > > > Thanks,
> > > > > -Chris West
> > > > >
> > > > >
> > > > >
> > > > > On 7/18/07, Edson Tirelli < tirelli(a)post.com> wrote:
> > > > > >
> > > > > > Chris,
> > > > > >
> > > > > > What seems to be happening us that your SortieStatus
interface has a state attribute. Drools is trying to read this attribute
value and cast it to LaunchRecoveryStatusShadowProxy what is causing the
problems...
> > > > > > Best way to solve would be to have the code so I can
debug.
Is it possible to isolate it and send me?
> > > > > >
> > > > > > []s
> > > > > > Edson
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2007/7/18, Chris West < crayzfishr(a)gmail.com>:
> > > > > > > Edson,
> > > > > > >
> > > > > > > It is certainly possible to create a JDK proxy with
only some
of the interfaces that are present on the delegate object that you are
proxying, but in my case, my proxies have all the interfaces of the
underlying object.
> > > > > > >
> > > > > > > The top two lines of the call stack I sent shows the
following:
> > > > > > >
> > > > > > > Exception in thread "main"
java.lang.ClassCastException:
ascc.status.FlightOpsStatusBoard$LaunchRecoveryStatusShadowProxy
> > > > > > >
> > > > > > > at
org.drools.base.ascc.status.AirPlanStatusBoard$SortieStatus$getState.getValue(Unknown
Source)
> > > > > > > What's strange here is that the ClassCastException
seems to be
caused by casting an object of type SortieStatus to type
LaunchRecoveryStatusShadowProxy, if I'm reading that
right. The types SortieStatus and LaunchRecoveryStatus are both interfaces
in my code, and they never appear on the same fact object (so no
SortieStatus will ever be a LaunchRecoveryStatus and vice-versa). So I'm
wondering why the cast is occuring, since it is not possible to work.
> > > > > > >
> > > > > > > The unfortunate part is I cannot see into the class
where the
cast is occurring, as it is a generated class created by drools.
> > > > > > >
> > > > > > > -Chris West
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 7/18/07, Edson Tirelli <tirelli(a)post.com>
wrote:
> > > > > > > >
> > > > > > > > Chris,
> > > > > > > >
> > > > > > > > For the solution to work, it is important
that a
superclass or interface matches all the ObjectTypes in your rulebase that
your final class (proxy) matches... I guess that is the case with JDK
proxies, isn't it?
> > > > > > > >
> > > > > > > > []s
> > > > > > > > Edson
> > > > > > > >
> > > > > > > >
> > > > > > > > 2007/7/18, Chris West <crayzfishr(a)gmail.com
>:
> > > > > > > >
> > > > > > > > > Edson,
> > > > > > > > >
> > > > > > > > > I downloaded and built the latest from the
trunk of the
repository. I applied this new build toward my test case, and it seemed to
fix the problem. However, when I applied it to my real project, it still
exhibits the problem. If I discover more information about the problem I'll
let you know.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Chris West
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 7/17/07, Edson Tirelli <
tirelli(a)post.com> wrote:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Chris,
> > > > > > > > > >
> > > > > > > > > > I found and developed an
intermediate solution that
shall work for your proxies.
> > > > > > > > > > If it is not possible to create a
shadow fact for a
class that is asserted (because the class is final or whatever), the engine
goes up in the class hierarchy, looking for a class or interface for which
is possible to create the proxy, but that still matches all ObjectTypes
available in the rule base matched by the original class. The analysis is a
bit complex, specially because new rules with new object types can be
dynamically added to the rule base, but I believe the solution will work for
JDK proxies and the most common proxy frameworks out there, that usually
don't proxy multiple unrelated interfaces at once.
> > > > > > > > > >
> > > > > > > > > > So, I ask you please to get latest
snapshot from the
repository and try it out for your use case and report back to the list the
results, since seems there are a few other people using similar things.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Edson
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 2007/7/17, Chris West <
crayzfishr(a)gmail.com>:
> > > > > > > > > >
> > > > > > > > > > > Is that still true if the equals()
and hashcode()
methods are only based on the identity fields of the object (which cannot
change)?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > -Chris West
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On 7/17/07, Mark Proctor
<mproctor(a)codehaus.org>
wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > you only need to use
modifyRetract if the object is
inserted. The reason for this is if you change field values on your facts we
will not be able to remove them from our various internal hashmaps; thus the
need to remove first prior to any changes, then make the changes and then
insert it again. We can't allow users to just call update() as we have no
idea what the old values where, thus we cannot find the objects in our
hashmaps.
> > > > > > > > > > > >
> > > > > > > > > > > > Mark
> > > > > > > > > > > >
> > > > > > > > > > > > Chris West wrote:
> > > > > > > > > > > > Mark,
> > > > > > > > > > > >
> > > > > > > > > > > > Using modifyRetract and
modifyInsert seems to fix
the problem (at least in my test case I finally created). I'll try this on
my real code.
> > > > > > > > > > > >
> > > > > > > > > > > > My only concern here is that
it puts the burden on
the rule author to know whether things are being shadowed or not. For
shadowing that is explicitly turned off this is ok. But for implicit
non-shadowing based on a class being final, this is not at all obvious to
the rule auther.
> > > > > > > > > > > >
> > > > > > > > > > > > Is there any way to have this
hidden such that I can
still call "update" but have it use "modifyRetract" and
"modifyInsert"
instead?
> > > > > > > > > > > >
> > > > > > > > > > > > Also, I'm curious why I
have to call modifyRetract
before I start modifing the object, since the engine does not know about my
modifications anyway until I call update or modifyInsert? By the way, I was
unable to use the block setter approach in the rule consequence due to not
having set methods for modifying my objects.
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks,
> > > > > > > > > > > > -Chris West
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On 7/17/07, Mark Proctor
<mproctor(a)codehaus.org >
wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you do not have
shadow facts you cannot use the
update() method, it will leave the working memory corrupted. Instead you
must manage this yourself, before you change any values on the object you
must call modifyRetract() and after you hvae finished your changes ot hte
object call modifyInsert() - luckily if you are doing this in the
consequence you can use the MVEL modify keyword combined with the block
setter and it does this for you:
> > > > > > > > > > > > > modify ( person ) { age
+= 1, location = "london"
}
> > > > > > > > > > > > >
> > > > > > > > > > > > > Mark
> > > > > > > > > > > > > Chris West wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hello,
> > > > > > > > > > > > >
> > > > > > > > > > > > > With prior versions of
JBoss Rules (3.0.5) I have
been using JDK generated dynamic proxies as facts, and they have been
working fine. However, after upgrading to JBoss Rules 4.0.0MR3, I cannot
seem to get the dynamic proxies to work as facts. It seems that even though
a rule fires that changes a field on the proxy, a second rule that should
not be activated after the update still fires.
> > > > > > > > > > > > >
> > > > > > > > > > > > > According to the JDK
javadoc documentation,
dynamic proxies are created as final. My assumption is that JBoss Rules is
not creating Shadow facts for these since they are final. After reading the
JIRA at http://jira.jboss.com/jira/browse/JBRULES-960, I
now am questioning what the effect of not using shadow facts is on the
engine. The relevant part of that is:
> > > > > > > > > > > > >
> > > > > > > > > > > > > "The problem is
that SpringAOP is generating a
proxy whose methods equals() and hashCode() are "final". As drools must
either override these methods in the shadow proxy or not shadow the fact at
all, I'm disabling shadow proxy generation for this use case.
> > > > > > > > > > > > >
> > > > > > > > > > > > > It is really important
to note that if you are
asserting SpringAOP proxies as facts into the working memory, you will not
be able to change any field value whose field is constrained in rules or you
may incur in a memory leak and non-deterministic behavior by the rules
engine. Unfortunately there is nothing we can do about, since when SpringAOP
makes the methods equals and hashcode final, we can't override them anymore
and as so, we can't shadow them."
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > [ Show » ]
> > > > > > > > > > > > > Edson Tirelli [02/Jul/07
03:29 PM] The problem is
that SpringAOP is generating a proxy whose methods equals() and hashCode()
are "final". As drools must either override these methods in the shadow
proxy or not shadow the fact at all, I'm disabling shadow proxy generation
for this use case. It is really important to note that if you are asserting
SpringAOP proxies as facts into the working memory, you will not be able to
change any field value whose field is constrained in rules or you may incur
in a memory leak and non-deterministic behavior by the rules engine.
Unfortunately there is nothing we can do about, since when SpringAOP makes
the methods equals and hashcode final, we can't override them anymore and as
so, we can't shadow them.
> > > > > > > > > > > > > Although I'm not
using SpringAOP, I believe my
facts are not being shadowed.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Is it true that not
using shadow facts may lead to
non-deterministic behavior? Prior to shadow facts, the engine seemed to
handle it. Any chance of reverting back to the old style of truth
maintenance in the case of not using shadow facts.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I apologize if I'm
not on the right track here.
My only test case for my problem is the entire application right now, so I
cannot offer it for discussion. Any advice would be greatly appreciated.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > -Chris West
> > > > > > > > > > > > >
> > > > > > > > > > > > >
________________________________
_______________________________________________
> > > > > > > > > > > > > rules-users mailing
list
> > > > > > > > > > > > >
rules-users(a)lists.jboss.org
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
_______________________________________________
> > > > > > > > > > > > > rules-users mailing
list
> > > > > > > > > > > > >
rules-users(a)lists.jboss.org
> > > > > > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
________________________________
_______________________________________________
> > > > > > > > > > > > rules-users mailing list
> > > > > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
_______________________________________________
> > > > > > > > > > > > rules-users mailing list
> > > > > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
_______________________________________________
> > > > > > > > > > > rules-users mailing list
> > > > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Edson Tirelli
> > > > > > > > > > Software Engineer - JBoss Rules Core
Developer
> > > > > > > > > > Office: +55 11 3529-6000
> > > > > > > > > > Mobile: +55 11 9287-5646
> > > > > > > > > > JBoss, a division of Red Hat @
www.jboss.com
> > > > > > > > > >
_______________________________________________
> > > > > > > > > > rules-users mailing list
> > > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
_______________________________________________
> > > > > > > > > rules-users mailing list
> > > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Edson Tirelli
> > > > > > > > Software Engineer - JBoss Rules Core Developer
> > > > > > > > Office: +55 11 3529-6000
> > > > > > > > Mobile: +55 11 9287-5646
> > > > > > > > JBoss, a division of Red Hat @ www.jboss.com
> > > > > > > >
_______________________________________________
> > > > > > > > rules-users mailing list
> > > > > > > > rules-users(a)lists.jboss.org
> > > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
_______________________________________________
> > > > > > > rules-users mailing list
> > > > > > > rules-users(a)lists.jboss.org
> > > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Edson Tirelli
> > > > > > Software Engineer - JBoss Rules Core Developer
> > > > > > Office: +55 11 3529-6000
> > > > > > Mobile: +55 11 9287-5646
> > > > > > JBoss, a division of Red Hat @ www.jboss.com
> > > > > > _______________________________________________
> > > > > > rules-users mailing list
> > > > > > rules-users(a)lists.jboss.org
> > > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users(a)lists.jboss.org
> > > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Edson Tirelli
> > > > Software Engineer - JBoss Rules Core Developer
> > > > Office: +55 11 3529-6000
> > > > Mobile: +55 11 9287-5646
> > > > JBoss, a division of Red Hat @ www.jboss.com
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > >
https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> >
> >
> >
> > --
> > Edson Tirelli
> > Software Engineer - JBoss Rules Core Developer
> > Office: +55 11 3529-6000
> > Mobile: +55 11 9287-5646
> > JBoss, a division of Red Hat @ www.jboss.com
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
________________________________
Be a better Globetrotter. Get better travel answers from someone who knows.
Yahoo! Answers - Check it out.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
9:54 a.m.
you can always override equals() and hashcode() on your fact objects.
In fact it is always encouraged to do so. If you are using eclipse,
you can even choose the interesting properties which define the
semantic identity of your fact objects and eclipse can generate the
equals() and hashcode() methods automatically for you.
Regards,
Ellen
On 7/17/07, Chris West <crayzfishr(a)gmail.com> wrote:
Is that still true if the equals() and hashcode() methods are only
based on
the identity fields of the object (which cannot change)?
-Chris West
On 7/17/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
>
> you only need to use modifyRetract if the object is inserted. The reason
for this is if you change field values on your facts we will not be able to
remove them from our various internal hashmaps; thus the need to remove
first prior to any changes, then make the changes and then insert it again.
We can't allow users to just call update() as we have no idea what the old
values where, thus we cannot find the objects in our hashmaps.
>
> Mark
>
> Chris West wrote:
> Mark,
>
> Using modifyRetract and modifyInsert seems to fix the problem (at least in
my test case I finally created). I'll try this on my real code.
>
> My only concern here is that it puts the burden on the rule author to know
whether things are being shadowed or not. For shadowing that is explicitly
turned off this is ok. But for implicit non-shadowing based on a class
being final, this is not at all obvious to the rule auther.
>
> Is there any way to have this hidden such that I can still call "update"
but have it use "modifyRetract" and "modifyInsert" instead?
>
> Also, I'm curious why I have to call modifyRetract before I start modifing
the object, since the engine does not know about my modifications anyway
until I call update or modifyInsert? By the way, I was unable to use the
block setter approach in the rule consequence due to not having set methods
for modifying my objects.
>
> Thanks,
> -Chris West
>
>
> On 7/17/07, Mark Proctor <mproctor(a)codehaus.org > wrote:
> >
> > If you do not have shadow facts you cannot use the update() method, it
will leave the working memory corrupted. Instead you must manage this
yourself, before you change any values on the object you must call
modifyRetract() and after you hvae finished your changes ot hte object call
modifyInsert() - luckily if you are doing this in the consequence you can
use the MVEL modify keyword combined with the block setter and it does this
for you:
> > modify ( person ) { age += 1, location = "london" }
> >
> > Mark
> > Chris West wrote:
> >
> > Hello,
> >
> > With prior versions of JBoss Rules (3.0.5) I have been using JDK
generated dynamic proxies as facts, and they have been working fine.
However, after upgrading to JBoss Rules 4.0.0MR3, I cannot seem to get the
dynamic proxies to work as facts. It seems that even though a rule fires
that changes a field on the proxy, a second rule that should not be
activated after the update still fires.
> >
> > According to the JDK javadoc documentation, dynamic proxies are created
as final. My assumption is that JBoss Rules is not creating Shadow facts
for these since they are final. After reading the JIRA at
http://jira.jboss.com/jira/browse/JBRULES-960, I now am
questioning what the effect of not using shadow facts is on the engine. The
relevant part of that is:
> >
> > "The problem is that SpringAOP is generating a proxy whose methods
equals() and hashCode() are "final". As drools must either override these
methods in the shadow proxy or not shadow the fact at all, I'm disabling
shadow proxy generation for this use case.
> >
> > It is really important to note that if you are asserting SpringAOP
proxies as facts into the working memory, you will not be able to change any
field value whose field is constrained in rules or you may incur in a memory
leak and non-deterministic behavior by the rules engine. Unfortunately there
is nothing we can do about, since when SpringAOP makes the methods equals
and hashcode final, we can't override them anymore and as so, we can't
shadow them."
> >
> >
> >
> > [ Show » ]
> > Edson Tirelli [02/Jul/07 03:29 PM] The problem is that SpringAOP is
generating a proxy whose methods equals() and hashCode() are "final". As
drools must either override these methods in the shadow proxy or not shadow
the fact at all, I'm disabling shadow proxy generation for this use case. It
is really important to note that if you are asserting SpringAOP proxies as
facts into the working memory, you will not be able to change any field
value whose field is constrained in rules or you may incur in a memory leak
and non-deterministic behavior by the rules engine. Unfortunately there is
nothing we can do about, since when SpringAOP makes the methods equals and
hashcode final, we can't override them anymore and as so, we can't shadow
them.
> > Although I'm not using SpringAOP, I believe my facts are not being
shadowed.
> >
> > Is it true that not using shadow facts may lead to non-deterministic
behavior? Prior to shadow facts, the engine seemed to handle it. Any
chance of reverting back to the old style of truth maintenance in the case
of not using shadow facts.
> >
> > I apologize if I'm not on the right track here. My only test case for
my problem is the entire application right now, so I cannot offer it for
discussion. Any advice would be greatly appreciated.
> >
> > Thanks,
> > -Chris West
> >
> > ________________________________
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> >
> >
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
> ________________________________
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Ellen Ning Zhao
Department of Computer Science
University of Applied Science of Kaiserslautern at Zweibruecken
Tel: +49-179-7447898
homepage: http://ningning.org/
6366
days inactive
6373
days old
28 comments
7 participants
participants (7)
-
Chris West -
Edson Tirelli -
Ellen Zhao -
Manukyan, Sergey -
Mark Proctor -
Ronald R. DiFrango -
trandinh tho