Re: [rules-users] Event and Facts Problem
Thank you! That is right... It was my fault by posting the wrong code of mine. I used to modify the event itself, which isn't the right way since they are immuteable, and getting the same error. But with retract($request) it is working properly ;) -- View this message in context: http://drools.46999.n3.nabble.com/Event-and-Facts-Problem-tp4024622p4024698.html Sent from the Drools: User forum 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] Drools Guvnor got hang
Any update on this.
On Mon, Jul 1, 2013 at 12:44 PM, krishna prasad As
krishnaprasa...@gmail.com wrote:
Hi,
I'm using Drools Guvnor 5.4.0.Final for my production application. It was
running fine But today the guvnor got hung and when I tried to restart it,
got the following error in tomcat's(6.0.24) localhost log,
Jul 1, 2013 7:14:31 AM org.apache.catalina.session.StandardSession
writeObject
WARNING: Cannot serialize session attribute
org.jboss.weld.context.http.HttpSessionContext#org.jboss.weld.bean-flat-ManagedBean-org.jboss.seam.security.IdentityImpl[@javax.enterprise.context.SessionScoped()@javax.inject.Named(value=identity)@org.jboss.solder.config.xml.core.XmlConfiguredBean()@org.jboss.solder.config.xml.core.XmlId(value=1)]{org.jboss.seam.security.IdentityImpl.authenticators[@javax.enterprise.inject.Any()@javax.inject.Inject()];org.jboss.seam.security.IdentityImpl.beanManager[@javax.inject.Inject()];org.jboss.seam.security.IdentityImpl.credentials[@javax.inject.Inject()];org.jboss.seam.security.IdentityImpl.permissionMapper[@javax.inject.Inject()];org.jboss.seam.security.IdentityImpl.requestSecurityState[@javax.inject.Inject()];org.jboss.seam.security.IdentityImpl.session[@javax.inject.Inject()];org.jboss.seam.security.IdentityImpl.deferredAuthenticationObserver(org.jboss.seam.security.events.DeferredAuthenticationEvent[@javax.enterprise.event.Observes(during=IN_PROGRESS,notifyObserver=ALWAYS)]);}
for session 82B9B573DFBB2E9E7470649A1A5441E3
java.io.NotSerializableException: org.drools.repository.RulesRepository
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
at java.util.ArrayList.writeObject(ArrayList.java:570)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
at
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:416)
at
java.util.Collections$SynchronizedCollection.writeObject(Collections.java:1602)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
at
org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:1546)
at
org.apache.catalina.session.StandardSession.writeObjectData(StandardSession.java:989)
at
org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:517)
at
org.apache.catalina.session.StandardManager.unload(StandardManager.java:463)
at
org.apache.catalina.session.StandardManager.stop(StandardManager.java:667)
at
Re: [rules-users] drools migration
Have you checked that the jars have been downloaded in your local repository ? -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-drools-migration-tp4024691p4024707.html Sent from the Drools: User forum 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] Upgrade from drools 5.4 to 6.0.0-Beta3 - Legacy API Adapter JAR
Hi,
There is not enough documentation on drools v6.0.0-Beta3, but this is what
I'm trying to do.
Our system was designed with 5.3 but then we encountered the issue with
synchronization (https://issues.jboss.org/browse/JBRULES-3283), so we
upgraded to v 5.4.
Things worked fine until we multithreaded the client code due to which we
faced another issue (https://issues.jboss.org/browse/JBRULES-3675)
So finally now, I'm trying to upgrade to 6.0.0-Beta3 since both those issues
should've been fixed with 6.0.0-Alpha1. The problem I'm facing is, I do not
have enough documentation to look at to see how to convert those things. I
went through the slides etc that were posted on the mailing list for the
conferences, but I'm still unable to figure it out correctly..
So, can someone point me to a JUnit or something that I can look at to
figure this thing out?
static {
KieServices ks = KieServices.Factory.get();
KieRepository kr = ks.getRepository();
Resource res = ks.getResources().newFileSystemResource(
src/main/resources/rules/abc.drl);
KieModule kModule = kr.addKieModule(res);
kc = ks.newKieContainer(kModule.getReleaseId());
}
throws an exception on kr.addKieModule(res) which says Error in opening zip
file.. I assume we are now expecting a jar instead of a plain drl file. Is
there a way to convert this drl into a jar that the 6.0 code can understand
(for compatibility purposes with the existing system)?
Another thought was to make use of the Legacy API Adapter JAR, but I
couldn't find any examples of the same. Can you point me to a code
sample/JUnit that could explain how this works?
Thanks
--
View this message in context:
http://drools.46999.n3.nabble.com/Upgrade-from-drools-5-4-to-6-0-0-Beta3-Legacy-API-Adapter-JAR-tp4024713.html
Sent from the Drools: User forum 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] drools migration
Yes, the dependencies are in my local repo. I changed the way we read the DRL files, I need to use KnowledgeBase classes. Once I am done with that, I updated the antlr version as well in the maven dependencies. Now I am stuck at other point. In some of the rules, we have ArrayList() from collect() in the when part and we retract them in the when part of the rule. I am getting ConsequenceException now which is Caused by: java.util.ConcurrentModificationException. -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-drools-migration-tp4024691p4024714.html Sent from the Drools: User forum 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] Timers and fireAllRules
I'm grateful for the clarification that the timer behavior is changing in Drools 6. I was planning on exploiting the Drools 5 behavior to fire certain rules asynchronously at intervals using a timer, even when the engine was otherwise idle. I don't want to use fireUntilHalt because I need to make numerous updates to facts in a batch in Java code, and I don't want any rules to fire prematurely. To prepare for Drools 6, then, it looks like I should use Java to implement the timer, update the working memory, and call fireAllRules. I'd prefer to be able to specify this declaratively in the DRL file as I can now in Drools 5, but since I want to future-proof my code I'll need a different approach. Best wishes, Tom From: rules-users-boun...@lists.jboss.org [mailto:rules-users-boun...@lists.jboss.org] On Behalf Of Wolfgang Laun Sent: Monday, June 24, 2013 4:02 PM To: Rules Users List Subject: Re: [rules-users] Timers and fireAllRules You just make sure that the documentation for 5.x remains as I've added it, and that it is updated accordingly for the 6.x Expert manual. I don't think that the behaviour in 5.x when fireAllRules() is called and repeating timers execute their tasks even when the Engine is idle is evil. The general flow of logic is consistent even though some executions happen later compared to what would happen when running in fireUntilHalt. But you can indeed uphold the position that any timer activity is in conflict with the Engine being suspended after fireAllRules() returns. But what should be the consequence? Delay the return? Terminate the timers? Disallow timers being launched in a run initiated by fireAllRules()? Let's hope that 6.x reacts cleanly... -W On 24 June 2013 21:05, Mark Proctor mproc...@codehaus.orgmailto:mproc...@codehaus.org wrote: btw sorry about the confusion. The reason was we have changed the behaviour in 6, and in the mean time I'd forgotten what the exact behaviour was in 5. In 6.x there is no async behaviour, for fireAllRules, all action happens in the user thread. So there will be no rule firing if fireAllRules (passive mode) is not called, or you are not using fireUntilHalt (reactive mode). There have been several discussion on IRC, and the conclusion was were very uncomfortable with async operations of timers, in passive mode. If people want reactive behaviour, they should use the engine in reactive mode, if they want passive behaviour, they should use the engine in passive mode. Timers are no longer part of Agenda, and instead we have a TimerNode that lives in the network. It's role is simply to control tuple propagation. The code is a lot simpler and more isolated than 5.x, this is also very helpful (if not necessary) in the multi-core work we plan to do. https://github.com/droolsjbpm/drools/blob/master/drools-core/src/main/java/org/drools/core/phreak/PhreakTimerNode.java We do think there may be some future use cases for a mixed hybrid/passive execution mode. Where some rules are passive, some reactive, but we'd rather that we found a way to do this declaratively. Mark On 22 Jun 2013, at 07:17, Wolfgang Laun wolfgang.l...@gmail.commailto:wolfgang.l...@gmail.com wrote: Added to Chapter-LanguageReferencehttps://github.com/droolsjbpm/drools/tree/master/drools-docs/drools-expert-docs/src/main/docbook/en-US/Chapter-LanguageReference / Section-Rule.xml on master. -W On 20 June 2013 22:55, Wolfgang Laun wolfgang.l...@gmail.commailto:wolfgang.l...@gmail.com wrote: OK, and now? You can wrap it into a couple of docbook tags and add it to the Expert manual, I'm not reserving the copyright ;-) -W On 20 June 2013 21:29, Mark Proctor mproc...@codehaus.orgmailto:mproc...@codehaus.org wrote: I assumed you were quoting from some documentation. Mark On 20 Jun 2013, at 17:08, Wolfgang Laun wolfgang.l...@gmail.commailto:wolfgang.l...@gmail.com wrote: You sound absolutely sibyllic. Which documentation will you update - I'm not aware of any documentation describing the behaviour of timers. What, in your opinion, was the behaviour in an older version? And what older version are you referring to anyway? I've ascertained that what I described is the behaviour in 5.1.1, 5.2.0, 5.3.0, 5.4.0 and 5.5.0. And: where is it written that execution tied to a repeating timer must be constrained within fireAllRules? I could make a very good case for arguing that RHS executions due to timer expiry aren't firing in the classic sense - that's just what happens when the LHS matches. -W On 20 June 2013 15:44, Mark Proctor mproc...@codehaus.orgmailto:mproc...@codehaus.org wrote: We'll update the documentation, that was probably the behaviour in an older version. The behaviour should not have rules async firing, unless there is proper async controls, as with fireUntilHalt, otherwise the firings must be constrained within fireAllRules. Mark On 20 Jun 2013, at 12:04, Wolfgang Laun wolfgang.l...@gmail.commailto:wolfgang.l...@gmail.com
Re: [rules-users] drools migration
I ran into a similar issue a while ago and had to rewrite the rule on how it deals with collection object as facts. Maybe, if you post your rule, I can try to suggest. -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-drools-migration-tp4024691p4024716.html Sent from the Drools: User forum 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] Timers and fireAllRules
Timers not continuing to fire after fireUntilHalt returns makes this feature unusable for us, too. :-[ We see timer-controlled firing as a sustained firing, maintaining a sort of frozen state. If some process is tied to Time, halting a rule engine is a minor event. -W On 02/07/2013, Thomas Grayson tgray...@bluemetal.com wrote: I'm grateful for the clarification that the timer behavior is changing in Drools 6. I was planning on exploiting the Drools 5 behavior to fire certain rules asynchronously at intervals using a timer, even when the engine was otherwise idle. I don't want to use fireUntilHalt because I need to make numerous updates to facts in a batch in Java code, and I don't want any rules to fire prematurely. To prepare for Drools 6, then, it looks like I should use Java to implement the timer, update the working memory, and call fireAllRules. I'd prefer to be able to specify this declaratively in the DRL file as I can now in Drools 5, but since I want to future-proof my code I'll need a different approach. Best wishes, Tom From: rules-users-boun...@lists.jboss.org [mailto:rules-users-boun...@lists.jboss.org] On Behalf Of Wolfgang Laun Sent: Monday, June 24, 2013 4:02 PM To: Rules Users List Subject: Re: [rules-users] Timers and fireAllRules You just make sure that the documentation for 5.x remains as I've added it, and that it is updated accordingly for the 6.x Expert manual. I don't think that the behaviour in 5.x when fireAllRules() is called and repeating timers execute their tasks even when the Engine is idle is evil. The general flow of logic is consistent even though some executions happen later compared to what would happen when running in fireUntilHalt. But you can indeed uphold the position that any timer activity is in conflict with the Engine being suspended after fireAllRules() returns. But what should be the consequence? Delay the return? Terminate the timers? Disallow timers being launched in a run initiated by fireAllRules()? Let's hope that 6.x reacts cleanly... -W On 24 June 2013 21:05, Mark Proctor mproc...@codehaus.orgmailto:mproc...@codehaus.org wrote: btw sorry about the confusion. The reason was we have changed the behaviour in 6, and in the mean time I'd forgotten what the exact behaviour was in 5. In 6.x there is no async behaviour, for fireAllRules, all action happens in the user thread. So there will be no rule firing if fireAllRules (passive mode) is not called, or you are not using fireUntilHalt (reactive mode). There have been several discussion on IRC, and the conclusion was were very uncomfortable with async operations of timers, in passive mode. If people want reactive behaviour, they should use the engine in reactive mode, if they want passive behaviour, they should use the engine in passive mode. Timers are no longer part of Agenda, and instead we have a TimerNode that lives in the network. It's role is simply to control tuple propagation. The code is a lot simpler and more isolated than 5.x, this is also very helpful (if not necessary) in the multi-core work we plan to do. https://github.com/droolsjbpm/drools/blob/master/drools-core/src/main/java/org/drools/core/phreak/PhreakTimerNode.java We do think there may be some future use cases for a mixed hybrid/passive execution mode. Where some rules are passive, some reactive, but we'd rather that we found a way to do this declaratively. Mark On 22 Jun 2013, at 07:17, Wolfgang Laun wolfgang.l...@gmail.commailto:wolfgang.l...@gmail.com wrote: Added to Chapter-LanguageReferencehttps://github.com/droolsjbpm/drools/tree/master/drools-docs/drools-expert-docs/src/main/docbook/en-US/Chapter-LanguageReference / Section-Rule.xml on master. -W On 20 June 2013 22:55, Wolfgang Laun wolfgang.l...@gmail.commailto:wolfgang.l...@gmail.com wrote: OK, and now? You can wrap it into a couple of docbook tags and add it to the Expert manual, I'm not reserving the copyright ;-) -W On 20 June 2013 21:29, Mark Proctor mproc...@codehaus.orgmailto:mproc...@codehaus.org wrote: I assumed you were quoting from some documentation. Mark On 20 Jun 2013, at 17:08, Wolfgang Laun wolfgang.l...@gmail.commailto:wolfgang.l...@gmail.com wrote: You sound absolutely sibyllic. Which documentation will you update - I'm not aware of any documentation describing the behaviour of timers. What, in your opinion, was the behaviour in an older version? And what older version are you referring to anyway? I've ascertained that what I described is the behaviour in 5.1.1, 5.2.0, 5.3.0, 5.4.0 and 5.5.0. And: where is it written that execution tied to a repeating timer must be constrained within fireAllRules? I could make a very good case for arguing that RHS executions due to timer expiry aren't firing in the classic sense - that's just what happens when the LHS matches. -W On 20 June 2013 15:44, Mark Proctor mproc...@codehaus.orgmailto:mproc...@codehaus.org wrote:
Re: [rules-users] drools migration
Thanks for your reply.
Here is a rule:
rule US authorities
lock-on-active true
when
$trx : TransactionWrapper(ignoreSourceLocation == false)
$fromState : TAyWrapper ( authorityType == TAType.STATE || authorityType
== TAType.COUNTRY, locationType == LocationType.ORIGIN )
$toState : TAWrapper ( authorityType == TAType.STATE || authorityType ==
TAType.COUNTRY, locationType == LocationType.DESTINATION, code !=
$fromState.code )
$removableAuthorities : ArrayList() from collect(TAWrapper( locationType
== LocationType.ORIGIN ))
then
for(Object ta: $removableAuthorities){
retract (ta);
}
end
Basically it is not retracting a fact. I do not know what is the problem.
I have changed the version from 5.2 to 5.5.0 Final(Now I am not getting any
exception, but I could see that the fact is still there)
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-drools-migration-tp4024691p4024718.html
Sent from the Drools: User forum 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] drools migration
This seems to be an equivalent rule removing the need for collect... when $trx : TransactionWrapper(ignoreSourceLocation == false) $fromState : TAWrapper ( authorityType == TAType.STATE || authorityType == TAType.COUNTRY, locationType == LocationType.ORIGIN ) $toState : TAWrapper ( authorityType == TAType.STATE || authorityType == TAType.COUNTRY, locationType == LocationType.DESTINATION, code != $fromState.code ) $removableAuthority : TAWrapper( locationType == LocationType.ORIGIN ) then retract ($removableAuthority); end You know your domain better :) but maybe this is what was meant?... when $trx : TransactionWrapper(ignoreSourceLocation == false) $fromState : TAWrapper ( authorityType == TAType.STATE || authorityType == TAType.COUNTRY, locationType == LocationType.ORIGIN ) $toState : TAWrapper ( authorityType == TAType.STATE || authorityType == TAType.COUNTRY, locationType == LocationType.DESTINATION, code != $fromState.code ) then retract (fromState); end Good luck!!! -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-drools-migration-tp4024691p4024719.html Sent from the Drools: User forum 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] drools migration
Thanks, I see what you are saying. I am trying that out. But I am wondering why the drools versions are not backward compatible. But all these rules were written a long back. And I was trying not to change the same. I need to build an application which will have rules per client kind of thing. So I would need to have a UI to create rules and also store them in database. I have seen some examples of using Guvnor and the db to store rules with the newer versions of the drools. When I upgraded the versions, my existing rules start breaking :( -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-drools-migration-tp4024691p4024720.html Sent from the Drools: User forum 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] drools migration
Also I am looking at the domain objects for this: And I need to retract all the objects with locationType == LocationType.ORIGIN the fromState is one of them. But there would be more of the same. I think that is the reason the collect is in there. -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-drools-migration-tp4024691p4024721.html Sent from the Drools: User forum 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] guvnor-webapp war file download
Hi, I would like to integrate guvnor with in my web app. I have read the documentation and seen that we need to deploy this as a separate web application on server. And then embed using IFrame.. But I am unable to locate the war file. Let me know where I can find the guvnor web app war file. Thanks, RR -- View this message in context: http://drools.46999.n3.nabble.com/guvnor-webapp-war-file-download-tp4024722.html Sent from the Drools: User forum 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] guvnor-webapp war file download
Ignore this post. I got the war file. http://mvnrepository.com/artifact/org.drools/guvnor-webapp-drools/5.5.0.Final -- View this message in context: http://drools.46999.n3.nabble.com/guvnor-webapp-war-file-download-tp4024722p4024723.html Sent from the Drools: User forum 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] Upgrade from drools 5.4 to 6.0.0-Beta3 - Legacy API Adapter JAR
Please ignore, I got it working thanks -- View this message in context: http://drools.46999.n3.nabble.com/Upgrade-from-drools-5-4-to-6-0-0-Beta3-Legacy-API-Adapter-JAR-tp4024713p4024724.html Sent from the Drools: User forum 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] drools migration
I ran into the java.util.ConcurrentModificationException too when trying to
iterate over an ArrayList created via from collect in Drools 5.5.0 Final. My
solution was to copy the list into an array using List.toArray and then iterate
over that. I found that the type information is often not properly maintained
in the right-hand side of the rule, requiring casts where they should be
unnecessary. Here is a complete, self-contained example that shows how to
iterate over the array to modify or retract the facts.
import java.util.ArrayList;
declare Fact
@propertyReactive
name : String @key
value : String
end
rule initialize
when
then
insert (new Fact(abc));
insert (new Fact(def));
insert (new Fact(ghi));
end
rule collect and retract
salience 1
when
$list : ArrayList(size 0) from collect (Fact(name in (abc, def)))
then
// This will not compile without the explicit cast.
Fact[] facts = (Fact[]) $list.toArray(new Fact[0]);
for (Fact f : facts) {
retract (f);
}
end
rule collect and modify
salience 2
when
$list : ArrayList(size 0) from collect (Fact(name in (abc, def)))
then
Fact[] facts = (Fact[]) $list.toArray(new Fact[0]);
for (Fact f : facts) {
// The modify will not compile without an explicit cast,
// despite the declaration of f in the enhanced for loop.
Fact g = (Fact) f;
modify (g) {
setValue(g.getName() + A);
}
}
// Avoid the cast by using a traditional indexed loop.
for (int i = 0; i facts.length; i++) {
// Copy the array element into a new variable
// because modify (facts[i]) will not compile.
Fact g = facts[i];
modify (g) {
setValue(g.getName() + B);
}
}
end
Best wishes,
Tom
-Original Message-
From: rules-users-boun...@lists.jboss.org
[mailto:rules-users-boun...@lists.jboss.org] On Behalf Of radhika.inugala
Sent: Tuesday, July 02, 2013 3:20 PM
To: rules-users@lists.jboss.org
Subject: Re: [rules-users] drools migration
Also I am looking at the domain objects for this:
And I need to retract all the objects with locationType == LocationType.ORIGIN
the fromState is one of them.
But there would be more of the same.
I think that is the reason the collect is in there.
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-drools-migration-tp4024691p4024721.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
___
rules-users mailing list
rules-users@lists.jboss.orgmailto: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
