Re: [rules-users] Version 4.0.0.MR4
Is there any information for the version 4 ? Mark Proctor wrote: planned for the 16th. The engine is near enough frozen now, just waiting on the IDE stufff to finish, hopefully any day now. Mark hypnosat7 wrote: And for the 4.0.0 release ? thanks Mark Proctor wrote: you can try that now from the continuous build releases: http://cruisecontrol.jboss.com/cc/artifacts/jboss-rules I want to do it by tue/wed this week, I'm just waiting for them to finish the gui stuff off - this will hopefully be the last milestone release before we ship a candidate release. Mark hypnosat7 wrote: Can you pls tell us when the version 4 MR4 will be released ? I'm waiting for the feature JBRULES-350 : client/server API for rule deployment and management ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- View this message in context: http://www.nabble.com/Version-4.0.0.MR4-tf4011681.html#a11663630 Sent from the drools - user mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Entreprise using Drools with success
Is there any companies which used Drools successfully ? Tell us more about your experiences, I need it to make decision -- View this message in context: http://www.nabble.com/Entreprise-using-Drools-with-success-tf4101493.html#a11663657 Sent from the drools - user mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Unable to perform simple primitive operations
Natraj, What you described are all limitations of drools 3. They are all solved now in drools 4, but not much we can do in 3. []s Edson 2007/7/18, Natraj Gudla [EMAIL PROTECTED]: Hi All, I am using Drools 3.0.6 and unable to perform some simple form of multiplication. I want to compare an object field with another field multiplied by a factor. * rule * *Calculate* Business profit,1 *when * *EMIAgainstProperty* ( bp1 : businessProfit1 ) emi : *EMIAgainstProperty* ( businessProfit2 *(bp1*1.5)* ) *then *emi.setBusinessProfit((emi.getBusinessProfit1 ()+emi.getBusinessProfit2())/2);* ** end* I get an error on creation of the package that * is undefined for Double and double. I understand this is because Drools does an auto box on primitive type variables. But is there a work around to do simpler comparisons like this, especially on the right hand side of the condition. some thing like [ variable * constantValue ]. Also, i am forced to do a declaration for businessProfit1, and use in the comparison below. I am not able to compare two fields of the same object directly. some thing like businessProfit2 businessProfit1 does not work, why is this so? Any one has faced these problems earlier? Thanks Natraj ___ rules-users mailing list rules-users@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Another problem
Hi Natraj, I wrote up a few tactics to (successfully) debug rules: http://rbs.gernotstarke.de/faq/faq/faq-devel.html It's neither finished nor complete - but try it out... (test both conditions with one rule for each of them, test for the existence of the appropriate facts, include a catchall-rule which prints all facts from wm.) regards, Gernot Hi, I am using Drools 3.0.6, and facing a peculiar problem. My rule: * rule* Calculate Business profit,1* **salience* 1000 *when **EMIAgainstProperty ( BP1 : refBP1 ) *emi : EMIAgainstProperty ( businessProfit2 BP1 ) *then* * *System.out.println( BP +(emi.getBusinessProfit1 ()+emi.getBusinessProfit2())/2);* *emi.setBusinessProfit((emi.getBusinessProfit1 ()+emi.getBusinessProfit2())/2);* **end* ** The above line in bold inside the condition part seem to create problem for rule evaluation. WHen i have this, the rule does not show up in the Agenda view, hence i dont see the console print in the action part. As soon as i remove this line and replace BP1 with 1.5 in the second line, i see the rule being fired. As far as i understand, I am doing a declaration to set refBP1 an object attribute to BP1, which i later use.What is that i am missing here? My fact has proper getter and setters for refBP1 attribute. Thanks Natraj ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Dr. Gernot Starke Willi-Lauf Allee 43, D-50858 Köln Tel. +49 (0) 177 - 728 2570 Mail: [EMAIL PROTECTED] http://www.gernotstarke.de http://www.arc42.de ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Entreprise using Drools with success
Yes, there are. I work (as external consultant) for a few of those, which I am not allowed to disclose here... But: A decision pro/con Drools should be based upon YOUR specific criteria, not those of other enterprises, right?! In my experience, Drools is both stable and performant enough to be used in productive environment. We tested several deployment and architecture variants (esp. for batch processing), with 100 Rules and 10 facts for each data-row within our batches, but a few million rows. Worked out fine. We currently use 3.0.6, no major issues. regards, Gernot Is there any companies which used Drools successfully ? Tell us more about your experiences, I need it to make decision -- View this message in context: http://www.nabble.com/Entreprise-using-Drools-with-success-tf4101493.html#a11663657 Sent from the drools - user mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Dr. Gernot Starke Willi-Lauf Allee 43, D-50858 Köln Tel. +49 (0) 177 - 728 2570 Mail: [EMAIL PROTECTED] http://www.gernotstarke.de http://www.arc42.de ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] NoClassDefFoundError for BaseObjectClassFieldExtractor when running in Tomcat
The NoClassDefFoundError exception is thrown from within drools code, so it's obviously in the classpath. The problem appears to be with the mechanism used by drools to load it's own code. Jesse On Wed, 2007-18-07 at 02:14 -0300, Fernando Meyer wrote: You should add the drools-core library as a required dependency. Fernando Meyer http://fmeyer.org [EMAIL PROTECTED] PGP: 0xD804DDFB On Jul 17, 2007, at 9:55 AM, Jesse Stockall wrote: Tomcat 5.5 Java 1.5 jbossrules-4.0.0.12865MR3 I have an instance of Drools running inside a webapp deployed on Tomcat. The rules have been compiled ahead of time and are loaded in with: InputStream is = PolicyRuntime.class.getResourceAsStream(name); DroolsObjectInputStream in = new DroolsObjectInputStream(is); Package p = (Package) in.readObject(); When run outside Tomcat it loads fine, when run inside Tomcat I get: java.lang.NoClassDefFoundError: org/drools/base/extractors/BaseObjectClassFieldExtractor at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at org.drools.base.ClassFieldExtractorFactory $ByteArrayClassLoader.defineClass(ClassFieldExtractorFactory.java:455) at org.drools.base.ClassFieldExtractorFactory.getClassFieldExtractor(ClassFieldExtractorFactory.java:114) at org.drools.base.ClassFieldExtractor.init(ClassFieldExtractor.java:77) at org.drools.base.ClassFieldExtractor.init(ClassFieldExtractor.java:57) at org.drools.base.ClassFieldExtractorCache.getExtractor(ClassFieldExtractorCache.java:35) at org.drools.base.ClassFieldExtractor.readResolve(ClassFieldExtractor.java:72) I've tried adding DroolsObjectInputStream.class.getClassLoader() , PolicyRuntime.class.getClassLoader() and Thread.currentThread().getContextClassLoader() to the constructor of the DroolsObjectInputStream but none had any effect. Thanks Jesse ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Another problem
Hi Starke, Thanks a lot for your inputs. Apart from being able to debug using your stuff, my main concern is that a simple declaration is making the rule not to fire. Why is that so? I am pretty sure, when i remove that particular line the fact which is passed passes the condition. The Drools documentation has a clear example which does the same. Any help in this regard will highly be appreciated. Thanks Natraj On 7/18/07, Dr. Gernot Starke [EMAIL PROTECTED] wrote: Hi Natraj, I wrote up a few tactics to (successfully) debug rules: http://rbs.gernotstarke.de/faq/faq/faq-devel.html It's neither finished nor complete - but try it out... (test both conditions with one rule for each of them, test for the existence of the appropriate facts, include a catchall-rule which prints all facts from wm.) regards, Gernot Hi, I am using Drools 3.0.6, and facing a peculiar problem. My rule: * rule* Calculate Business profit,1* **salience* 1000 *when **EMIAgainstProperty ( BP1 : refBP1 ) *emi : EMIAgainstProperty ( businessProfit2 BP1 ) *then* * *System.out.println( BP +(emi.getBusinessProfit1 ()+emi.getBusinessProfit2())/2);* *emi.setBusinessProfit((emi.getBusinessProfit1 ()+emi.getBusinessProfit2())/2);* **end* ** The above line in bold inside the condition part seem to create problem for rule evaluation. WHen i have this, the rule does not show up in the Agenda view, hence i dont see the console print in the action part. As soon as i remove this line and replace BP1 with 1.5 in the second line, i see the rule being fired. As far as i understand, I am doing a declaration to set refBP1 an object attribute to BP1, which i later use.What is that i am missing here? My fact has proper getter and setters for refBP1 attribute. Thanks Natraj ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Dr. Gernot Starke Willi-Lauf Allee 43, D-50858 Köln Tel. +49 (0) 177 - 728 2570 Mail: [EMAIL PROTECTED] http://www.gernotstarke.de http://www.arc42.de ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Entreprise using Drools with success
We deployed a Drools based solution to a client in the pharmaceutical distribution world (Fortune 100 company :-). We used Drools to power the decisions an interactive voice ordering system. A small number of rules initially but growing constantly based on user metrics. System has been running for a couple of years now. On 7/18/07, Geoffrey Wiseman [EMAIL PROTECTED] wrote: On 7/18/07, hypnosat7 [EMAIL PROTECTED] wrote: Is there any companies which used Drools successfully ? Tell us more about your experiences, I need it to make decision I've worked at a company that used it internally in its product before, although I don't work there now. It worked well for us; and everything I've seen about subsequent releases implies it's better than ever. Now, that's not to say that any of us can predict your success; it does depend on how you plan on using it, but for the most part, I'd say Drools / JBoss Rules is a relatively easy-to-use, powerful and performant choice for many of the things people consider using it for. - Geoffrey -- Geoffrey Wiseman ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Unable to perform simple primitive operations
Mark, We might not be using 4.0 so soon. The business is still to make a decision on that. In these scenarios what is way out to effectively code such kind of a scenarios. If i make all my class attributes to be objects ( Double), then in the rule conditions i cannot use something like 1. attrib * 1.5, because it fails saying * cannot be applied to Double and double 2. attrib.doubleValue() * 1.5 isnt working. Complains that doubleValue() is not defined in java.lang.Object. attrib has been declared as Double in my object. 3. I havent tried a full analysis, but calling a function which does this calculation cant be called from the other half of the predicate. If say attrib2 multiply(attrib1.doubleValue(), 1.5). It complains of not being able to resolve multiply. I have specifically observed difficulty to work things for the part coming after a or a etc. THe work around which i tried is emi: EMIObject ( businessProfit1 (businessProfit2 * 1.5) ) - This wont work i have another variable in EMIObject, whic is declared double bp = businessProfit2 * 1.5; and then emi: EMIObject ( businessProfit1 bp ). This works, but i am forced to move some logic to the business object which should not be the case. Let me know if there is a better way! Or am i missing any basics over here? Any inputs are very useful. Thanks Natraj On 7/18/07, Mark Proctor [EMAIL PROTECTED] wrote: I believe all your requests are in 4.0, give that a try. For 2.0.6 you'll have to unwrap (bpl.doubleValue() * 1.5 ) Mark Natraj Gudla wrote: Hi All, I am using Drools 3.0.6 and unable to perform some simple form of multiplication. I want to compare an object field with another field multiplied by a factor. * rule **Calculate* Business profit,1 *when **EMIAgainstProperty* ( bp1 : businessProfit1 ) emi : *EMIAgainstProperty* ( businessProfit2 *(bp1*1.5)* ) *then *emi.setBusinessProfit((emi.getBusinessProfit1 ()+emi.getBusinessProfit2())/2);* **end* I get an error on creation of the package that * is undefined for Double and double. I understand this is because Drools does an auto box on primitive type variables. But is there a work around to do simpler comparisons like this, especially on the right hand side of the condition. some thing like [ variable * constantValue ]. Also, i am forced to do a declaration for businessProfit1, and use in the comparison below. I am not able to compare two fields of the same object directly. some thing like businessProfit2 businessProfit1 does not work, why is this so? Any one has faced these problems earlier? Thanks Natraj -- ___ rules-users mailing [EMAIL PROTECTED]://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
RE: [rules-users] Entreprise using Drools with success
We short-listed Drools against ILOG and Fair Issac. V4.0 was to be the technical winner but for (a) per CPU support cost and (b) internal politics. It was (and still is) a shame we had to sell out :-( Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Sam-Bodden Sent: 18 July 2007 15:01 To: Rules Users List Subject: Re: [rules-users] Entreprise using Drools with success We deployed a Drools based solution to a client in the pharmaceutical distribution world (Fortune 100 company :-). We used Drools to power the decisions an interactive voice ordering system. A small number of rules initially but growing constantly based on user metrics. System has been running for a couple of years now. On 7/18/07, Geoffrey Wiseman [EMAIL PROTECTED] wrote: On 7/18/07, hypnosat7 [EMAIL PROTECTED] wrote: Is there any companies which used Drools successfully ? Tell us more about your experiences, I need it to make decision I've worked at a company that used it internally in its product before, although I don't work there now. It worked well for us; and everything I've seen about subsequent releases implies it's better than ever. Now, that's not to say that any of us can predict your success; it does depend on how you plan on using it, but for the most part, I'd say Drools / JBoss Rules is a relatively easy-to-use, powerful and performant choice for many of the things people consider using it for. - Geoffrey -- Geoffrey Wiseman ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] The effect of not using shadow facts
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
Re: [rules-users] The effect of not using shadow facts
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 [EMAIL PROTECTED] 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 [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 » ]
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
Re: [rules-users] The effect of not using shadow facts
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 [EMAIL PROTECTED] 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 [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?
Re: [rules-users] The effect of not using shadow facts
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
Re: [rules-users] The effect of not using shadow facts
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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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 [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
Re: [rules-users] The effect of not using shadow facts
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
[rules-users] Re: Entreprise using Drools with success
Not quite able to say who I work for, but we run a brokerage app for which we licensed the source code. We've been running/modding the app for the last 3 years, so it's pretty much our app now, in terms of how familiar we are with it, and how much we've changed/tuned it. That being said, our app had a custom rules engine, with a bloated XML language, etc. In evaluating Drools, I tested out commission calculation. We have about 40 scenarios, so I created 1000 trades of each type, put them in a collection, and shuffled it. Commission calculation in our old rules engine took about 38000ms, and Drools did it in about 250ms. So, the speed, and the fact that to download it, read the docs, write all the rules using a DSL, and write and run the test took me only about 4 hours (never having seen Drools before) led me to think that it merited a closer look. Matt Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] The effect of not using shadow facts
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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 [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
Re: [rules-users] The effect of not using shadow facts
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
Re: [rules-users] The effect of not using shadow facts
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, 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] : 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 [EMAIL PROTECTED] 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 [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
[rules-users] 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.___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] disable shadowing facts in MR3
You need to use trunk... that was not available in MR3 I think. 2007/7/18, Manukyan, Sergey [EMAIL PROTECTED]: 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@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Proposal: Collect Case Studies
Hi Drools-users, to further promote JBoss-Drools I suggest to compile a few practical application scenarios or case-studies. A few of you gave hints on your application domains as answer to Re: [rules-users] Entreprise using Drools with success. I am most willing to document examples, as long as you provide enough details (plus sample rules...). What about a section in the JBoss-Drools-Wiki? I'll start writing a sample one of these days - so far see my first ideas on content-based routing: http://rbs.gernotstarke.de/samples/samples/routing.html feedback welcome Gernot ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Proposal: Collect Case Studies
Oh - reply to my own mail :-) One (awesome!) example has been written on InfoQ: http://www.infoq.com/articles/Brasilian-Healthcare-System It's not only on Drools, but covers many other aspects as well... but having a few of those would be GREAT! cu, Gernot Am 18.07.2007 um 23:21 schrieb Dr. Gernot Starke: Hi Drools-users, to further promote JBoss-Drools I suggest to compile a few practical application scenarios or case-studies. A few of you gave hints on your application domains as answer to Re: [rules-users] Entreprise using Drools with success. I am most willing to document examples, as long as you provide enough details (plus sample rules...). What about a section in the JBoss-Drools-Wiki? I'll start writing a sample one of these days - so far see my first ideas on content-based routing: http://rbs.gernotstarke.de/samples/samples/routing.html feedback welcome Gernot ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users Dr. Gernot Starke Doing IT Right --- Willi-Lauf Allee 43, D-50858 Köln [EMAIL PROTECTED], +49 (0) 177 - 728 2570 http://www.gernotstarke.de Blog: http://it-and-more.blogspot.com Das freie Portal für Software-Architekten: http://www.arc42.de ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Proposal: Collect Case Studies
Hi folks, I used to buy some hardware from here and played with their configurator: http://www.alternate.de/html/includeStaticBig.html?treeName=KONFIGURATORENfile=BuildersIncLevel1=; (The page is in German but they have graphic icons around it's not hard to understand) If you choose an amd based motherboard and an Intel CPU together, their web configuration will warn you and you have to re-choose. I do not really know how they implemented it but I thought a rule-based implementation is very suitable for such kind of thing. I ran into a combinatorial optimization problem recently. At the first thought, any Rete-based rule engine is not really the right tool for searching optimal solutions in a *huge* solution space. But when I started to implement my algorithm, it turns out that Drools can still possibly help me in two places. I decided to use Monte Carlo optimization algorithms, for my problem the most interesting candidates are evolution strategy and genetic algorithms. Before I start to randomly poll elements from the solution space, I could use drools to efficiently filter out the absolutely unwanted elements (this has its drawbacks too...depends on how tolerate to the end result the end users *want* to be). My filter condition changes very often (it would depends on the things like personal preference of a particular user, etc), so using drools for filtering makes sense. The filtering does effectively reduce the solution space. And then, drools could be used to calculate the global score after each poll from the solution space. If I use the genetic algorithm, the mixing rules could also be defined in a .drl file (which will be very easy to change, and yes, it needs frequent changes when I want to tune the system). The gene mixing could also be running in Drools' working memory. There might be some performance gain against straight iteration + data manipulation in a single java procedure. But I have not implemented it yet (will start coding from tomorrow), so far not sure about the performance gain. if anything turns out good, I'd be glad to report. Regards, Ellen N. Zhao On 7/18/07, Dr. Gernot Starke [EMAIL PROTECTED] wrote: Hi Drools-users, to further promote JBoss-Drools I suggest to compile a few practical application scenarios or case-studies. A few of you gave hints on your application domains as answer to Re: [rules-users] Entreprise using Drools with success. I am most willing to document examples, as long as you provide enough details (plus sample rules...). What about a section in the JBoss-Drools-Wiki? I'll start writing a sample one of these days - so far see my first ideas on content-based routing: http://rbs.gernotstarke.de/samples/samples/routing.html feedback welcome Gernot ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
