[JBoss JIRA] Created: (JBPM-1709) JtaDbPersistenceService cannot begin Tx
by Thomas Diesler (JIRA)
JtaDbPersistenceService cannot begin Tx
---------------------------------------
Key: JBPM-1709
URL: https://jira.jboss.org/jira/browse/JBPM-1709
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
Fix For: jBPM 3.3.0
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.persistence.jta.JtaDbPersistenceTest.isTxCreatedByService(JtaDbPersistenceTest.java:194)
at org.jbpm.persistence.jta.JtaDbPersistenceTest.deployProcess(JtaDbPersistenceTest.java:79)
at org.jbpm.persistence.jta.JtaDbPersistenceTest.testServiceTx(JtaDbPersistenceTest.java:59)
at org.jbpm.persistence.jta.JtaDbPersistenceTest.testUserTx(JtaDbPersistenceTest.java:50)
Caused by: javax.transaction.NotSupportedException
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:79)
at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.begin(BaseTransactionManagerDelegate.java:77)
at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.begin(ServerVMClientUserTransaction.java:124)
at org.jbpm.persistence.jta.JtaDbPersistenceService.beginJtaTransaction(JtaDbPersistenceService.java:72)
--
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
15 years, 11 months
[JBoss JIRA] Created: (JBPM-1717) web console: disable job executor launcher and resolve ejb and destination references
by Alejandro Guizar (JIRA)
web console: disable job executor launcher and resolve ejb and destination references
-------------------------------------------------------------------------------------
Key: JBPM-1717
URL: https://jira.jboss.org/jira/browse/JBPM-1717
Project: JBoss jBPM
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jPDL 3
Reporter: Alejandro Guizar
Priority: Blocker
Fix For: jBPM 3.3.0 CR1
After much scratching my head over why the enterprise tests simply do not work despite they already worked in 3.2.3, I realized the job executor was running, which interferes with the enterprise scheduler and message services. The job executor launcher has to be disabled and the commented out ejb and destination references must be uncommented and resolved against the EJBs.
The forum link discusses ear vs sar packaging, which influences how the ejb and destination references will be resolved.
--
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
15 years, 11 months
[JBoss JIRA] Created: (JBPM-1754) StaleObjectLog verbosity control code should be added to flushSession()
by Alejandro Guizar (JIRA)
StaleObjectLog verbosity control code should be added to flushSession()
-----------------------------------------------------------------------
Key: JBPM-1754
URL: https://jira.jboss.org/jira/browse/JBPM-1754
Project: JBoss jBPM
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Alejandro Guizar
Fix For: jBPM 3.3.0 GA
DbPersistenceService.flushSession line #272
Since a StaleObjectStateExcetion occures in flushSession() rather than commit(), StaleObjectLog verbosity control code should be added to flushSession() method as the same manner as commit(). See the following code snippet. An external transaction manager is being used and indeed DbPersistenceService.commit() does nothing.
Exception flushSession() {
if (mustSessionBeFlushed) {
try {
log.debug("flushing hibernate session " + session.toString());
session.flush();
// >>>>>>> begin
} catch (StaleObjectStateException e) {
log.info("optimistic locking failed");
StaleObjectLogConfigurer.staleObjectExceptionsLog.error("optimistic locking failed", e);
return e;
// <<<<<<< end
} catch (Exception e) {
log.error("hibernate flush failed", e);
return e;
}
}
return null;
}
--
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
15 years, 11 months
[JBoss JIRA] Created: (JBPM-1429) Custom FunctionMapper implementation is not picked up in org.jbpm.mail.Mail
by Martin Putz (JIRA)
Custom FunctionMapper implementation is not picked up in org.jbpm.mail.Mail
---------------------------------------------------------------------------
Key: JBPM-1429
URL: https://jira.jboss.org/jira/browse/JBPM-1429
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jPDL 3.2.3
Reporter: Martin Putz
Assignee: Alejandro Guizar
Fix For: JBossBPM-3.3.0
I have created a custom implementation of the FunctionMapper, which provides a custom function I want to use in an email template.
Now, after I add the reference to this FunctionMapper to jbpm.cfg.xml:
<bean name="jbpm.function.mapper" class="org.jbpm.jpdl.el.impl.DateFormatFunctionMapper" singleton="true" />
it will get picked up, but unfortunately, the default Mail class does not use it because it always sets the FunctionMapper to null in the evaluate method (last parameter):
String evaluate(String expression) {
//...
return (String) JbpmExpressionEvaluator.evaluate(expression, executionContext, variableResolver, null);
this should be :
return (String) JbpmExpressionEvaluator.evaluate(expression, executionContext, variableResolver, JbpmExpressionEvaluator.getUsedFunctionMapper());
--
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
15 years, 11 months
[JBoss JIRA] Created: (JBPM-1465) NullPointerException on transaction.rollback() in DbPersistenceService
by Martin Putz (JIRA)
NullPointerException on transaction.rollback() in DbPersistenceService
----------------------------------------------------------------------
Key: JBPM-1465
URL: https://jira.jboss.org/jira/browse/JBPM-1465
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jPDL 3.2.3, SOA 4.2 CP02
Reporter: Martin Putz
Assignee: Alejandro Guizar
We are having NullPointerException from DbPersistenceService when Hibernate throws Exception on close() method. The line is transaction.rollback(); in rollback() method. My two cents is this code should be embraced with "if ( isTransactionEnabled && (transaction != null) )" statement, because we are using external JDBC Connection provider, and the transaction reference never be set.
All calls to the rollback() method in DbPersistenceService are already preceded by a check for
if ( (isTransactionEnabled)
&& (transaction!=null)
) {
except this one after an exception has happened during the Hibernate session.flush call:
Exception flushException = flushSession();
if (flushException!=null) {
rollback(); // missing check if there is a transaction
closeSession();
closeConnection();
throw new JbpmPersistenceException("hibernate flush failed", flushException);
}
--
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
15 years, 11 months
[JBoss JIRA] Created: (JBPM-1119) Timers using EjbSchedulerService are not persisted across JBoss restarts
by Aner Perez (JIRA)
Timers using EjbSchedulerService are not persisted across JBoss restarts
------------------------------------------------------------------------
Key: JBPM-1119
URL: http://jira.jboss.com/jira/browse/JBPM-1119
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.1
Environment: JBoss 4.0.5
Reporter: Aner Perez
Assigned To: Tom Baeyens
Timers created using the EjbSchedulerService do not fire if JBoss is restarted after the timer is set. The reason
is that although the JBPM timer row still exists in the database, there is no corresponding EJB timer to kick off
the JBPM timer action.
EJB timers are supposed to persist across server restarts but there is a catch. JBPM uses an EJB with a "local"
interface to dispatch the JBPM timers. JBoss (as of 4.0.2) has decided to make the jndi name of EJBs with
local interfaces have a unique name by appending an '@' sign and a hashcode to the EJB name. This hash
code is different every time the server is restarted. When the EJB timers are reloaded after a restart, the EJB
that is supposed to receive the timer doesn't exist anymore because it now has a different name (different
hashcode). This causes the timers to be deactivated and they do not fire at the appointed time.
See http://wiki.jboss.org/wiki/Wiki.jsp?page=WhyDoesTheLocalNameContainARando... for an explanation
of the EJB name issue for EJBs with a local interface.
We need a local-jndi-name parameter added to the TimerServiceBean so we can always locate it under the same name
and the timers will work as expected.
adding the following to jboss.xml takes care of this issue:
<session>
<ejb-name>TimerServiceBean</ejb-name>
<local-jndi-name>TimerServiceBean</local-jndi-name>
</session>
--
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
15 years, 11 months