-
15. Re: 3.2 alpha 1 release status
I'm referring to
protected synchronized boolean isWaiting(Thread thread) { return (thread.getState()==State.WAITING) || (thread.getState()==State.TIMED_WAITING); }
Thread.getState() and the Thread.State enum are new to java 5. Perhaps you set your JRE system library to jdk 1.5 in eclipse? -
16. Re: 3.2 alpha 1 release status
James - would you say that these bugs reflect the same underlying problem:
http://jira.jboss.com/jira/browse/JBPM-395 (SwimlaneInstance PooledActor assignment bug (not re-assignment issue))
http://jira.jboss.com/jira/browse/JBPM-378 (Broken support for SwimlaneInstance PooledActor reassignment) -
17. Re: 3.2 alpha 1 release status
No, Ive read both of these issues before, and this doesnt appear to be linked to that.
We have a simple process that starts with the initiator, and goes to a submitted state.
In the submitted state it is controlled by a swimlane named 'approvers'
3 people or so are being added to the approvers swimlane, and that shows correctly in the database,
but when we go and look on the web, it does not show up on anyone's inbox.
Upon further looking, we saw that the function that gets the pooled tasks ONLY appears to get the tasks for pooled actors if they are direfctly declared as pooled actors, like pooled-actors=xxxx.
The query for that joins across three tables or so. But for swimlane actors, there is no entry in the JBPM_TASKACTORPOOL.
And it gets really hairy at that point, cause many of the names are so related, and the query says it is using a swimlaneactorid, when its just using an actorid, semantically different, but....
So if you can take a look at it at least, would be great.
As I said earlier, we created another function/query, which seems to get in the rest of the swimlane tasks ok.
James Ratcliff -
18. Re: 3.2 alpha 1 release status
"david.lloyd@jboss.com" wrote:
...which is to say, using -source 1.4 you couldn't use enums, generics, or annotations, but you can still use new classes/methods. There's nothing within the JDK classes that marks specific classes or methods as new for 1.5 such that the compiler would be able to detect it.
that must be it. didn't think of that. thanks, david! -
19. Re: 3.2 alpha 1 release status
"david.lloyd@jboss.com" wrote:
"falazar" wrote:
It seems like a couple of these tables may not be normalized very well either.
I'm with you there, but from talking to Tom I don't think we can expect this to change in the 3.x series, since we're going to avoid any sweeping database changes, especially those that would introduce compatibility problems... Tom, correct me if I'm wrong.
3.1, 3.2, 3.3, ... can have changing database schemas. it's for micro release numbers that jbpm db schema should be stable (e.g. between 3.1.2 and 3.1.3).
but id didn't yet get completely the problem that falazar is experiencing. falazar, can you try explaining again what you did, what jbpm behaviour was and what behaviour you expected. -
20. Re: 3.2 alpha 1 release status
3.1, 3.2, 3.3, ... can have changing database schemas
Is it documented somewhere ?
Regards,
David -
21. Re: 3.2 alpha 1 release status
I believe I found the problem now, after digging for yet another day. It appears we were using hte API to try and put the swimlane actors on a task before the task was created... we are juggling it around now, and should have it back to working soon.
James