[JBoss JIRA] Created: (JBPM-1708) CommandServiceBean cannot access UserTransaction
by Thomas Diesler (JIRA)
CommandServiceBean cannot access UserTransaction
------------------------------------------------
Key: JBPM-1708
URL: https://jira.jboss.org/jira/browse/JBPM-1708
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
Fix For: jBPM 3.3.0
Caused by: org.jbpm.JbpmException: couldn't start JTA transaction
at org.jbpm.persistence.jta.JtaDbPersistenceService.beginJtaTransaction(JtaDbPersistenceService.java:74)
at org.jbpm.persistence.jta.JtaDbPersistenceService.<init>(JtaDbPersistenceService.java:47)
at org.jbpm.persistence.jta.JtaDbPersistenceServiceFactory.openService(JtaDbPersistenceServiceFactory.java:63)
at org.jbpm.svc.Services.getService(Services.java:156)
at org.jbpm.svc.Services.getPersistenceService(Services.java:195)
at org.jbpm.JbpmContext.getPersistenceService(JbpmContext.java:622)
at org.jbpm.JbpmContext.getGraphSession(JbpmContext.java:566)
at org.jbpm.JbpmContext.deployProcessDefinition(JbpmContext.java:173)
at org.jbpm.command.DeployProcessCommand.execute(DeployProcessCommand.java:68)
at org.jbpm.ejb.impl.CommandServiceBean.execute(CommandServiceBean.java:146)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:169)
at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
... 45 more
Caused by: org.jbpm.JbpmException: could not retrieve user transaction with name java:comp/UserTransaction
at org.jbpm.persistence.jta.JtaDbPersistenceServiceFactory.getUserTransaction(JtaDbPersistenceServiceFactory.java:84)
at org.jbpm.persistence.jta.JtaDbPersistenceService.beginJtaTransaction(JtaDbPersistenceService.java:71)
... 68 more
--
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
14 years, 8 months
[JBoss JIRA] Created: (JBPM-2637) TaskMgmtSession.findTaskInstancesByIds() fails if taskInstanceIds is an empty list
by Toshiya Kobayashi (JIRA)
TaskMgmtSession.findTaskInstancesByIds() fails if taskInstanceIds is an empty list
----------------------------------------------------------------------------------
Key: JBPM-2637
URL: https://jira.jboss.org/jira/browse/JBPM-2637
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 3.2.8, jBPM 3.2.7
Reporter: Toshiya Kobayashi
org.jbpm.command.GetTaskListCommand.execute() throws JbpmPersistenceException if there is no pooled task instances for a given actor even if the actor has personally assigned task instaces.
=====
org.jbpm.persistence.JbpmPersistenceException: couldn't get task instances by ids '[]'
at org.jbpm.db.TaskMgmtSession.findTaskInstancesByIds(TaskMgmtSession.java:204)
at org.jbpm.db.TaskMgmtSession.findPooledTaskInstances(TaskMgmtSession.java:123)
at org.jbpm.JbpmContext.getGroupTaskList(JbpmContext.java:194)
at org.jbpm.command.GetTaskListCommand.execute(GetTaskListCommand.java:54)
at sample.task.ws.TaskSampleWS.test(TaskSampleWS.java:52)
=====
In case of CP01, GetTaskListCommand returns the personal task list without Exception.
This behavior is caused by the change introduced by r4076 in org.jbpm.db.TaskMgmtSession.findTaskInstancesByIds().
r4705
===
public List<TaskInstance> findTaskInstancesByIds(List<Long> taskInstanceIds) {
List<TaskInstance> result;
if (taskInstanceIds.isEmpty()) {
result = Collections.emptyList();
}
else {
try {
Query query = session.getNamedQuery("TaskMgmtSession.findTaskInstancesByIds");
query.setParameterList("taskInstanceIds", taskInstanceIds);
result = CollectionUtil.checkList(query.list(), TaskInstance.class);
}
catch (Exception e) {
handle(e);
throw new JbpmException("couldn't get task instances by ids '" + taskInstanceIds + "'", e);
}
}
return result;
}
===
r4706
===
public List findTaskInstancesByIds(List taskInstanceIds) {
try {
return session.getNamedQuery("TaskMgmtSession.findTaskInstancesByIds")
.setParameterList("taskInstanceIds", taskInstanceIds)
.list();
}
catch (HibernateException e) {
handle(e);
throw new JbpmPersistenceException("couldn't get task instances by ids '"
+ taskInstanceIds
+ "'", e);
}
}
===
The change was related to JBPM-2205 and removed the empty check because the method Collections.emptyList() is not supported in jdk1.4. But I think an equivalent empty check should be restored.
--
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
14 years, 10 months
[JBoss JIRA] Created: (JBPM-2581) Problems with nested Forks
by Sebastian Castellanos (JIRA)
Problems with nested Forks
---------------------------
Key: JBPM-2581
URL: https://jira.jboss.org/jira/browse/JBPM-2581
Project: jBPM
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: jBPM 4.0
Environment: Windows xp, Eclipse galileo and jbpm integred with spring and hibernate.
Reporter: Sebastian Castellanos
Priority: Critical
First off, I apologize for not having made the unit tests, but do not have time at the moment and I think it is a conceptual problem and a unit test would not provide much.
I am integrating jBPM version 4.1 and it proves there too.
The situation is this:
When launched a nested Fork1 another in the second Fork repeats one of its tasks.
In the xml it becomes clear what the situation.
Maybe it is a conceptual issue, and I who is mishandled.
I would be grateful if I can help, as I searched in different places this situation and found no alternative but to post it here.
Greetings.
Sebastian.
--
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
14 years, 10 months
[JBoss JIRA] Created: (JBPM-2263) Multiple timers in node cause EventSource reset
by Asaf Shakarchi (JIRA)
Multiple timers in node cause EventSource reset
-----------------------------------------------
Key: JBPM-2263
URL: https://jira.jboss.org/jira/browse/JBPM-2263
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 3.2.6.SP1
Reporter: Asaf Shakarchi
When having multiple timers in a node, the 2nd timer and all after 'lose' the relationship between the timer->graphElement, thus,
timers are being persisted without the relationship with the graphElement, that causes serious problems in job execution time,
Here's a deep detail explaination (considering there are two timers in one task node)
When entering a node, the 'EVENTTYPE_NODE_ENTER' event gets fired, which causes two 'create timer actions' to be created via CreateTimerAction, one per timer,
In GraphElement->fireEvent() there's the following piece of code:
...
fireAndPropagateEvent(eventType, executionContext);
} finally {
executionContext.setEventSource(null);
}
...
This part seems to clean up the eventSource, but that causes the 2nd timer and above to 'lose' the association to the graphElement(Node ID) the timer was created from,
I assume its not taken into consideration that the create timer fires another 'inner' event that causes the eventSource to be reset:
CreateTimerAction->createTimer(..) {
graphElement.fireEvent(Event.EVENTTYPE_TIMER_CREATE, executionContext);
}
For now, we commented out the GraphElement->fireEvent->'executionContext.setEventSource(null);' line, but I don't really understand the impact of that,
If that line is important, I think it's better to perform the cleanup only in case the fire event is not invoked in an 'inner' fire event call, or find another approach,
Thanks.
--
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
14 years, 10 months