-
15. Re: TaskInstance.setActorId(String) causes set TaskInstance
octomac Jun 16, 2008 11:19 AM (in response to octomac)Changing to a request bean instead of a session bean fixed the refresh problem, since I'm now forcing JBPM to hit the database on every call to the controller. This is a little slow, but it's working well, which is fine by me.
I'm still seeing, though, that when I assign a task from a PooledActor to an ActorID by means of setActorId(String), the boolean properties ISCANCELLED, ISSUSPENDED, ISOPEN, ISSIGNALILNG, and ISBLOCKING are all set to TRUE. This is a major problem, because JBPM now thinks that the assigned task is canceled. That means that the task disappears from both the group list and the users list.
Does anyone have any idea as to why these boolean properties may be getting set this way? -
16. Re: TaskInstance.setActorId(String) causes set TaskInstance
kukeltje Jun 16, 2008 1:09 PM (in response to octomac)
Does anyone have any idea as to why these boolean properties may be getting set this way?
A bug?
As mentioned before, make a small unit test with embedded processflow that demonstrates the problem -
17. Re: TaskInstance.setActorId(String) causes set TaskInstance
octomac Jun 16, 2008 4:38 PM (in response to octomac)It might be a bug, but I think it may be more likely that Hibernate is receiving the wrong data -- that is, it's expecting a '1' or a '0' perhaps, and is instead getting, say, a "T" or "F" string, which is causing it to always assume "TRUE".
This is a newbie question, but is there a way to turn on transaction logging so that I can see each statement and its corresponding data that is sent to the database? I have the hibernate.show_sql property in my hibernate.cfg.xml set to "true," but this only gives me the query or statement, not the data that goes along with it (that is, I see "UPDATE **** SET **** = ? WHERE blah blah," but the '?' in the statement doesn't have a corresponding value). Being able to see what data is being put into the database will help me immensely.
Thanks again for everyone's help! -
18. Re: TaskInstance.setActorId(String) causes set TaskInstance
kukeltje Jun 17, 2008 3:25 AM (in response to octomac)
It might be a bug, but I think it may be more likely that Hibernate is receiving the wrong data -- that is, it's expecting a '1' or a '0' perhaps, and is instead getting, say, a "T" or "F" string, which is causing it to always assume "TRUE".
That could be because of an incorrect hibernate mapping
Regarding the logging, if you put hibernate in debug (or trace with the newer log4j's, you'll see something like this:2006-07-28 09:57:12,061 DEBUG org.hibernate.SQL - insert into BASKET_LINE_ALLOC (LAST_UPDATED, QUANTITY, CUSTOMER_REF, NOTES, BRANCH_ID, FUND_ID, TEMPLATE_ID, BASKET_LINE_ALLOC_ID) values (?, ?, ?, ?, ?, ?, ?, ?) 2006-07-28 09:57:12,081 DEBUG org.hibernate.type.TimestampType - binding '2006-07-28 09:57:12' to parameter: 1 2006-07-28 09:57:12,081 DEBUG org.hibernate.type.IntegerType - binding '3' to parameter: 2 2006-07-28 09:57:12,082 DEBUG org.hibernate.type.StringType - binding '' to parameter: 3 2006-07-28 09:57:12,082 DEBUG org.hibernate.type.StringType - binding '' to parameter: 4 2006-07-28 09:57:12,082 DEBUG org.hibernate.type.LongType - binding '511' to parameter: 5 2006-07-28 09:57:12,082 DEBUG org.hibernate.type.LongType - binding '512' to parameter: 6 2006-07-28 09:57:12,082 DEBUG org.hibernate.type.LongType - binding null to parameter: 7 2006-07-28 09:57:12,082 DEBUG org.hibernate.type.LongType - binding '180030' to parameter: 8
See http://www.javalobby.org/java/forums/t44119.html (google is your friend you know ;-) ) -
19. Re: TaskInstance.setActorId(String) causes set TaskInstance
octomac Jun 20, 2008 4:03 PM (in response to octomac)I managed to find the problem, so I thought I'd come back here and post it just in case this helps anyone else.
The default JBPM database configuration uses the type "BIT" for boolean columns. BIT doesn't map exactly correctly to Java's "true" and "false," or even 1 and 0. As a result, no matter what data I placed into the database, JBPM and Hibernate would interpret it as "true." So, whenever I called, say, TaskInstance.setActorId("Name"), the Hibernate query was inserting correct data to the database, but that data was being interpreted as a BIT value.
To correct the problem, I manually changed each BIT column to a TINYINT(1) type. This ensured that the data Hibernate was passing into my database was interpreted correctly, and as a result, I am now able to handle assignment and creation of tasks correctly.
If anyone else experiences the same problem that I did, hopefully this will help. Thanks again to the JBoss Forum members who assisted me in this matter! -
20. Re: TaskInstance.setActorId(String) causes set TaskInstance
kukeltje Jun 20, 2008 5:29 PM (in response to octomac)What db (and version) are you using? I thought with MySQL you could not even load the ddl if you did not change the bit to tinyint(1)... maybe with some versions you can. It is at least not a generic problem.
-
21. Re: TaskInstance.setActorId(String) causes set TaskInstance
salaboy21 Jun 20, 2008 7:00 PM (in response to octomac)Excelent answer!
i will burn this solution into my mind for this type of problems...
Thanks to you! -
22. Re: TaskInstance.setActorId(String) causes set TaskInstance
lblaauw Jun 21, 2008 2:54 AM (in response to octomac)Hey,
yeah correct for the suplied jBPM ddl script to work, you have to change all the bit definition to boolean. MySQl will indeed change these to tinyint(1) but looking at the ddl script boolean is the correct definition to use. After that change we had no problems initializing our mySQl db with it, well and added semicolons after every line ;-)
Greetz,
Leo"kukeltje" wrote:
What db (and version) are you using? I thought with MySQL you could not even load the ddl if you did not change the bit to tinyint(1)... maybe with some versions you can. It is at least not a generic problem. -
23. Re: TaskInstance.setActorId(String) causes set TaskInstance
kukeltje Jun 22, 2008 9:28 AM (in response to octomac)to work or to load? That is what I asked... were you able to load it at all without modifications? The changes you made are known for a very long time and mentioned in the wiki. And still then, *what version* of MySQL are you using? and on what platform. Only if we get details on that, we can include somthing decent in the releasenotes