Hi Alberto,
I'm not upset, kind the opposite. I'm sorry if my comments sounds harsh. I
was making some assumptions based on my previous experience.
My main point was, let's try to be concrete and let's work on code and
failing tests. I know that is not trivial, but if we want to make the
project be
Mauricio, seems to me that you're upset. I'm really sorry, I didn't mean
it. I didn't mean this thread to become a fud or some kind of rant.
Comments inline:
On Mon, Jun 25, 2012 at 1:36 PM, Mauricio Salatino wrote:
> What I've noticed in the past, doing consulting is that people wants to
> migr
What I've noticed in the past, doing consulting is that people wants to
migrate from jBPM3 that is almost stateless to jBPM5 and have everything
inside a Stateful session with a richer context and expect that everything
will work in the same way.
If you run each of your process instances in differe
We're in a hurry now to make our system work, unfortunately seems that we
will be doing dirty tricks as this one for some time ... we'll open an
issue whenever a test can be produced ...
We were running our system using JBPM 3 and both the integration and the
persistence there were seamsly don
So, can you create an isolated test where you reproduce:
"We are unable to complete a human task after rehydrating a Drools
knowledge session because in some circunstances the generated Drools'
workitems don't get persisted in the database after the completion of a
previous task"
And I can ta
Sure, WorkItemHandlers are never persisted. I re-register those handlers
before staring the session, just because I want my tasks to be properly
executed.
:(
Alberto R. Galdo
arga...@gmail.com
On Fri, Jun 22, 2012 at 2:46 PM, Mauricio Salatino wrote:
> There are two concepts here:
> 1) WorkIt
There are two concepts here:
1) WorkItem -> Persist the state of the activity
2) WorkItemHandlers -> Never Persisted
Are you re-registering the WorkItemHandlers at rehydratation?
WorkItemHandlers are part of the runtime status and don't get persisted.
Cheers
On Fri, Jun 22, 2012 at 9:39 AM, Alber
No, I'm not registering pending workitems at rehydration. That's why I'm
using Drools & JBPM persistence ;-). I don't want to write my own state
persistence, as I am a mere user of JBPM & Drools services.
>> "They are never persisted"
This several methods in org.drools.persitence.jpa.JPAPersisten
"We are unable to complete a human task after rehydrating a Drools
knowledge session because in some circunstances the generated Drools'
workitems don't get persisted in the database after the completion of a
previous task"
They are never persisted, they are runtime information that you must
re-