[rules-users] Simple question
Hi, I am having trouble with accessing two same objects with different data in working memory. When I print the list of working memory I see two objects: Com.model.PersonTO Com.model.PersonTO But I am not sure how to access each of them individually e.g; Person object exists = person: PersonTO() Please help. Saleem Lakhani ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Problems using shadow proxies and Hibernate lazy initialization
Edson, Thanks for the reply. I took a look at your post regarding how to retract then modify the fact, but I have a different situation. I need to modify the fact via a function call. This is because inside the function I have access to Spring-managed services that I use to retrieve domain objects from the data access layer that I can then set (i.e., modify) on the domain object (or fact, as referred to in Drools). So, right now, my consequence looks like the following: drools.modifyRetract($loan); functionNameThatModifiesLoan($loan); drools.modifyInsert($loan); Does this, in effect, do the same thing that your posting shows how to do. In other words, can I retract the fact, modify it, then insert it back into the Drools engine this way? BTW, I will be more than happy to open a JIRA. I just want to make sure that what I am doing in my consequence is correct first since the modifyRetract() and modifyAssert(), which will be changed to modifyInsert() via the JIRA, is how the user guide currently describes how this should be done, not the way your posting describes. On 4/2/08, Edson Tirelli [EMAIL PROTECTED] wrote: It seems the docs need to be updated. Would you plz open a JIRA to fix the place you are seeing this info? For more current info, take a look at this blog post, specially the end on how to disable shadow facts: http://blog.athico.com/2008/02/shadow-facts-what-you-always-wanted-to.html []s Edson 2008/4/2, Keith Bennett [EMAIL PROTECTED]: I am currently using Drools to validate an extensive object graph. When I validate a transient object graph (i.e., not persisted via Hibernate) inside of a JUnit test method, validation occurs successfully. However, when I retrieve the same object graph from Hibernate and subsequently validate it, I get the stack trace that I've included below, but only when I use shadow proxies. When I turn shadow proxies off, validation runs successfully against the persisted object graph again. Of course, I'm utilizing lazy association fetching to improve performance and want to continue utilizing it. Has anyone run into this same problem, and if so, were you able to work around it without turning shadow proxies off? Before you ask, my Hibernate session is open before and after I invoke Drools to perform validation in the same unit of work (i.e., transaction), so it's not an issue of not having an active Hibernate session available (I've verified this through testing). One more thing. The user guide says that if shadow proxies are turned off that modifyRetract() should be called before an object is modified and modifyAssert() should be called after it is modifed. First, what is the method parameter to these two overloaded methods, Object or FactHandle (both exist)? Second, I don't see modifyAssert() available in the library, just modifyInsert(). Should the documentation change to read modifyInsert() instead of modifyAssert()? If so, again with which parameter? I appreciate any insight you may have! Here's the stack trace: org.hibernate.LazyInitializationException: failed to lazily initialize a collection, no session or session was closed at org.hibernate.collection.AbstractPersistentCollection.throwLazyInitializationException(AbstractPersistentCollection.java:358) at org.hibernate.collection.AbstractPersistentCollection.throwLazyInitializationExceptionIfNotConnected(AbstractPersistentCollection.java:350) at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:343) at org.hibernate.collection.PersistentSet.addAll(PersistentSet.java:244) at org.drools.util.ShadowProxyUtils.cloneObject(ShadowProxyUtils.java:76) at com.cbi.domain.loan.indirect.IndirectLoanShadowProxy.getCustomers(Unknown Source) at org.drools.base.com.cbi.domain.loan.indirect.IndirectLoan28409161$getCustomers.getValue(Unknown Source) at org.drools.base.ClassFieldExtractor.getValue(ClassFieldExtractor.java:127) at org.drools.rule.Declaration.getValue(Declaration.java:198) at LoanValidationBusinessRules.Rule_A_Loan_must_have_at_least_one_Customer_0Eval0Invoker.evaluate(Rule_A_Loan_must_have_at_least_one_Customer_0Eval0Invoker.java:12) at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:72) at org.drools.reteoo.EvalConditionNode.assertTuple(EvalConditionNode.java:145) at org.drools.reteoo.CompositeTupleSinkAdapter.createAndPropagateAssertTuple(CompositeTupleSinkAdapter.java:73) at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:116) at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:318) at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:153) at
[rules-users] Short circuiting evaluations on LHS
I am currently using Drools 4.0 to determine the best choice out of a data set based on business rules. The rules eliminate (retract) facts until a single fact survives, and is used for additional processing. I have found Drools to be a great solution for this problem, and plan to role it out for additional survivor rules. My problem is in optimization - this is essentially a batch processing application, and speed is very important (of course it is - show me the case where it isn't, right?). Some of the later evaluations in the rules are fairly expensive (invoking complex queries from the database), and generally apply to only a small set of the use cases. For most use cases, the survivor will have been determined after the first or second rule, so I only want to perform the expensive evaluations if necessary. I have not found a way to avoid or schedule the LHS evaluations from firing when inserting the fact into the working memory. I have played around with agenda groups and rule flows, but haven't had any luck. The only way I can think of at this point is to break my rules into separate rule bases, and manually copy survivors from one working memory to the next, performing my own short circuiting outside of the rules being fired. Is there any other technique that I have missed? From a maintenance standpoint, I would prefer to be able to use one rule base/rule flow to manage the rules (there are only about 10 total rules, so the base is not very large - and I would have to break it into 4 or 5 different rule bases, which seems like it will be a pain across the 5 different areas I need to implement the rules.) Thanks, -Jason The information transmitted (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is intended only for the person(s) or entity/entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Rule Compilation - Thread deadlock possibility?
I have a class DroolsRuleLocator that fetches rules from the database,
compiles and hands me back the RuleBase. At this time I have just one rule
file with a bunch of rules in them. I do not experience any issues when I
execute that in a single thread.
But when I load test my application and the client is passing in the request
that requires *lookup and compilation of the same rule source in my server
concurrently but on different threads,* it appears that my application is
dead locked trying to compile the rules.
Relevant Rule compilation code:
RuleBase ruleBase = RuleBaseFactory.newRuleBase();
try {
// Rule is a simple java bean containing the rule text.
for (Rule rule : rules) {
// ruleDefinition will contain the contents of the drl
source.
String ruleDefinition = rule.getRuleText();
PackageBuilder builder = new PackageBuilder();
// Parse and compile in one step
builder.addPackageFromDrl(new StringReader(ruleDefinition));
if (builder.hasErrors()) {
throw new RuntimeException(Unable to compile rule
definition: + rule.getName());
}
// Get the compiled package (which is serializable)
Package pkg = builder.getPackage();
// Add the package to the created rulebase (deploy the rule
package).
ruleBase.addPackage(pkg);
}
}
Remote attaching to the tomcat server and suspending the hanging threads
shows the following trace.
Daemon Thread [http-8080-58] (Suspended)
owns: PhaseInterceptorChain (id=315)
waiting for: StandardClassLoader (id=244)
owned by: Daemon Thread [http-8080-62]
(Running)
StandardClassLoader(ClassLoader).loadClass(String, boolean)
line: not available
StandardClassLoader(ClassLoader).loadClass(String) line: not
available
WebappClassLoader.loadClass(String, boolean) line: 1349
WebappClassLoader.loadClass(String) line: 1208
ParserContext.checkForDynamicImport(String) line: 121
ParserContext.hasImport(String) line: 155
ExpressionCompiler(AbstractParser).createPropertyToken(int, int)
line: 893
ExpressionCompiler(AbstractParser).nextToken() line:
836
ExpressionCompiler._compile() line: 80
ExpressionCompiler.compile(ParserContext) line: 44
MVELExprAnalyzer.analyzeExpression(RuleBuildContext, String,
Set[], Map) line: 85
MVELDialect.analyzeExpression(RuleBuildContext, BaseDescr,
Object, Map) line: 320
MVELDialect.analyzeExpression(RuleBuildContext, BaseDescr,
Object) line: 308
MVELFromBuilder.build(RuleBuildContext, BaseDescr, Pattern)
line: 71
MVELFromBuilder.build(RuleBuildContext, BaseDescr) line: 50
PatternBuilder.build(RuleBuildContext, BaseDescr, Pattern) line:
172
PatternBuilder.build(RuleBuildContext, BaseDescr) line:
87
GroupElementBuilder.build(RuleBuildContext, BaseDescr, Pattern)
line: 69
RuleBuilder.build(RuleBuildContext) line: 53
PackageBuilder.addRule(RuleDescr) line: 446
PackageBuilder.addPackage(PackageDescr) line: 304
PackageBuilder.addPackageFromDrl(Reader) line: 167
DroolsRuleLocator.findRuleBase(long, String) line: 122
Can someone clarify if this dead lock scenario is a possibility. Currently
I am sychronizing on the method that compiles and returns the RuleBase to
avoid this situation.
Thanks.
- Krishna
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] what is the current drools release?
What's the most current drools release? There's discussion of 4.0.5 and 4.0.6 in the email below, which dates from 26-Mar-2008, but http://labs.jboss.com/drools/downloads.html lists 4.0.4 as having been released 31-Mar-2008 and does not mention 4.0.5 and 4.0.6. Thanks. - Godmar On Wed, Mar 26, 2008 at 9:20 AM, Mark Proctor [EMAIL PROTECTED] wrote: Sounds like when the MVEL author release 1.2.24 he didn't do a valid pom.xml - I'll let him know. There is also another problem with the 4.0.5 and the MVEL eclipse configuration - see email thread below. I'm going to push for a 4.0.6 release next week, to address this. 1.2.25 or 1.2.24 is fine - as long as you always use the same version for everything, they aren't serialisation compatible. Sorry. Eric Miles wrote: I am attempting to build a project using Maven2 with Drools 4.0.5 and JDK 1.4. The MVEL dependency was downloaded and I'm getting an error with it's pom: mvel-1.2.24-java1.4.pom 3/26/08 8:51:09 AM EDT: Parsing error /home/emiles/.m2/repository/org/mvel/mvel/1.2.24-java1.4/mvel-1.2.24-java1.4.pom; org.codehaus.plexus.util.xml.pull.XmlPullParserException: end tag name /pakaging must match start tag name packaging from line 6 (position: TEXT seen ...packagingjar/pakaging... @6:30) 3/26/08 8:51:09 AM EDT: Unable to read smarttime/pom.xml; org.eclipse.core.runtime.CoreException: Parsing error /home/emiles/.m2/repository/org/mvel/mvel/1.2.24-java1.4/mvel-1.2.24-java1.4.pom; org.codehaus.plexus.util.xml.pull.XmlPullParserException: end tag name /pakaging must match start tag name packaging from line 6 (position: TEXT seen ...packagingjar/pakaging... @6:30) I excluded version 1.2.24 and used 1.2.25 instead, which fixes my build path errors. Is this version okay to use with Drools 4.0.5? Thanks! Eric The mvel release is screwed up. dependency groupIdorg.mvel/groupId artifactIdmvel/artifactId version1.2.24-java1.4/version /dependency Our mvel, for the 1.4 backport, has always been called mve14 - as we've done the releases ourselves in the past. dependency groupIdorg.mvel/groupId artifactIdmvel14/artifactId version1.2.21/version /dependency So now when eclipse does the version stripping it includes mvel.jar and not mvel14.jar, leaving it screwed. Mark ___ 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] what is the current drools release?
Both 4.0.5 and 4.0.6 where bad releases, poor QA, so we rolled back to 4.0.4. Edson and I will take care of 4.0.7 QA ourselves and make sure its a good release, we will put it out on monday. Sorry Mark Godmar Back wrote: What's the most current drools release? There's discussion of 4.0.5 and 4.0.6 in the email below, which dates from 26-Mar-2008, but http://labs.jboss.com/drools/downloads.html lists 4.0.4 as having been released 31-Mar-2008 and does not mention 4.0.5 and 4.0.6. Thanks. - Godmar On Wed, Mar 26, 2008 at 9:20 AM, Mark Proctor [EMAIL PROTECTED] wrote: Sounds like when the MVEL author release 1.2.24 he didn't do a valid pom.xml - I'll let him know. There is also another problem with the 4.0.5 and the MVEL eclipse configuration - see email thread below. I'm going to push for a 4.0.6 release next week, to address this. 1.2.25 or 1.2.24 is fine - as long as you always use the same version for everything, they aren't serialisation compatible. Sorry. Eric Miles wrote: I am attempting to build a project using Maven2 with Drools 4.0.5 and JDK 1.4. The MVEL dependency was downloaded and I'm getting an error with it's pom: mvel-1.2.24-java1.4.pom 3/26/08 8:51:09 AM EDT: Parsing error /home/emiles/.m2/repository/org/mvel/mvel/1.2.24-java1.4/mvel-1.2.24-java1.4.pom; org.codehaus.plexus.util.xml.pull.XmlPullParserException: end tag name /pakaging must match start tag name packaging from line 6 (position: TEXT seen ...packagingjar/pakaging... @6:30) 3/26/08 8:51:09 AM EDT: Unable to read smarttime/pom.xml; org.eclipse.core.runtime.CoreException: Parsing error /home/emiles/.m2/repository/org/mvel/mvel/1.2.24-java1.4/mvel-1.2.24-java1.4.pom; org.codehaus.plexus.util.xml.pull.XmlPullParserException: end tag name /pakaging must match start tag name packaging from line 6 (position: TEXT seen ...packagingjar/pakaging... @6:30) I excluded version 1.2.24 and used 1.2.25 instead, which fixes my build path errors. Is this version okay to use with Drools 4.0.5? Thanks! Eric The mvel release is screwed up. dependency groupIdorg.mvel/groupId artifactIdmvel/artifactId version1.2.24-java1.4/version /dependency Our mvel, for the 1.4 backport, has always been called mve14 - as we've done the releases ourselves in the past. dependency groupIdorg.mvel/groupId artifactIdmvel14/artifactId version1.2.21/version /dependency So now when eclipse does the version stripping it includes mvel.jar and not mvel14.jar, leaving it screwed. Mark ___ 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
