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 [EMAIL PROTECTED] wrote:
Hello,
I got same problem to Chris's. Java classes
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
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 {
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
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
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 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()
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
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
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
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:
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,
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
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 [EMAIL PROTECTED]:
Edson,
I'll try to re-create the problem in a self contained test,
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
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
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
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
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
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
20 matches
Mail list logo
