12:07 p.m.
I have the BRMS running on Websphere 6 and am having 2 issues and hoping
someone else may have run into them and might have potential solutions.
Other than these 2 issues, the brms runs very good.
Thanks
1. The repository .lock file get sets when the server starts but is never
released. The file must be manually deleted before the server is restarted.
2. PropertyNotFoundException when viewing the Packages screen for the first
time. After the first time, the page loads normally.
[9/14/07 13:00:10:010 EDT] 0000001e WebApp A SRVE0181I:
[RAILINC_ADMIN_EAR#RAILINC_ADMIN_RULEMANAGE_WEB.war]
[/RAILINC_ADMIN_RULEMANAGE_WEB] [Servlet.LOG]: Exception while dispatching
incoming RPC call: javax.el.PropertyNotFoundException: Property 'jboss' is
not found on type: org.jboss.seam.Namespace
at javax.el.BeanELResolver.getValue(BeanELResolver.java:230)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:135)
at com.sun.el.parser.AstValue.getValue(AstValue.java:96)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:183)
at
org.jboss.seam.util.UnifiedELValueBinding.getValue(UnifiedELValueBinding.java:34)
at org.jboss.seam.core.Expressions$1.getValue(Expressions.java:57)
at org.jboss.seam.Component.getInstanceFromFactory(Component.java:1652)
at org.jboss.seam.Component.getInstance(Component.java:1601)
at org.jboss.seam.Component.getInstance(Component.java:1578)
at org.jboss.seam.Component.getInstance(Component.java:1572)
at org.jboss.seam.jsf.SeamELResolver.getValue(SeamELResolver.java:49)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:135)
at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:44)
at com.sun.el.parser.AstValue.getValue(AstValue.java:85)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:183)
at
org.jboss.seam.util.UnifiedELValueBinding.getValue(UnifiedELValueBinding.java:34)
at org.jboss.seam.security.Identity.evaluateExpression(Identity.java:507)
at org.jboss.seam.security.Identity.checkRestriction(Identity.java:151)
at
org.jboss.seam.interceptors.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:35)
at
org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
at
org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:103)
at
org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:154)
at
org.jboss.seam.intercept.JavaBeanInterceptor.intercept(JavaBeanInterceptor.java:89)
at
org.drools.brms.server.ServiceImplementation$$EnhancerByCGLIB$$bfa6cbfb.listPackages(<generated>)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.jboss.seam.remoting.gwt.GWTToSeamAdapter.callWebRemoteMethod(GWTToSeamAdapter.java:70)
at
org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.processCall(GWTRemoteServiceServlet.java:300)
at
org.jboss.seam.remoting.gwt.GWTRemoteServiceServlet.doPost(GWTRemoteServiceServlet.java:181)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:966)
at
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:907)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:145)
at org.jboss.seam.web.ContextFilter.doFilter(ContextFilter.java:56)
at
com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:87)
at
com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:701)
at
com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:646)
at
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:475)
at
com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:463)
at
com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:92)
at
com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:744)
at
com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1433)
at
com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:93)
at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:465)
at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:394)
at
com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:102)
at
com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:152)
at
com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:213)
at
com.ibm.io.async.AbstractAsyncFuture.fireCompletionActions(AbstractAsyncFuture.java:195)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:194)
at
com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:741)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:863)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1510)
--
View this message in context:
http://www.nabble.com/BRMS-Issues-on-Websphere-6----Repository-.lock-and-...
Sent from the drools - user mailing list archive at Nabble.com.
2:19 p.m.
New subject: rule flow
Folks,
Using 4.0.1. Trying to do use rule flow to manage the execution of
rules. As I understood in Split node with type XOR I can set conditions
for each destination that are executed against facts in working memory.
Let's consider I have a rule that executes every time it finds Integer
object in memory and increments it.
rule "Increment"
ruleflow-group "Up"
when
$i : Integer(intValue < 10)
then
System.out.println("INTEGER : " + $i);
retract($i);
insert(new Integer($i.intValue() + 1));
end
Now, I have the following rule flow in place:
The Split to Up arrow has constraint : Integer(intValue < 5)
And initially I am inserting this fact : insert (new Integer(0))
Now my understanding is that It should execute rule "Increment" 5
times.... But instead it does it 10 times...
Is that a normal behavior? Why cannot Split understand that only when
there is an Integer(intValue < 5) only then execute rule with
ruleflow-group "Up"
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.
6:37 p.m.
New subject: rule flow
Now my understanding is that It should execute rule
"Increment" 5 times.. But instead it does it 10 times.
Is that a normal behavior?
Well, actually, this is expected behaviour, let me try to clarify.
Whenever a RuleSet node, like your "Up" node, is activated, it starts executing
activations that are part of that ruleflow-group until no more activations can be found.
Then the node will finish and the flow will continue with the next node. The problem is
that your node, as it is implemented now, automatically increments your Integer 10 times
in a row (you can easily test this by just executing this rule without a ruleflow
present). The reason is, once you removed your old integer and inserted a new one, this
new Integer will match the same rule again, so your "Up" node will not just
continue after one increment, but will increment 10 times (until the integer does not
match the <10 pattern of your rule anymore) and then continue to the end.
If I understand what you are trying to do, you should try to make sure that your
"Up" rule only increments once. The best way I could think of right now is
adding this at the end of your rule,
drools.getWorkingMemory().getAgenda().deactivateRuleFlowGroup("Up");
which will automatically deactivate your ruleflow-group and continue with your execution.
But you'll have to use the latest svn code (or 4.0.2 which is released next week), as
I found a small problem which would prevent you from doing this in 4.0.1 (.
[Note: While using the no-loop rule attribute for your rule might solve the problem of
reactivation of the same rule after an update outside the context of ruleflow, in this
case, it will not be sufficient as it will not only block the reactivation of your rule
for now but also for all future executions of your "Up" node in your flow,
leading to an infinite loop.]
When you are trying to implement a loop, you should also put your join first, and your
split at the end. That way, you will decide what you want to do (in your split) every
time AFTER your rule set has been executed. You can then decide to either go back (to the
join in the beginning) or end.
Also note that doing something like this will become much easier once we add support for
ruleflow variables, as you would simply define a variable counter and you would be able to
define an action like counter++, and use your ruleflow-groups for executing
"real" rules.
Kris
----- Original Message -----
From: Manukyan, Sergey
To: Rules Users List
Sent: Friday, September 14, 2007 9:19 PM
Subject: [rules-users] rule flow
Folks,
Using 4.0.1. Trying to do use rule flow to manage the execution of rules. As I
understood in Split node with type XOR I can set conditions for each destination that are
executed against facts in working memory.
Let's consider I have a rule that executes every time it finds Integer object in
memory and increments it.
rule "Increment"
ruleflow-group "Up"
when
$i : Integer(intValue < 10)
then
System.out.println("INTEGER : " + $i);
retract($i);
insert(new Integer($i.intValue() + 1));
end
Now, I have the following rule flow in place:
The Split to Up arrow has constraint : Integer(intValue < 5)
And initially I am inserting this fact : insert (new Integer(0))
Now my understanding is that It should execute rule "Increment" 5 times.. But
instead it does it 10 times.
Is that a normal behavior? Why cannot Split understand that only when there is an
Integer(intValue < 5) only then execute rule with ruleflow-group "Up"
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
6:58 p.m.
New subject: rule flow
ah yes I missed this. use the rule attribute "lock-on-active" to stop
this behaviour, it stops a rule re-activating while the ruleflowgroup is
active.
Mark
Kris Verlaenen wrote:
> Now my understanding is that It should execute rule "Increment" 5
times.... But instead it does it 10 times...
> Is that a normal behavior?
Well, actually, this is expected behaviour, let me try to clarify.
Whenever a RuleSet node, like your "Up" node, is activated, it starts
executing activations that are part of that ruleflow-group until no
more activations can be found. Then the node will finish and the flow
will continue with the next node. The problem is that your node, as
it is implemented now, automatically increments your Integer 10 times
in a row (you can easily test this by just executing this rule without
a ruleflow present). The reason is, once you removed your old integer
and inserted a new one, this new Integer will match the same rule
again, so your "Up" node will not just continue after one increment,
but will increment 10 times (until the integer does not match the <10
pattern of your rule anymore) and then continue to the end.
If I understand what you are trying to do, you should try to make sure
that your "Up" rule only increments once. The best way I could think
of right now is adding this at the end of your rule,
drools.getWorkingMemory().getAgenda().deactivateRuleFlowGroup("Up");
which will automatically deactivate your ruleflow-group and continue
with your execution. But you'll have to use the latest svn code
(or 4.0.2 which is released next week), as I found a small problem
which would prevent you from doing this in 4.0.1 (.
[Note: While using the no-loop rule attribute for your rule might
solve the problem of reactivation of the same rule after an update
outside the context of ruleflow, in this case, it will not be
sufficient as it will not only block the reactivation of your rule for
now but also for all future executions of your "Up" node in your flow,
leading to an infinite loop.]
When you are trying to implement a loop, you should also put your join
first, and your split at the end. That way, you will decide what you
want to do (in your split) every time AFTER your rule set has been
executed. You can then decide to either go back (to the join in the
beginning) or end.
Also note that doing something like this will become much easier once
we add support for ruleflow variables, as you would simply define a
variable counter and you would be able to define an action like
counter++, and use your ruleflow-groups for executing "real" rules.
Kris
----- Original Message -----
*From:* Manukyan, Sergey <mailto:SManukyan@lear.com>
*To:* Rules Users List <mailto:rules-users@lists.jboss.org>
*Sent:* Friday, September 14, 2007 9:19 PM
*Subject:* [rules-users] rule flow
Folks,
Using 4.0.1. Trying to do use rule flow to manage the execution of
rules. As I understood in Split node with type XOR I can set
conditions for each destination that are executed against facts in
working memory.
Let's consider I have a rule that executes every time it finds
Integer object in memory and increments it.
rule "Increment"
ruleflow-group "Up"
when
$i : Integer(intValue < 10)
then
System.out.println("INTEGER : " + $i);
retract($i);
insert(new Integer($i.intValue() + 1));
end
Now, I have the following rule flow in place:
The Split to Up arrow has constraint : Integer(intValue < 5)
And initially I am inserting this fact : insert (new Integer(0))
Now my understanding is that It should execute rule "Increment" 5
times.... But instead it does it 10 times...
Is that a normal behavior? Why cannot Split understand that only
when there is an Integer(intValue < 5) only then execute rule with
ruleflow-group "Up"
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
------------------------------------------------------------------------
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
7:16 p.m.
New subject: rule flow
use the rule attribute "lock-on-active" to stop this
behaviour, it stops a rule re-activating while the ruleflowgroup is active
Well,
this won't work for the same reason no-loop isn't working: if you use
lock-on-active, it will make sure that the rule is not reactivated, so the execution of
the node will end after one increment. But the lock-on-active makes sure that no
activation is ever created, so, in the context of looping in ruleflow, even if the RuleSet
node is activated again afterwards, it will never increment the integer again (as you
prevented reactivation of the rule using lock-on-active), resulting in an endless loop in
this case. Currently, as far as I know, the only thing that works is manually
deactivating the ruleflow-group.
Kris
7:36 p.m.
New subject: rule flow
true, damn :)
I did think of an attribute to "re-activate" any rules that are true,
but not currently on the agenda - but not sure about it yet, would have
to think on the negative effects some more.
Mark
Kris Verlaenen wrote:
> use the rule attribute "lock-on-active" to stop this
behaviour, it
stops a rule re-activating while the ruleflowgroup is active
Well, this won't work for the same reason no-loop isn't working: if
you use lock-on-active, it will make sure that the rule is not
reactivated, so the execution of the node will end after one
increment. But the lock-on-active makes sure that no activation is
ever created, so, in the context of looping in ruleflow, even if the
RuleSet node is activated again afterwards, it will never increment
the integer again (as you prevented reactivation of the rule using
lock-on-active), resulting in an endless loop in this case.
Currently, as far as I know, the only thing that works is manually
deactivating the ruleflow-group.
Kris
------------------------------------------------------------------------
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
2:12 p.m.
New subject: rule flow --> possible bug?
Thank you for explanations, it did clear up the picture for me, but I
still didn't resolve the problem that I am having. Looks like problem
happens when attributes are involved in a Split. Possible bug?
So here is an example:
I am inserting initially a simple TestValid class that has boolean
hasError attribute = false;
insert(new TestValid(false));
INIT ruleflow-group just prints out the facts :
rule "INIT"
ruleflow-group "INIT" no-loop
when
$v : TestValid()
then
System.out.println("INIT : HAS ERROR ? : " +
$v.isHasErrors());
end
The "Make Error" ruleflow-group is activated when hasError attribute is
flase in estValid fact :
rule "Make Error"
ruleflow-group "Make Error" no-loop
when
$v : TestValid(hasErrors == false)
then
System.out.println("Make Error!!!");
$v.setHasErrors(true);
retract($v);
insert($v);
end
The "Has Error?" XOR Split has the following constraints:
- TestValid(hasErrors == false) // goes to "No Errors"
Action
- TestValid(hasErrors == true) // goes to END
The Actions Just print out information :
- System.out.println("Init Action");
- System.out.println("No Errors Action");
When running example I was expecting to see the following events as seen
on console:
<START>
Init Action
INIT : HAS ERROR ? : false
No Errors Action
Make Error!!!
Init Action
INIT : HAS ERROR ? : true
<END>
Instead that is what I see:
<START>
Init Action
INIT : HAS ERROR ? : false
No Errors Action
Make Error!!!
Init Action
INIT : HAS ERROR ? : true
No Errors Action
Init Action
No Errors Action
Init Action
...
<infinitely goes like this>
Now is this again expected behavior or a possible bug?
If it is expected then how can I make decisions based on attribute of a
fact in a Split...
Thank you,
-Sergey
________________________________
From: rules-users-bounces(a)lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Mark Proctor
Sent: Friday, September 14, 2007 8:37 PM
To: Rules Users List
Subject: Re: [rules-users] rule flow
true, damn :)
I did think of an attribute to "re-activate" any rules that are true,
but not currently on the agenda - but not sure about it yet, would have
to think on the negative effects some more.
Mark
Kris Verlaenen wrote:
use the rule attribute "lock-on-active" to stop this
behaviour, it
stops a rule re-activating while the ruleflowgroup is active
Well, this won't work for the same reason no-loop isn't working: if you
use lock-on-active, it will make sure that the rule is not reactivated,
so the execution of the node will end after one increment. But the
lock-on-active makes sure that no activation is ever created, so, in the
context of looping in ruleflow, even if the RuleSet node is activated
again afterwards, it will never increment the integer again (as you
prevented reactivation of the rule using lock-on-active), resulting in
an endless loop in this case. Currently, as far as I know, the only
thing that works is manually deactivating the ruleflow-group.
Kris
________________________________
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
**********************
** 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.
6:44 p.m.
New subject: rule flow --> possible bug?
Sergey,
I am actually getting your expected behaviour when I recreated your example here.
So could you open up a JIRA and include the example as a self-contained eclipse project,
or just email it to me?
I'll take a look at what might be wrong / different.
Kris
----- Original Message -----
From: Manukyan, Sergey
To: Rules Users List
Sent: Monday, September 17, 2007 9:12 PM
Subject: RE: [rules-users] rule flow --> possible bug?
Thank you for explanations, it did clear up the picture for me, but I still didn't
resolve the problem that I am having. Looks like problem happens when attributes are
involved in a Split. Possible bug?
So here is an example:
I am inserting initially a simple TestValid class that has boolean hasError attribute =
false;
insert(new TestValid(false));
INIT ruleflow-group just prints out the facts :
rule "INIT"
ruleflow-group "INIT" no-loop
when
$v : TestValid()
then
System.out.println("INIT : HAS ERROR ? : " + $v.isHasErrors());
end
The "Make Error" ruleflow-group is activated when hasError attribute is flase
in estValid fact :
rule "Make Error"
ruleflow-group "Make Error" no-loop
when
$v : TestValid(hasErrors == false)
then
System.out.println("Make Error!!!");
$v.setHasErrors(true);
retract($v);
insert($v);
end
The "Has Error?" XOR Split has the following constraints:
- TestValid(hasErrors == false) // goes to "No Errors" Action
- TestValid(hasErrors == true) // goes to END
The Actions Just print out information :
- System.out.println("Init Action");
- System.out.println("No Errors Action");
When running example I was expecting to see the following events as seen on console:
<START>
Init Action
INIT : HAS ERROR ? : false
No Errors Action
Make Error!!!
Init Action
INIT : HAS ERROR ? : true
<END>
Instead that is what I see:
<START>
Init Action
INIT : HAS ERROR ? : false
No Errors Action
Make Error!!!
Init Action
INIT : HAS ERROR ? : true
No Errors Action
Init Action
No Errors Action
Init Action
.
<infinitely goes like this>
Now is this again expected behavior or a possible bug?
If it is expected then how can I make decisions based on attribute of a fact in a
Split.
Thank you,
-Sergey
------------------------------------------------------------------------------
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org]
On Behalf Of Mark Proctor
Sent: Friday, September 14, 2007 8:37 PM
To: Rules Users List
Subject: Re: [rules-users] rule flow
true, damn :)
I did think of an attribute to "re-activate" any rules that are true, but not
currently on the agenda - but not sure about it yet, would have to think on the negative
effects some more.
Mark
Kris Verlaenen wrote:
use the rule attribute "lock-on-active" to stop this
behaviour, it stops a rule re-activating while the ruleflowgroup is active
Well, this won't work for the same reason no-loop isn't working: if you use
lock-on-active, it will make sure that the rule is not reactivated, so the execution of
the node will end after one increment. But the lock-on-active makes sure that no
activation is ever created, so, in the context of looping in ruleflow, even if the RuleSet
node is activated again afterwards, it will never increment the integer again (as you
prevented reactivation of the rule using lock-on-active), resulting in an endless loop in
this case. Currently, as far as I know, the only thing that works is manually
deactivating the ruleflow-group.
Kris
------------------------------------------------------------------------------
_______________________________________________rules-users mailing
listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
**********************
** 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
8:15 a.m.
New subject: rule flow --> possible bug?
Kris,
I found what was causing this strange behavior. It is the fact that I
disabled shadow proxy. Once I enabled it - it worked fine ... just like
I expected.
Is that normal/expected behavior?
How can I make it work with shadow proxies disabled?
Thanks,
-Sergey
________________________________
From: rules-users-bounces(a)lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Kris Verlaenen
Sent: Monday, September 17, 2007 7:44 PM
To: Rules Users List
Subject: Re: [rules-users] rule flow --> possible bug?
Sergey,
I am actually getting your expected behaviour when I recreated your
example here.
So could you open up a JIRA and include the example as a self-contained
eclipse project, or just email it to me?
I'll take a look at what might be wrong / different.
Kris
----- Original Message -----
From: Manukyan, Sergey <mailto:SManukyan@lear.com>
To: Rules Users List <mailto:rules-users@lists.jboss.org>
Sent: Monday, September 17, 2007 9:12 PM
Subject: RE: [rules-users] rule flow --> possible bug?
Thank you for explanations, it did clear up the picture for me,
but I still didn't resolve the problem that I am having. Looks like
problem happens when attributes are involved in a Split. Possible bug?
So here is an example:
I am inserting initially a simple TestValid class that has
boolean hasError attribute = false;
insert(new TestValid(false));
INIT ruleflow-group just prints out the facts :
rule "INIT"
ruleflow-group "INIT" no-loop
when
$v : TestValid()
then
System.out.println("INIT : HAS ERROR ? : " +
$v.isHasErrors());
end
The "Make Error" ruleflow-group is activated when hasError
attribute is flase in estValid fact :
rule "Make Error"
ruleflow-group "Make Error" no-loop
when
$v : TestValid(hasErrors == false)
then
System.out.println("Make Error!!!");
$v.setHasErrors(true);
retract($v);
insert($v);
end
The "Has Error?" XOR Split has the following constraints:
- TestValid(hasErrors == false) // goes to "No
Errors" Action
- TestValid(hasErrors == true) // goes to END
The Actions Just print out information :
- System.out.println("Init Action");
- System.out.println("No Errors Action");
When running example I was expecting to see the following events
as seen on console:
<START>
Init Action
INIT : HAS ERROR ? : false
No Errors Action
Make Error!!!
Init Action
INIT : HAS ERROR ? : true
<END>
Instead that is what I see:
<START>
Init Action
INIT : HAS ERROR ? : false
No Errors Action
Make Error!!!
Init Action
INIT : HAS ERROR ? : true
No Errors Action
Init Action
No Errors Action
Init Action
...
<infinitely goes like this>
Now is this again expected behavior or a possible bug?
If it is expected then how can I make decisions based on
attribute of a fact in a Split...
Thank you,
-Sergey
________________________________
From: rules-users-bounces(a)lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Mark Proctor
Sent: Friday, September 14, 2007 8:37 PM
To: Rules Users List
Subject: Re: [rules-users] rule flow
true, damn :)
I did think of an attribute to "re-activate" any rules that are
true, but not currently on the agenda - but not sure about it yet, would
have to think on the negative effects some more.
Mark
Kris Verlaenen wrote:
use the rule attribute "lock-on-active" to stop this
behaviour, it stops a rule re-activating while the ruleflowgroup is
active
Well, this won't work for the same reason no-loop isn't working:
if you use lock-on-active, it will make sure that the rule is not
reactivated, so the execution of the node will end after one increment.
But the lock-on-active makes sure that no activation is ever created,
so, in the context of looping in ruleflow, even if the RuleSet node is
activated again afterwards, it will never increment the integer again
(as you prevented reactivation of the rule using lock-on-active),
resulting in an endless loop in this case. Currently, as far as I know,
the only thing that works is manually deactivating the ruleflow-group.
Kris
________________________________
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
**********************
** 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
6773
days inactive
6777
days old
8 comments
4 participants
participants (4)
-
Barry K -
Kris Verlaenen -
Manukyan, Sergey -
Mark Proctor