[rules-users] Having an else part
When writing a rule, how do i deal with a scenario to do an action when a condition is not true. If i have a business need like IF COND1 is true DO Action1 ELSE DO Action 2 I feel with drools we only check for the condition in when part and incase it fails, we dont have a way to call another action. Any idea?? Thanks Natraj ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Having an else part
we currently recommend that you figure out the specific rules for that else part, and write them seperately. Mark Natraj Gudla wrote: When writing a rule, how do i deal with a scenario to do an action when a condition is not true. If i have a business need like IF COND1 is true DO Action1 ELSE DO Action 2 I feel with drools we only check for the condition in when part and incase it fails, we dont have a way to call another action. Any idea?? Thanks Natraj ___ 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] NoClassDefFoundError for BaseObjectClassFieldExtractor when running in Tomcat
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
RE: [rules-users] Unable to load dialect
Ok, just before I submit to JIRA, I want to make sure I have a case.
So I am using MR3.
The exception is thrown when for cycle is used with local variable
declared inside:
rule
when
...
then
for(int i = 1;;){break;}
end
it worked fine when variable is defined outside of cycle:
rule
when
...
then
int i = 0;
for(i = 1;;){break;}
end
Mark, please confirm that it is an issue and needs to be submitted to
JIRA,
Thanks,
-Sergey
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Proctor
Sent: Monday, July 16, 2007 4:58 PM
To: Rules Users List
Subject: Re: [rules-users] Unable to load dialect
no idea, please make a self contained test showing your error and upload
to jira.
Mark
Manukyan, Sergey wrote:
Ok, got it fixed by including the core-3.2.3.v_686_R32x.jar file,
also
included all other jar files in the same lib folder.
Now getting other exception:
[7/16/07 15:03:19:026 EDT] 002c SystemErr R
java.lang.NullPointerException
at
org.drools.rule.builder.dialect.java.JavaConsequenceBuilder.build(JavaCo
nsequenceBuilder.java:54)
at
org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:67)
at
org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:390)
at
org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:264)
at
org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java
:147)
Help! ;-)
-Sergey
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Manukyan,
Sergey
Sent: Monday, July 16, 2007 2:03 PM
To: Rules Users List
Subject: [rules-users] Unable to load dialect
Folks,
Just upgraded to MR3 from MR2 and started getting this exception:
[7/16/07 13:30:23:772 EDT] 0025 SystemErr R
org.drools.RuntimeDroolsException: Unable to load dialect
'org.drools.rule.builder.dialect.java.JavaDialect:java'
at
org.drools.compiler.PackageBuilderConfiguration.buildDialectRegistry(Pac
kageBuilderConfiguration.java:156)
at
org.drools.compiler.PackageBuilder.init(PackageBuilder.java:131)
at
org.drools.compiler.PackageBuilder.init(PackageBuilder.java:84)
Any idea why?... I included all 4 jar new files and removed old
ones...
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
___
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] 4.0 JBoss Rules IDE - JDK 1.4 compiler setting
Kris, I think I just realized that JBoss rules IDE is NOT compatible with Eclipse Europa and hence the strange behavior. That would explain some of this. On 7/17/07, Ronald R. DiFrango [EMAIL PROTECTED] wrote: Kris, I set the compiler compliance to 5.0, but the generated classes to 1.4. The only catch is that I also have to set the Source compatibility to 1.4as well. Hence the error still occurs. Ron On 7/16/07, Kris Verlaenen [EMAIL PROTECTED] wrote: Ronald, Could you try not setting the compiler compliance level of your eclipse project to 1.4 but leaving that to 5.0 and only setting the source compatibility level and the generated .class files compatibility to 1.4? The plugin needs a 5.0 compliant parser, but it can generate 1.4 compliant class files. The errors in the rules should then disappear. Kris Citeren Ronald R. DiFrango [EMAIL PROTECTED]: All, I had to change the compiler setting from JDK 5.0 to JDK 1.4 and no all of a sudden my DRL files give me the following error: Severity and DescriptionPathResourceLocationCreation Time Id Syntax error, static imports are only available if source level is 5.0 RtvDecisionEngine/src/rules/com/circuitcity/rtvcrms/rules modelDiscrepancyRules.drlline 20118400666338277860 On all rules. Thoughts? Ron ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] 4.0 JBoss Rules IDE - JDK 1.4 compiler setting
Kris, I set the compiler compliance to 5.0, but the generated classes to 1.4. The only catch is that I also have to set the Source compatibility to 1.4 as well. Hence the error still occurs. Ron On 7/16/07, Kris Verlaenen [EMAIL PROTECTED] wrote: Ronald, Could you try not setting the compiler compliance level of your eclipse project to 1.4 but leaving that to 5.0 and only setting the source compatibility level and the generated .class files compatibility to 1.4? The plugin needs a 5.0 compliant parser, but it can generate 1.4 compliant class files. The errors in the rules should then disappear. Kris Citeren Ronald R. DiFrango [EMAIL PROTECTED]: All, I had to change the compiler setting from JDK 5.0 to JDK 1.4 and no all of a sudden my DRL files give me the following error: Severity and DescriptionPathResourceLocationCreation Time Id Syntax error, static imports are only available if source level is 5.0 RtvDecisionEngine/src/rules/com/circuitcity/rtvcrms/rules modelDiscrepancyRules.drlline 20118400666338277860 On all rules. Thoughts? Ron ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Unable to load dialect
Sergey
This was indeed a bug that I already solved in MR4. If you get latest
successful build you shall not have the problem:
http://cruisecontrol.jboss.com/cc/artifacts/jboss-rules
Thanks,
Edson
2007/7/17, Manukyan, Sergey [EMAIL PROTECTED]:
Ok, just before I submit to JIRA, I want to make sure I have a case.
So I am using MR3.
The exception is thrown when for cycle is used with local variable
declared inside:
rule
when
...
then
for(int i = 1;;){break;}
end
it worked fine when variable is defined outside of cycle:
rule
when
...
then
int i = 0;
for(i = 1;;){break;}
end
Mark, please confirm that it is an issue and needs to be submitted to
JIRA,
Thanks,
-Sergey
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Proctor
Sent: Monday, July 16, 2007 4:58 PM
To: Rules Users List
Subject: Re: [rules-users] Unable to load dialect
no idea, please make a self contained test showing your error and upload
to jira.
Mark
Manukyan, Sergey wrote:
Ok, got it fixed by including the core-3.2.3.v_686_R32x.jar file,
also
included all other jar files in the same lib folder.
Now getting other exception:
[7/16/07 15:03:19:026 EDT] 002c SystemErr R
java.lang.NullPointerException
at
org.drools.rule.builder.dialect.java.JavaConsequenceBuilder.build(JavaCo
nsequenceBuilder.java:54)
at
org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:67)
at
org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:390)
at
org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:264)
at
org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java
:147)
Help! ;-)
-Sergey
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Manukyan,
Sergey
Sent: Monday, July 16, 2007 2:03 PM
To: Rules Users List
Subject: [rules-users] Unable to load dialect
Folks,
Just upgraded to MR3 from MR2 and started getting this exception:
[7/16/07 13:30:23:772 EDT] 0025 SystemErr R
org.drools.RuntimeDroolsException: Unable to load dialect
'org.drools.rule.builder.dialect.java.JavaDialect:java'
at
org.drools.compiler.PackageBuilderConfiguration.buildDialectRegistry(Pac
kageBuilderConfiguration.java:156)
at
org.drools.compiler.PackageBuilder.init(PackageBuilder.java:131)
at
org.drools.compiler.PackageBuilder.init(PackageBuilder.java:84)
Any idea why?... I included all 4 jar new files and removed old
ones...
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
___
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
--
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] The effect of not using shadow facts
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 Tirellihttp://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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Re: Using JDK dynamic proxies as facts
Oleg,
So far I have not been successful. I've just posted my thoughts to this
list (under the subject The effect of not using shadow facts). Concerning
the class names, my rules only match on an interface type implemented by the
proxies, so the actual class type of the instance does not matter.
-Chris
On 7/13/07, Oleg Yavorsky [EMAIL PROTECTED] wrote:
Chris,
I'm thinking about using dynamic proxies in my rules too. I'll be glad to
hear about your success with them. I think that there could be problem with
matching of facts as they won't be of original class but of Proxy$... one.
CGLIB approach doesn't have such problem as it just modifies original
classes' bytecode. I could be wrong, anyway.
Oleg.
*Mark Proctor [EMAIL PROTECTED]* wrote:
That is not the only thing that determines shadowing. If you look the
shadowing is actually determined here:
if ( !ruleBase.getConfiguration().isShadowProxy() || cls ==
null || !ruleBase.getConfiguration().isShadowed( cls.getName() ) ) {
return;
}
By default shadowing is turned on for all (none final) bjects, except
stuff in the org.drools namespace, you have to set exclusion lists.too. So
if your package has a null namespace it will still attempt to shadow it.
Mark
Chris West wrote:
OK, I just solved my own problem. My proxy had no package, since the jdk
based proxy is only in a package if it has at least 1 non public interface,
according to the javadoc.
The suspect code beginning on line 333 is:
String pkgName = cls.getPackage().getName();
if ( org.drools.reteoo.equals( pkgName ) ||
org.drools.base.equals(
pkgName ) ) {
// We don't shadow internal classes
this.shadowEnabled = false;
return;
}
The getPackage() method returns null. In this case, it would be good if
JBoss Rules handled the null and went on to shadow the object anyway, since
it is obviously not in the org.drools packages.
Now I'll continue trying to build a test case for my original problem.
Shall I enter a JIRA for this issue?
Thanks,
-Chris West
On 7/12/07, Chris West [EMAIL PROTECTED] wrote:
Hello,
I'm trying to use objects that are generated as dynamic proxies (through
the java.lang.reflect.Proxy class) as facts in JBoss Rules 4.0 MR3. My
project was using CGLib to generate proxies, and they were working just fine
in 3.0.6. However, when I tried 4.0, the CGLib based proxies seemed to
have a final method that kept the proxies from being proxied as shadow
facts. So I rewrote my code to try to use JDK based proxies, and version
4.0 MR3 accepts them and apparently creates shadow facts, but now my
rules don't fire correctly.
So, in an attempt to create a simple program to illustrate the problem,
I ran into a different problem. The attached eclipse project illustrates
this problem.
The error is:
java.lang.NullPointerException
at org.drools.reteoo.Rete$ObjectTypeConf.init(Rete.java:333)
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 com.sample.DroolsTest.main(DroolsTest.java:42)
Has anyone successfully used JDK based dynamic proxies as facts?
Thanks,
-Chris West
--
___ 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
--
Вы уже с Yahoo!?
Испытайте обновленную и улучшенную Yahoo! Почту!
___
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] class nameShadowProxy
Sergey, ShadowProxy classes are not supposed to be visible outside the engine. What problem are you facing? []s Edson 2007/7/17, Manukyan, Sergey [EMAIL PROTECTED]: Folks, I am using MR3, my classes are being shadowed and I have something like class nameShadowProxy … I need to avoid that as my logic depends on class name, so I just need to disable shadowing right? How can I do that? 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
Re: [rules-users] The effect of not using shadow facts
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 [EMAIL PROTECTED]: 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 Tirellihttp://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@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] Re: Using JDK dynamic proxies as facts
Chris,
I'll try to dig it a little too. My problem is that I need to proxy concrete
classes as they are generated from XSD using Castor. If I find workaround I'll
let you know.
Oleg.
Chris West [EMAIL PROTECTED] wrote: Oleg,
So far I have not been successful. I've just posted my thoughts to this list
(under the subject The effect of not using shadow facts). Concerning the
class names, my rules only match on an interface type implemented by the
proxies, so the actual class type of the instance does not matter.
-Chris
On 7/13/07, Oleg Yavorsky [EMAIL PROTECTED] wrote: Chris,
I'm thinking about using dynamic proxies in my rules too. I'll be glad to hear
about your success with them. I think that there could be problem with matching
of facts as they won't be of original class but of Proxy$... one. CGLIB
approach doesn't have such problem as it just modifies original classes'
bytecode. I could be wrong, anyway.
Oleg.
Mark Proctor [EMAIL PROTECTED] wrote:That is not the only thing that
determines shadowing. If you look the shadowing is actually determined here:
if ( !ruleBase.getConfiguration().isShadowProxy() || cls == null
|| !ruleBase.getConfiguration().isShadowed( cls.getName() ) ) {
return;
}
By default shadowing is turned on for all (none final) bjects, except stuff in
the org.drools namespace, you have to set exclusion lists.too. So if your
package has a null namespace it will still attempt to shadow it.
Mark
Chris West wrote: OK, I just solved my own problem. My proxy had no package,
since the jdk based proxy is only in a package if it has at least 1 non public
interface, according to the javadoc.
The suspect code beginning on line 333 is:
String pkgName = cls.getPackage().getName();
if ( org.drools.reteoo.equals( pkgName ) ||
org.drools.base.equals( pkgName ) ) {
// We don't shadow internal classes
this.shadowEnabled = false;
return;
}
The getPackage() method returns null. In this case, it would be good if JBoss
Rules handled the null and went on to shadow the object anyway, since it is
obviously not in the org.drools packages.
Now I'll continue trying to build a test case for my original problem.
Shall I enter a JIRA for this issue?
Thanks,
-Chris West
On 7/12/07, Chris West [EMAIL PROTECTED] wrote:Hello,
I'm trying to use objects that are generated as dynamic proxies (through the
java.lang.reflect.Proxy class) as facts in JBoss Rules 4.0 MR3. My project was
using CGLib to generate proxies, and they were working just fine in 3.0.6.
However, when I tried 4.0, the CGLib based proxies seemed to have a final
method that kept the proxies from being proxied as shadow facts. So I rewrote
my code to try to use JDK based proxies, and version 4.0 MR3 accepts them and
apparently creates shadow facts, but now my rules don't fire correctly.
So, in an attempt to create a simple program to illustrate the problem, I ran
into a different problem. The attached eclipse project illustrates this
problem.
The error is:
java.lang.NullPointerException
at org.drools.reteoo.Rete$ObjectTypeConf.init(Rete.java:333)
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 com.sample.DroolsTest.main(DroolsTest.java:42)
Has anyone successfully used JDK based dynamic proxies as facts?
Thanks,
-Chris West
-
___ 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
-
Вы уже с Yahoo!?
Испытайте обновленную и улучшенную Yahoo! Почту!
___
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
-
Вы уже с Yahoo!? Испытайте обновленную и улучшенную. Yahoo! Почту!___
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
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 Tirellihttp://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]://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] Re: Using JDK dynamic proxies as facts
Oleg,
Are you generating the Castor classes on the fly? I am successfully using
Castor generated classes within the rules engine without any proxy classes.
My process is that I use the Castor ant task to generate objects based upon
my schema. I then develop my rules against the Castor generated objects.
These work just fine with stock JBoss Rules, so the question is why the
proxy classes?
Ron
On 7/17/07, Oleg Yavorsky [EMAIL PROTECTED] wrote:
Chris,
I'll try to dig it a little too. My problem is that I need to proxy
concrete classes as they are generated from XSD using Castor. If I find
workaround I'll let you know.
Oleg.
*Chris West [EMAIL PROTECTED]* wrote:
Oleg,
So far I have not been successful. I've just posted my thoughts to this
list (under the subject The effect of not using shadow facts). Concerning
the class names, my rules only match on an interface type implemented by the
proxies, so the actual class type of the instance does not matter.
-Chris
On 7/13/07, Oleg Yavorsky [EMAIL PROTECTED] wrote:
Chris,
I'm thinking about using dynamic proxies in my rules too. I'll be glad
to hear about your success with them. I think that there could be problem
with matching of facts as they won't be of original class but of Proxy$...
one. CGLIB approach doesn't have such problem as it just modifies original
classes' bytecode. I could be wrong, anyway.
Oleg.
*Mark Proctor [EMAIL PROTECTED] * wrote:
That is not the only thing that determines shadowing. If you look the
shadowing is actually determined here:
if ( !ruleBase.getConfiguration().isShadowProxy() || cls ==
null || !ruleBase.getConfiguration().isShadowed( cls.getName() ) ) {
return;
}
By default shadowing is turned on for all (none final) bjects, except
stuff in the org.drools namespace, you have to set exclusion lists.too.
So if your package has a null namespace it will still attempt to shadow it.
Mark
Chris West wrote:
OK, I just solved my own problem. My proxy had no package, since the
jdk based proxy is only in a package if it has at least 1 non public
interface, according to the javadoc.
The suspect code beginning on line 333 is:
String pkgName = cls.getPackage().getName();
if ( org.drools.reteoo.equals( pkgName ) ||
org.drools.base.equals( pkgName ) ) {
// We don't shadow internal classes
this.shadowEnabled = false;
return;
}
The getPackage() method returns null. In this case, it would be good if
JBoss Rules handled the null and went on to shadow the object anyway, since
it is obviously not in the org.drools packages.
Now I'll continue trying to build a test case for my original problem.
Shall I enter a JIRA for this issue?
Thanks,
-Chris West
On 7/12/07, Chris West [EMAIL PROTECTED] wrote:
Hello,
I'm trying to use objects that are generated as dynamic proxies
(through the java.lang.reflect.Proxy class) as facts in JBoss Rules
4.0 MR3. My project was using CGLib to generate proxies, and they
were working just fine in 3.0.6. However, when I tried 4.0, the CGLib
based proxies seemed to have a final method that kept the proxies from being
proxied as shadow facts. So I rewrote my code to try to use JDK based
proxies, and version 4.0 MR3 accepts them and apparently creates
shadow facts, but now my rules don't fire correctly.
So, in an attempt to create a simple program to illustrate the
problem, I ran into a different problem. The attached eclipse project
illustrates this problem.
The error is:
java.lang.NullPointerException
at org.drools.reteoo.Rete$ObjectTypeConf.init(Rete.java:333)
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 com.sample.DroolsTest.main(DroolsTest.java:42)
Has anyone successfully used JDK based dynamic proxies as facts?
Thanks,
-Chris West
--
___ 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
--
Вы уже с Yahoo!?
Испытайте обновленную и улучшенную Yahoo! Почту!
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing
Re: [rules-users] The effect of not using shadow facts
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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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 Tirellihttp://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
[rules-users] frequency of digest posts
Why is it that the digest comes almost as frequently as individual emails? I've received eight separate digest emails in the last five hours, and I can only assume I'll get another ten or so by the end of the day? I subscribe because I like to keep up on what's going on with JBoss Rules, but there is a reason I chose digest as my delivery option, after all. Can an admin throttle the flow a little bit? It seems like someone has defined a threshhold whereby if 2 KB of text accumulate, it's time to drain the queue and send out a digest. Thanks, Matt Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545469 ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
RE: [rules-users] class nameShadowProxy
Edson,
The problem is for example: I have a classes that I use with
persistance broker (OJB)
class Parent {
private Child child;
public Child getChild() {
OJBBeanManager.retrieveReferenceIfNull(this,child);
return child;
}
}
He OJB broker then does this.getClass().getName() - to get name of class
requesting update of it's reference and depending on the name it
requests a proper datasource to get broker to perform transaction.
The name should be Parent, but it gets ParentShadowProxy, and cannot
find it in datasource configuration.
Can I disable shadowing somehow? Or what shall I do...?
-Sergey
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Edson Tirelli
Sent: Tuesday, July 17, 2007 12:20 PM
To: Rules Users List
Subject: Re: [rules-users] class nameShadowProxy
Sergey,
ShadowProxy classes are not supposed to be visible outside the
engine. What problem are you facing?
[]s
Edson
2007/7/17, Manukyan, Sergey [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] :
Folks,
I am using MR3, my classes are being shadowed and I have something like
class nameShadowProxy ... I need to avoid that as my logic depends
on class name, so I just need to disable shadowing right?
How can I do that?
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
Re: [rules-users] The effect of not using shadow facts
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
Tirellihttp://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
Ответ: Re: [rules-users] Re: Using JDK d ynamic proxies as facts
Ronald,
I use Ant task too but in my usecase I'd like to add additional property to
objects on a fly (actually collection of parents) so I can check it on a LHS.
Currently I use eval on external objects (identity map with child and
associated parents). I don't know yet if this approach viable at all but if I
manage to add such a property I'll get rid of eval thus having advantages of
properties caching and indexing. Time will show...
Oleg.
Ronald R. DiFrango [EMAIL PROTECTED] wrote: Oleg,
Are you generating the Castor classes on the fly? I am successfully using
Castor generated classes within the rules engine without any proxy classes. My
process is that I use the Castor ant task to generate objects based upon my
schema. I then develop my rules against the Castor generated objects. These
work just fine with stock JBoss Rules, so the question is why the proxy
classes?
Ron
On 7/17/07, Oleg Yavorsky [EMAIL PROTECTED] wrote: Chris,
I'll try to dig it a little too. My problem is that I need to proxy concrete
classes as they are generated from XSD using Castor. If I find workaround I'll
let you know.
Oleg.
Chris West [EMAIL PROTECTED] wrote:
Oleg,
So far I have not been successful. I've just posted my thoughts to this list
(under the subject The effect of not using shadow facts). Concerning the
class names, my rules only match on an interface type implemented by the
proxies, so the actual class type of the instance does not matter.
-Chris
On 7/13/07, Oleg Yavorsky [EMAIL PROTECTED] wrote: Chris,
I'm thinking about using dynamic proxies in my rules too. I'll be glad to hear
about your success with them. I think that there could be problem with matching
of facts as they won't be of original class but of Proxy$... one. CGLIB
approach doesn't have such problem as it just modifies original classes'
bytecode. I could be wrong, anyway.
Oleg.
Mark Proctor [EMAIL PROTECTED] wrote: That is not the only thing
that determines shadowing. If you look the shadowing is actually determined
here:
if ( !ruleBase.getConfiguration().isShadowProxy() || cls == null
|| !ruleBase.getConfiguration().isShadowed( cls.getName() ) ) {
return;
}
By default shadowing is turned on for all (none final) bjects, except stuff in
the org.drools namespace, you have to set exclusion lists.too. So if your
package has a null namespace it will still attempt to shadow it.
Mark
Chris West wrote: OK, I just solved my own problem. My proxy had no package,
since the jdk based proxy is only in a package if it has at least 1 non public
interface, according to the javadoc.
The suspect code beginning on line 333 is:
String pkgName = cls.getPackage().getName();
if ( org.drools.reteoo.equals( pkgName ) ||
org.drools.base.equals( pkgName ) ) {
// We don't shadow internal classes
this.shadowEnabled = false;
return;
}
The getPackage() method returns null. In this case, it would be good if JBoss
Rules handled the null and went on to shadow the object anyway, since it is
obviously not in the org.drools packages.
Now I'll continue trying to build a test case for my original problem.
Shall I enter a JIRA for this issue?
Thanks,
-Chris West
On 7/12/07, Chris West [EMAIL PROTECTED] wrote: Hello,
I'm trying to use objects that are generated as dynamic proxies (through the
java.lang.reflect.Proxy class) as facts in JBoss Rules 4.0 MR3. My project was
using CGLib to generate proxies, and they were working just fine in 3.0.6.
However, when I tried 4.0, the CGLib based proxies seemed to have a final
method that kept the proxies from being proxied as shadow facts. So I rewrote
my code to try to use JDK based proxies, and version 4.0 MR3 accepts them and
apparently creates shadow facts, but now my rules don't fire correctly.
So, in an attempt to create a simple program to illustrate the problem, I ran
into a different problem. The attached eclipse project illustrates this
problem.
The error is:
java.lang.NullPointerException
at org.drools.reteoo.Rete$ObjectTypeConf.init(Rete.java:333)
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 com.sample.DroolsTest.main (DroolsTest.java:42)
Has anyone successfully used JDK based dynamic proxies as facts?
Thanks,
-Chris West
-
___
Re: [rules-users] The effect of not using shadow facts
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
Tirellihttp://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
Re: [rules-users] NoClassDefFoundError for BaseObjectClassFieldExtractor when running in Tomcat
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
