[JBoss JIRA] Created: (JBPM-2692) Still problems with variables of Serializable objects
by Mauro Molinari (JIRA)
Still problems with variables of Serializable objects
-----------------------------------------------------
Key: JBPM-2692
URL: https://jira.jboss.org/jira/browse/JBPM-2692
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 3.2.6.SP1
Environment: jBPM 3.2.6.SP1 embedded into a web application
Reporter: Mauro Molinari
There …
[View More]are times in which when calling org.jbpm.context.exe.VariableInstance.getValue(), the proprty token is null. In this case, if the variable object is of a Serializable class and this class is in the PAR, calling getValue() will fail with a ClassNotFound exception if the process class loader is not the one who loaded the SerializableToByteArrayConverter class. This is because the method org.jbpm.context.exe.converter.SerializableToByteArrayConverter.revert(ByteArray) (without the token) is called and a plain ObjectInputStream is used to do the deserialization.
I don't have a simple test case to reproduce, but this is what I am doing:
- my webapp application is retreiving all the logs associated to a ProcessInstance using org.jbpm.db.LoggingSession.findLogsByProcessInstance(long)
- it is iterating over the collection and, for each ProcessLog instance, it is retreiving the variable instance values (for example: org.jbpm.context.log.VariableCreateLog the method org.jbpm.context.log.VariableLog.getVariableInstance() is called; for a org.jbpm.context.log.VariableUpdateLog the methods org.jbpm.context.log.VariableUpdateLog.getOldValue() and org.jbpm.context.log.VariableUpdateLog.getNewValue() are called and so on)
- a ClassNotFoundException is launched; the class loader in use is that of the webapp, so it's normal that the class of the variable value cannot be found, since it is a serializable class provided by the PAR.
I don't know why token is null: should it be restored by Hibernate? Looking at org.jbpm.context.exe.VariableInstance the only explicit code that sets the token property is in org.jbpm.context.exe.VariableInstance.create(Token, String, Object).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
14 years, 4 months
[JBoss JIRA] Created: (JBPM-2797) Bug in LockMonitor unlocks EVERY Job, not only overdue ones
by Bernd Ruecker (JIRA)
Bug in LockMonitor unlocks EVERY Job, not only overdue ones
-----------------------------------------------------------
Key: JBPM-2797
URL: https://jira.jboss.org/jira/browse/JBPM-2797
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 3.2.8
Reporter: Bernd Ruecker
Assignee: Bernd Ruecker
The LockMonitorThread has a really …
[View More]huge bug.
It queries all jobs with overdue lock time:
Date threshold = new Date(System.currentTimeMillis() - maxLockTime - lockBufferTime);
List overdueJobs = jbpmContext.getJobSession().findJobsWithOverdueLockTime(threshold);
by this query:
<query name="JobSession.findJobsWithOverdueLockTime">
select job
from org.jbpm.job.Job as job
where job.lockTime > :threshold
</query>
This finds all jobs with a lock timer NEWER than the treshold, not OLDER as it should be. So the query must be:
<query name="JobSession.findJobsWithOverdueLockTime">
select job
from org.jbpm.job.Job as job
where job.lockTime < :threshold
</query>
So if a job runs exactly at the time the LockMonitorThread comes active, this leads to a StaleObjectException in the JobExecution. Since the LockMonitorThread runs only every minute, this is a pretty rare case. The more puzzling it was to find ;-) Surprising, that it wasn't recognized that long!
I commit the changed query to HEAD.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
14 years, 4 months
[JBoss JIRA] Created: (JBPM-2823) Lazy loading of ExceptionHandler causes Exception in JTA Env
by Robert Schmelzer (JIRA)
Lazy loading of ExceptionHandler causes Exception in JTA Env
------------------------------------------------------------
Key: JBPM-2823
URL: https://jira.jboss.org/jira/browse/JBPM-2823
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jBPM 3.2.8
Reporter: Robert Schmelzer
The fix for https://jira.jboss.org/jira/browse/JBPM-1775 does not work in JTA environment with …
[View More]JtaDbPersistenceService and following config:
jbpm-context>
<service name="persistence">
<factory>
<bean class="org.jbpm.persistence.jta.JtaDbPersistenceServiceFactory">
<field name="isCurrentSessionEnabled"><true /></field>
<field name="isTransactionEnabled"><false /></field>
</bean>
</factory>
</service>
<service name="tx" factory="org.jbpm.tx.TxServiceFactory"/>
<service name="message" factory="at.telekom.wfm.process.queue.JbpmJmsMessageServiceFactory" />
<service name="scheduler" factory="org.jbpm.scheduler.db.DbSchedulerServiceFactory" />
<service name="authentication" factory="org.jbpm.security.authentication.DefaultAuthenticationServiceFactory" />
</jbpm-context>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
14 years, 4 months