[JBoss JIRA] Created: (JBPM-1423) idenitfy supported deployments
by Tom Baeyens (JIRA)
idenitfy supported deployments
------------------------------
Key: JBPM-1423
URL: https://jira.jboss.org/jira/browse/JBPM-1423
Project: JBoss jBPM
Issue Type: Task
Security Level: Public (Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Priority: Critical
Identify the supported deployment environments and the corresponding configurations.
This basically will come down to transaction configurations in pvm, hibernate, spring, ejb and the likes.
Configurations:
* pvm
* hibernate
* ejb
Controlling transactions:
* Hibernate transaction programmatic
* Direct JDBC connection programmatic
* JTA UserTransaction programmatic (== BMT?)
* CMT through EJB deployment descriptors
--
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, 7 months
[JBoss JIRA] Created: (JBPM-1162) Problem with exception handling within the Decision nodes
by Jon Folland (JIRA)
Problem with exception handling within the Decision nodes
---------------------------------------------------------
Key: JBPM-1162
URL: http://jira.jboss.com/jira/browse/JBPM-1162
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Environment: Vaio laptop running Windows Vista, Java 1.5, JBPM 3.2.2
Reporter: Jon Folland
Assigned To: Tom Baeyens
I believe there may be a bug in the Decision class where exception handling is concerned which causes this failure:
If the line: String transitionName = decisionHandler.decide(executionContext); ...
...in the method public void execute(ExecutionContext executionContext)
throws an exception, which is caught here in the same method:
raiseException(exception, executionContext);
We miss the block:
if (transition==null) {
transition = getDefaultLeavingTransition();
log.debug("decision didn't select transition, taking default "+transition);
}
So when executionContext.leaveNode(transition); is called at the bottom, there wil be no transition set.
I believe we need to check for a tranistion==null condition regardless of whether an excpetion has been handled. Otherwise you will never be able to handle an exception in a Decision without another unhandled exception being thrown (which kind of defeits the point :-)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 7 months
[JBoss JIRA] Created: (JBPM-1139) The ClassUtil class is not thread-safe
by Wojciech Gdela (JIRA)
The ClassUtil class is not thread-safe
--------------------------------------
Key: JBPM-1139
URL: http://jira.jboss.com/jira/browse/JBPM-1139
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.3
Reporter: Wojciech Gdela
Assigned To: Tom Baeyens
Attachments: ClassUtil-concurrency-issue.zip
The ClassUtil class is not thread-safe. The exception will occur when two thread simultanously try do deserialize variables from two different process definitions. Look at the code:
{code}
public ContextObjectInputStream(final InputStream in,
ProcessInstance processInstance) throws IOException {
super(in);
this.setProcessInstance(processInstance);
ClassUtil.setProcessInstance(processInstance);
}
...
protected Class resolveClass(final ObjectStreamClass desc)
throws IOException, ClassNotFoundException {
return ClassUtil.forName(desc.getName(), ContextObjectInputStream.class);
}
...
ContextObjectInputStream cois = new ContextObjectInputStream(bais, definition.createProcessInstance());
// when here another thread tries to execute the same code with another process instance there will be a problem
return cois.readObject();
{/code}
Further description of issue is in attached test case.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 7 months
[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-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
[JBoss JIRA] Created: (JBPM-2047) PersistenceDbServiceTest and PersistenceServiceDbTest are dependent
by Jiri Pechanec (JIRA)
PersistenceDbServiceTest and PersistenceServiceDbTest are dependent
-------------------------------------------------------------------
Key: JBPM-2047
URL: https://jira.jboss.org/jira/browse/JBPM-2047
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core Engine
Affects Versions: jBPM-3.2.5.SP1
Reporter: Jiri Pechanec
Assignee: Thomas Diesler
The tests can fail based on the execution order of these tests.
If PersistenceDbServiceTest is executed first then it sets session factory to MockSessionFactory.
Unfortunately it seems that the setting is SAME for ALL future newly created JbpmContexts.
PersistenceServiceDbTest then tests that the factory is null but it is not assertNull(persistenceServiceFactory.sessionFactory). The same test also tests few more features that ends in calls of unsupported operations on the MockSessionFactory.
I am not sure if this is a problem of test - then the sessionFactory should be cleard after test or if it is wrong that the setting is shared for all JBpmContexts.
--
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, 11 months