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 < [EMAIL PROTECTED]>:
>
> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]>:
> > >
> > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] >:
> > > > >
> > > > > 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]>:
> > > > > > >
> > > > > > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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
> > > > > > > > > [email protected]
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > rules-users mailing list
> > > > > > > > > [email protected]
> > > > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > > >
> > > > > > > > >
> > > > > > > > ------------------------------
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > rules-users mailing list
> > > > > > > > [email protected]
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > rules-users mailing list
> > > > > > > > [email protected]
> > > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > rules-users mailing list
> > > > > > > [email protected]
> > > > > > > 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
> > > > > > [email protected]
> > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > [email protected]
> > > > > 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
> > > > [email protected]
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > [email protected]
> > > 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
> > [email protected]
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
> _______________________________________________
> rules-users mailing list
> [email protected]
> 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
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
