Problem deploying 5.3.0 drools server in Tomcat
by Ravi Sundaar
Hi,
When I deploy drools-camel-server-5.3.0.Final.war into tomcat (webapps
folder), I see the following problem. I don't have a problem with the 5.3
Guvnor war file. Any idea what might be going on?
INFO: Starting ProtocolHandler ["ajp-apr-8009"]
Feb 6, 2012 9:06:40 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 24453 ms
INFO 06-02 21:07:17,196 (NilAuthenticator.java:authenticate:35) All use
rs are guests.
Feb 6, 2012 9:15:00 PM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive C:\apache-tomcat-7.0.25\webapps\drools-c
amel-server-5.3.0.Final.war
Feb 6, 2012 9:15:03 PM org.apache.catalina.loader.WebappClassLoader validateJarF
ile
INFO: validateJarFile(C:\apache-tomcat-7.0.25\webapps\drools-camel-server-5.3.0.
Final\WEB-INF\lib\geronimo-servlet_3.0_spec-1.0.jar) - jar not loaded. See Servl
et Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class
log4j:WARN No appenders could be found for logger (org.springframework.web.conte
xt.ContextLoader).
log4j:WARN Please initialize the log4j system properly.
Thanks,
Ravi.
12 years, 9 months
Fwd: Migrating repository data from Drools 5.0 to 5.3Final
by Michael Anstis
I suspect ConsumerAccountAssociationFact.hasAnyAccountClosed is a boolean.
In 5.3 we handle data-types better than 5.0, so String, Numbers, Dates are
Booleans have editors appropriate for the data-type and the resulting DRL
only escapes values with quotation marks where needed (i.e. Strings and
Dates). Boolean's in the table are now shown as Checkboxes. If the value is
"true" it is ticked, if the value is "false" the checkbox is not ticked.
I don't therefore believe there is any problem.
On 10 February 2012 16:35, jian zhi <jianpzhi(a)yahoo.com> wrote:
> Mike,
>
> Thanks for the quick response. I downloaded the war and tested the fix.
> The order of the conditions are correct now. There is still a small problem
> in the last condition.
>
> In Drools 5.0 the source is consumerAccount :
> ConsumerAccountAssociationFact( hasAnyAccountClosed == "false" ).
> In Drools 5.3 the source is consumerAccount :
> ConsumerAccountAssociationFact( hasAnyAccountClosed == false ). It displays
> a square check box in the cell.
>
> Could you please take a look?
> Thanks,
> Jian
>
> ------------------------------
> *From:* Michael Anstis <michael.anstis(a)gmail.com>
> *To:* jian zhi <jianpzhi(a)yahoo.com>; Rules Users List <
> rules-users(a)lists.jboss.org>
> *Sent:* Thursday, February 9, 2012 4:55 AM
>
> *Subject:* Re: [rules-users] Migrating repository data from Drools 5.0 to
> 5.3Final
>
> You can get a build containing the fix from Nexus:
>
>
> https://repository.jboss.org/nexus/index.html#nexus-search;gav~org.drools...
>
> 2012/2/8 jian zhi <jianpzhi(a)yahoo.com>
>
> Mike,
>
> Is it possible to release a patch of 5.3?
>
> Thanks,
> Jian
>
> ------------------------------
> *From:* Michael Anstis <michael.anstis(a)gmail.com>
> *To:* Rules Users List <rules-users(a)lists.jboss.org>
> *Sent:* Wednesday, February 8, 2012 3:17 AM
>
> *Subject:* Re: [rules-users] Migrating repository data from Drools 5.0 to
> 5.3Final
>
> The problem has existed since 5.2 and would potentially affect loading any
> earlier version.
> Prior to 5.2 the object model used by the guided decision table did not
> hold a Pattern to which individual condition columns are bound.
> The conversion code groups individual condition columns into the
> appropriate group and moves the underlying column data accordingly (as
> there was no guarantee columns with the same bound name were consecutive).
> There was a problem with the creation and insertion of the new Pattern
> objects that relied upon the order of entries in a HashMap being
> consistent. This has now changed.
> I know others have been using the new guided decision table with old
> repositories without problem and our unit tests did not detect the problem
> either.
> AFAIK this is the first report of any such issue since the release of
> 5.2's betas, however I would be wrong to say there is no risk.
> sent on the move
> On 8 Feb 2012 01:22, "vadlam" <sreeram.vadlamudi(a)wellsfargo.com> wrote:
>
> does this issue happen for any previous version of Guvnor data such as 5.0
> or 5.1 or 5.2 exported and imported into a Guvnor 5.3 repository ?
>
> does this mean, we cannot rely on 5.3.0 version of Guvnor code when
> migrating data from a previous version and should rather apply the fix ?
>
>
>
> --
> View this message in context:
> http://drools.46999.n3.nabble.com/rules-users-Migrating-repository-data-f...
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
>
12 years, 9 months
5.4 stability?
by Stephen Masters
Hi folks,
With 5.3.0.Final I have crashed into the brick wall of https://issues.jboss.org/browse/GUVNOR-1726 which makes templates pretty much useless.
Now Jira mentions that this should be fixed in 5.4.0 beta1, so I'm thinking that it should still be fixed in beta 2. Not having the ability to build these rule templates is a pretty big issue for me, but I don't want to give myself a whole load more headaches by switching to something too flaky. So can anybody give me some idea of how stable beta 2 is at the moment? If I were to perform the upgrade would I be likely to spend a few days fire-fighting?
Steve
12 years, 9 months
Re: [rules-users] rule group activation by concurrent jbpm processes
by Alberto R. Galdo
Hi,
We've gained some insight about what is happening under the hood for this
kind of interaction between JBPM and Drools expert.
Imagine a knowledge session with this set of rules:
rule "new case"
when
$object : Object(processed==false) from entry-point "my stream"
then
ProcessInstance
processInstance=kcontext.getKnowledgeRuntime().createProcessInstance("my.Process",
parameters);
insert(processInstance);
end
rule "complete"
ruleflow-group "process complete"
no-loop true
when
$processInstance: WorkflowProcessInstance()
then
System.out.println("Fired!" + $processInstance);
end
And a process that runs a time consuming task before reaching a
bussinessruletask node that calls the "process complete" group of rules.
What is happening from Drool's expert point of view is the following
sequence of events:
1 - A fact is inserted that triggers the rule "new case". An Activation
is inserted into the agenda.
2 - As this is running in a fireUntilHalt loop then, almost
inmediatelly, the previous activation is fired and it's consquence is
evaluated leading to the insertion of the process instance as a fact in the
knowledge session. The process is now executing.
3 - This very new fact triggers the activation of the rule "complete"
( as it's only condition is that a processinstance exists ). It's
consequence gets evaluated and as it belongs to a group of rules, an
Activation is added to the ruleFlowGroup inside the Agenda. Nothing happens
thereafter.
4 - Another fact of the same type arrives and steps 1,2 and 3 execute
for the new fact. Now, the agenda has two Activations stored in the
ruleFlowGroup.
5 - At this time, the task in the first process ends, the
businessruletask gets executed and JBPM calls "activateRuleFlowGroup" on
the Agenda and the rule flow group gets activated.
6 - Inmediatelly the group of rules fires two activations ( both queued
at process fact insertion when the process was started ), when only one
process ended.
7 - So at least one rule gets evaluated for a process instance that
didn't belong to it .. :(
Then , "We have added special logic to make sure that a variable
processInstance of type WorkflowProcessInstance
will only match to the current process instance and not to other process
instances in the Working Memory." doesn't hold to be true, as our rule is
fired *before* it's process asks Drools to do so.
We've tested this behaviour in Drools 5.1.0, 5.2.0 and 5.3.0. All fail to
fulfill the requirements in the documentation.
What's worring us is that there seems to be no difference between actions
in the agenda as they're instances of AgendaItem class wich has no means to
discriminate between Activations ( at least there's no clear path to guess
the attached process instance ).
Bug report?
If this is a bug ( or lack of use case ) we will be more than happy to
submit a patch for it, just will need some hints...
Alberto R. Galdo
argaldo(a)gmail.com
2012/2/13 Esteban Aliverti <esteban.aliverti(a)gmail.com>
> The behavior you described is how it is working in 5.3 (and it seems 5.2
> too). The rule is fired once per process instance you have in your working
> memory no matter if the others instances are, are not yet or even has
> already been in that Rule Task Node. Again, I'm not sure if this is a
> deliberated feature or a bug, but according to the documentation, it is a
> bug.
> One workaround could be that the process inserts a control fact containing
> its own id right before the Task Node is ejecuted (this could be done in a
> listener or in the on-entry action property of the node).
> Your rule then will look like this:
>
> rule "process complete"
> ruleflow-group "Complete task group"
> when
> $ControlFact($id: processIntanceId)
> $processInstance: WorkflowProcessInstance(instanceId == $id)
>
> then
> System.out.println("processInstance.id " +
> $processInstance.getId());
> retract ($id)
> end
>
> Best Regards,
>
>
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>
> Esteban Aliverti
> - Developer @ http://www.plugtree.com
> - Blog @ http://ilesteban.wordpress.com
>
>
> 2012/2/13 Alberto R. Galdo <argaldo(a)gmail.com>
>
>> We're using 5.2.0 final here.
>>
>> What we are also observing is that whenever a process instance reaches a
>> businessruletask node the rule gets fired a number of times equal to the
>> number of instantiated processes even if any of those processes didn't
>> reach the bussinessruletask node.
>>
>> Does this means that whenever a businessruletask is reached in any of the
>> current process instance, the rule gets fired for *all* the instances of
>> the process and subsequent businessruletask nodes won't fire anything?
>>
>>
>>
>>
>> 2012/2/13 Esteban Aliverti <esteban.aliverti(a)gmail.com>
>>
>>> I had some tests working fine in jbpm 5.1 but failing in 5.3 because of
>>> this same reason. I'm not sure if this is this is a regression bug or if
>>> there is a deliberated change in the behavior.
>>> Maybe someone in the jbpm dev team can shed some light here.
>>>
>>> Best Regards,
>>>
>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>>>
>>> Esteban Aliverti
>>> - Developer @ http://www.plugtree.com
>>> - Blog @ http://ilesteban.wordpress.com
>>>
>>>
>>> 2012/2/13 Alberto R. Galdo <argaldo(a)gmail.com>
>>>
>>>>
>>>> According to the documentation:
>>>>
>>>> "Rule constraints do not have direct access to variables defined inside
>>>>> the process.
>>>>> It is however possible to refer to the current process instance inside
>>>>> a rule constraint,
>>>>> by adding the process instance to the Working Memory and matching for
>>>>> the process instance in your rule constraint.
>>>>> We have added special logic to make sure that a variable
>>>>> processInstance of type WorkflowProcessInstance
>>>>> will only match to the current process instance and not to other
>>>>> process instances in the Working Memory.
>>>>> Note that you are however responsible yourself to insert the process
>>>>> instance into the session and,
>>>>> possibly, to update it, for example, using Java code or an on-entry or
>>>>> on-exit or explicit action in your process.
>>>>> The following example of a rule constraint will search for a person
>>>>> with the same name as the value stored in the variable "name" of the
>>>>> process:"
>>>>>
>>>>
>>>>
>>>> This however does not seem to be true.
>>>>
>>>> The first rule is to receive a stream of objects of type MyObject.
>>>> This rule starts an associated process.
>>>>
>>>> The second rule will be called by the process (from bpmn).
>>>>
>>>> Within the process there a task that invokes an an asynchronous
>>>> service, ie,
>>>> an implementation of WorkItemHandler that contains a Thread that will
>>>> set call
>>>> manager.completeWorkItem(workItemId,results);
>>>> when 30s have passed).
>>>>
>>>> With this setup we can observe what happens when 2 MyObject instances
>>>> come into the first rule separated by a short period of time (say 5
>>>> seconds).
>>>>
>>>> When the first object comes in a process is created and started (with
>>>> process id=1)
>>>> The process passes from the start node to the callMyTask node, which
>>>> invokes the slow WorkItemHandler references by MyTask
>>>> (which we have previously registered into session.getWorkItemManager()
>>>> ).
>>>> Because the WorkItemHandler has a thread that waits 30s before
>>>> completing the work item, it just sits there doing nothing (so far
>>>> everything is ok)
>>>> and allows the engine to process other events.
>>>>
>>>> 5 seconds later we insert another MyObject into the stream.
>>>> The first rule gets fired and created another process (with process
>>>> id=2).
>>>> The process passes from the start node to the callMyTask node, which
>>>> invoke our slow service.
>>>>
>>>> We have thus two processes running in parallel.
>>>>
>>>> When the first callMyTask node completes, the next node completeTask is
>>>> invoked.
>>>>
>>>> The rule "process complete" is matched as it belongs to the rule flow
>>>> group "Complete task group".
>>>>
>>>> At this point we observe that the rule is matched twice spitting out:
>>>>
>>>> processInstance.id 2
>>>> processInstance.id 1
>>>> .
>>>> So the rule has matched both process instances that are in working
>>>> memory and not just the one (with process id 1)
>>>> that called the "process complete" rule.
>>>>
>>>>
>>>>
>>>> The rule file
>>>> -------------
>>>>
>>>> rule "New case"
>>>> when
>>>> $myobject : MyObject(processed==false) from entry-point
>>>> "myobject stream"
>>>> then
>>>> ProcessInstance
>>>> processInstance=kcontext.getKnowledgeRuntime().createProcessInstance("com.mycompany.process.MyProcess",
>>>> parameters);
>>>> insert(processInstance);
>>>>
>>>> kcontext.getKnowledgeRuntime().startProcessInstance(processInstance.getId());
>>>> modify ($myobject){
>>>> setProcessed(true)
>>>> }
>>>> end
>>>>
>>>> rule "process complete"
>>>> ruleflow-group "Complete task group"
>>>> no-loop true
>>>> when
>>>> $processInstance: WorkflowProcessInstance()
>>>> then
>>>> System.out.println("processInstance.id " +
>>>> $processInstance.getId());
>>>> end
>>>>
>>>>
>>>> The BPMN xml
>>>> ------------
>>>>
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <definitions id="Definition"
>>>> targetNamespace="http://www.jboss.org/drools"
>>>> typeLanguage="http://www.java.com/javaTypes"
>>>> expressionLanguage="http://www.mvel.org/2.0"
>>>> xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>> xsi:schemaLocation="
>>>> http://www.omg.org/spec/BPMN/20100524/MODEL BPMN20.xsd"
>>>> xmlns:g="http://www.jboss.org/drools/flow/gpd"
>>>> xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
>>>> xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
>>>> xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
>>>> xmlns:tns="http://www.jboss.org/drools">
>>>>
>>>> <process processType="Private" isExecutable="true"
>>>> id="com.mycompany.process.MyProcess" name="my process" >
>>>>
>>>> <!-- process variables -->
>>>>
>>>> <!-- nodes -->
>>>> <startEvent id="start" name="StartProcess" />
>>>>
>>>> <task id="callMyTask" name="call my task" tns:taskName="MyTask"
>>>> >
>>>> <ioSpecification>
>>>> </ioSpecification>
>>>> </task>
>>>>
>>>>
>>>> <businessRuleTask id="completeTask" name="Complete slow task"
>>>> g:ruleFlowGroup="Complete task group" >
>>>> </businessRuleTask>
>>>>
>>>> <endEvent id="end" name="EndProcess" />
>>>>
>>>> <!-- connections -->
>>>> <sequenceFlow id="start-callMyTask" sourceRef="start"
>>>> targetRef="callMyTask" />
>>>> <sequenceFlow id="callMyTask-completeTask"
>>>> sourceRef="callMyTask" targetRef="completeTask" />
>>>> <sequenceFlow id="completeTask-end" sourceRef="completeTask"
>>>> targetRef="end" />
>>>> </process>
>>>> </definitions>
>>>>
>>>>
>>>> What's wrong with this? Isn't WorkflowProcessInstance() supposed to be
>>>> attached to the calling ProcessInstance? Is there another way of getting
>>>> the group of rules fire only for the processinstance that called it?
>>>>
>>>>
>>>> Greets,
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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
>
>
12 years, 9 months
Testing for global variable
by Chris Selwyn
Is there a way to test for the existence of a global variable in a StatelessKnowledgeSession before inserting a SetGlobal command into a BatchExecutionCommand?
I am trying to write a rules executor class that may execute some rulesets that need a particular global variable and some that don't.
So I would like to be able to automatically test whether the rules that I am about to execute have the global variable and if they do not then not to insert the SetGlobal into the batch.
I am using DRools 5.1
Chris Selwyn
12 years, 9 months
5.3.0 NoClassDefFound due to nested property access
by Wolfgang Laun
Is this already known and fixed in 5.4.0? The problem occurs when you
have, e.g.,
Fact( foo.bar == "baz" )
Stack dump:
Exception in thread "main" java.lang.NoClassDefFoundError: monitor/Monitor
at ASMAccessorImpl_114212541328697624590.getValue(Unknown Source)
at org.mvel2.optimizers.dynamic.DynamicGetAccessor.getValue(DynamicGetAccessor.java:73)
at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:106)
at org.mvel2.compiler.ExecutableAccessor.getValue(ExecutableAccessor.java:42)
at org.mvel2.MVEL.executeExpression(MVEL.java:954)
at org.drools.base.extractors.MVELClassFieldReader.getValue(MVELClassFieldReader.java:100)
at org.drools.base.extractors.BaseObjectClassFieldReader.isNullValue(BaseObjectClassFieldReader.java:179)
at org.drools.rule.VariableRestriction$ObjectVariableContextEntry.updateFromFactHandle(VariableRestriction.java:338)
at org.drools.common.SingleBetaConstraints.updateFromFactHandle(SingleBetaConstraints.java:118)
at org.drools.reteoo.NotNode.modifyRightTuple(NotNode.java:339)
at org.drools.reteoo.BetaNode.modifyObject(BetaNode.java:431)
at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:468)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:436)
at org.drools.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:288)
at org.drools.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:271)
at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:459)
at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:363)
at org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:298)
at monitor.Rule_stop_monitoring.defaultConsequence(Rule_stop_monitoring.java:8)
at monitor.Rule_stop_monitoringDefaultConsequenceInvoker.evaluate(Unknown
Source)
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1091)
at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1029)
at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1251)
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:708)
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:672)
at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:90)
at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:46)
at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:13)
at org.drools.time.impl.PseudoClockScheduler.runCallBacks(PseudoClockScheduler.java:203)
at org.drools.time.impl.PseudoClockScheduler.advanceTime(PseudoClockScheduler.java:156)
12 years, 9 months
