[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
17 years, 3 months
[JBoss JIRA] Created: (JBPM-1130) complete Task fails with in transaction with Session closed Error.
by vijay koripella (JIRA)
complete Task fails with in transaction with Session closed Error.
------------------------------------------------------------------
Key: JBPM-1130
URL: http://jira.jboss.com/jira/browse/JBPM-1130
Project: JBoss jBPM
Issue Type: Bug
Affects Versions: jBPM jPDL 3.2.1
Reporter: vijay koripella
Assigned To: Tom Baeyens
When ever we complete a task in the jbp process we get the below exception when ever we are using the transaction supports .
If for the completeTask method we specify the TRANSACTION_NOT_SUPPORTED then this works. So in summary the jbpm complete Task fails when used with in transaction.
This is the below exception we get.
Please also refere to theese links , they are also the same issue.
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4105609#4105609
http://www.mail-archive.com/jboss-user@lists.jboss.org/msg106103.html
Exception:
Caused by: org.springframework.transaction.UnexpectedRollbackException: JTA transaction unexpectedly rolled back (maybe due to a timeout); nested exception is weblogic.transaction.RollbackException: Unexpected exception in beforeCompletion: sync=org.jbpm.db.JobSession$DeleteJobsSynchronization@18db529
Session is closed!
at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:845)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:662)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:632)
at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:314)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:117)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy110.saveClaimAndCompleteClaimUserTask(Unknown Source)
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:585)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
at com.marsh.itg.ddeepa.services.interception.ExportedServiceWrapperFactoryBean$2$1$1.run(ExportedServiceWrapperFactoryBean.java:83)
at com.marsh.itg.ddeepa.services.interception.ExportedServiceWrapperFactoryBean$2$1.run(ExportedServiceWrapperFactoryBean.java:104)
at com.marsh.itg.ddeepa.services.util.common.ThreadLocalVariable.runWith(ThreadLocalVariable.java:43)
at com.marsh.itg.ddeepa.services.interception.ExportedServiceWrapperFactoryBean$2.invoke(ExportedServiceWrapperFactoryBean.java:75)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy110.saveClaimAndCompleteClaimUserTask(Unknown Source)
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:585)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
at org.springframework.remoting.support.RemoteInvocationTraceInterceptor.invoke(RemoteInvocationTraceInterceptor.java:70)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy109.saveClaimAndCompleteClaimUserTask(Unknown Source)
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:585)
at org.springframework.remoting.support.RemoteInvocation.invoke(RemoteInvocation.java:205)
at org.springframework.remoting.support.DefaultRemoteInvocationExecutor.invoke(DefaultRemoteInvocationExecutor.java:38)
at org.springframework.remoting.support.RemoteInvocationBasedExporter.invoke(RemoteInvocationBasedExporter.java:76)
at org.springframework.remoting.support.RemoteInvocationBasedExporter.invokeAndCreateResult(RemoteInvocationBasedExporter.java:112)
at org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter.handleRequest(HttpInvokerServiceExporter.java:117)
at org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle(HttpRequestHandlerAdapter.java:49)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:857)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:792)
at com.marsh.itg.ddeepa.services.platform.MarshDispatcherServlet.access$0(MarshDispatcherServlet.java:1)
at com.marsh.itg.ddeepa.services.platform.MarshDispatcherServlet.doService(MarshDispatcherServlet.java:65)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:475)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:440)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3370)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2117)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2023)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1359)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
at org.springframework.remoting.support.RemoteInvocationUtils.fillInClientStackTraceIfPossible(RemoteInvocationUtils.java:47)
at org.springframework.remoting.support.RemoteInvocationResult.recreate(RemoteInvocationResult.java:105)
at org.springframework.remoting.support.RemoteInvocationBasedAccessor.recreateRemoteInvocationResult(RemoteInvocationBasedAccessor.java:83)
at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.invoke(HttpInvokerClientInterceptor.java:159)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy159.saveClaimAndCompleteClaimUserTask(Unknown Source)
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:585)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:296)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:177)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
at org.springframework.aop.framework.adapter.AfterReturningAdviceInterceptor.invoke(AfterReturningAdviceInterceptor.java:50)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.adapter.MethodBeforeAdviceInterceptor.invoke(MethodBeforeAdviceInterceptor.java:50)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy159.saveClaimAndCompleteClaimUserTask(Unknown Source)
at com.marsh.itg.gws.presentation.order.view.component.OrderPaymentForm.finish(OrderPaymentForm.java:247)
at com.marsh.itg.gws.presentation.order.view.component.OrderPaymentForm.access$2(OrderPaymentForm.java:180)
at com.marsh.itg.gws.presentation.order.view.component.OrderPaymentForm$3.perform(OrderPaymentForm.java:141)
at com.marsh.itg.ddeepa.presentation.framework.components.AbstractActionHandler.execute(AbstractActionHandler.java:31)
at com.marsh.itg.ddeepa.presentation.framework.components.MButton.onSubmit(MButton.java:50)
at wicket.markup.html.form.Form.delegateSubmit(Form.java:574)
at wicket.markup.html.form.Form.onFormSubmitted(Form.java:313)
... 32 more
Caused by: weblogic.transaction.RollbackException: Unexpected exception in beforeCompletion: sync=org.jbpm.db.JobSession$DeleteJobsSynchronization@18db529
Session is closed!
at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1818)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:333)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:227)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:281)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:275)
at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:842)
... 121 more
--
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
17 years, 3 months
[JBoss JIRA] Closed: (JBPM-696) Field Instanciator problems
by Alejandro Guizar (JIRA)
[ https://jira.jboss.org/jira/browse/JBPM-696?page=com.atlassian.jira.plugi... ]
Alejandro Guizar closed JBPM-696.
---------------------------------
Closing issues that I resolved in already released versions.
> Field Instanciator problems
> ---------------------------
>
> Key: JBPM-696
> URL: https://jira.jboss.org/jira/browse/JBPM-696
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.1.1
> Environment: WinXP, Linux running on JBoss Application Server 4.0.3SP1, JDK1.5.0_06
> Reporter: Shai Bentin
> Assignee: Alejandro Guizar
> Priority: Minor
> Fix For: jBPM 3.3.0 GA
>
>
> The method getValue() is see two problems, one is jdk5 related the other is just an idea.
> In jdk5 doing if (type.isAssignableFrom(Set.class)) and such yields a 'false' even when it is supposed to be true...
> if we would write the same if in reverse:
> Set.class.isAssignableFrom(type) we will ge the desired reuslt.
> The other issue is, if we know the super type why do we impose a specific implementation, i.e. if we have a Collection, why do we impose an ArrayList. We have the user's type and we know it is of type collection so why don't we instanciate the requested type....
> Here is how I propose to write this method:
> public static Object getValue(Class type, Element propertyElement) {
> // parse the value
> Object value = null;
> try {
>
> if ( type == String.class ) {
> value = propertyElement.getText();
> } else if ( (type==Integer.class) || (type==int.class) ) {
> value = new Integer( propertyElement.getTextTrim() );
> } else if ( (type==Long.class) || (type==long.class) ) {
> value = new Long( propertyElement.getTextTrim() );
> } else if ( (type==Float.class ) || (type==float.class) ) {
> value = new Float( propertyElement.getTextTrim() );
> } else if ( (type==Double.class ) || (type==double.class) ) {
> value = new Double( propertyElement.getTextTrim() );
> } else if ( (type==Boolean.class ) || (type==boolean.class) ) {
> value = Boolean.valueOf( propertyElement.getTextTrim() );
> } else if ( (type==Character.class ) || (type==char.class) ) {
> value = new Character( propertyElement.getTextTrim().charAt(0) );
> } else if ( (type==Short.class ) || (type==short.class) ) {
> value = new Short( propertyElement.getTextTrim() );
> } else if ( (type==Byte.class ) || (type==byte.class) ) {
> value = new Byte( propertyElement.getTextTrim() );
> } else if (List.class.isAssignableFrom(type)) {
> value = getCollection(propertyElement, (List)type.newInstance());
> } else if (Set.class.isAssignableFrom(type)) {
> value = getCollection(propertyElement, (Set)type.newInstance());
> } else if (Collection.class.isAssignableFrom(type)) {
> value = getCollection(propertyElement, (Collection)type.newInstance());
> } else if (Map.class.isAssignableFrom(type)) {
> value = getMap(propertyElement, (Map)type.newInstance());
> } else if ( type==Element.class ) {
> value = propertyElement;
> } else {
> Constructor constructor = type.getConstructor(new Class[]{String.class});
> if ( (propertyElement.isTextOnly())
> && (constructor!=null) ) {
> value = constructor.newInstance(new Object[]{propertyElement.getTextTrim()});
> }
> }
> } catch (Exception e) {
> log.error("couldn't parse the bean property value '" + propertyElement.asXML() + "' to a '" + type.getName() + "'" );
> throw new JbpmException( e );
> }
> return value;
> }
--
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
17 years, 3 months
[JBoss JIRA] Assigned: (JBPM-1016) ProcessState 'leave' method always returns default transition
by Alejandro Guizar (JIRA)
[ https://jira.jboss.org/jira/browse/JBPM-1016?page=com.atlassian.jira.plug... ]
Alejandro Guizar reassigned JBPM-1016:
--------------------------------------
Assignee: Alejandro Guizar
> ProcessState 'leave' method always returns default transition
> --------------------------------------------------------------
>
> Key: JBPM-1016
> URL: https://jira.jboss.org/jira/browse/JBPM-1016
> Project: JBoss jBPM
> Issue Type: Patch
> Components: Core Engine
> Affects Versions: jBPM 3.2.0
> Reporter: Randy Gullett
> Assignee: Alejandro Guizar
> Fix For: jBPM 3.3.2 GA
>
>
> The leave method for ProcessStates currently automatically takes the default transition despite taking a transition as a parameter. Can it be modified so that it leaves by the transition passed in (if it isn't null) like you'd expect it to? I want to be able to short-circuit my subprocesses in certain scenarios. See the method as it's currently coded below.
> public void leave(ExecutionContext executionContext, Transition transition) {
> ProcessInstance subProcessInstance = executionContext.getSubProcessInstance();
> Token superProcessToken = subProcessInstance.getSuperProcessToken();
> // feed the readable variableInstances
> if ((variableAccesses != null) && (!variableAccesses.isEmpty())) {
> ContextInstance superContextInstance = executionContext.getContextInstance();
> ContextInstance subContextInstance = subProcessInstance.getContextInstance();
> // loop over all the variable accesses
> Iterator iter = variableAccesses.iterator();
> while (iter.hasNext()) {
> VariableAccess variableAccess = (VariableAccess) iter.next();
> // if this variable access is writable
> if (variableAccess.isWritable()) {
> // the variable is copied from the sub process mapped name
> // to the super process variable name
> String mappedName = variableAccess.getMappedName();
> Object value = subContextInstance.getVariable(mappedName);
> String variableName = variableAccess.getVariableName();
> log.debug("copying sub process var '"+mappedName+"' to super process var '"+variableName+"': "+value);
> if (value!=null) {
> superContextInstance.setVariable(variableName, value, superProcessToken);
> }
> }
> }
> }
> // fire the subprocess ended event
> fireEvent(Event.EVENTTYPE_SUBPROCESS_END, executionContext);
> // remove the subprocess reference
> superProcessToken.setSubProcessInstance(null);
>
> // We replaced the normal log generation of super.leave() by creating the log here
> // and overriding the addNodeLog method with an empty version
> superProcessToken.addLog(new ProcessStateLog(this, superProcessToken.getNodeEnter(), new Date(), subProcessInstance));
> // call the subProcessEndAction
> [b]super.leave(executionContext, getDefaultLeavingTransition());[/b] }
> The bold line could be replaced by something like:
> if(transition != null) {
> super.leave(executionContext, transition);
> } else {
> super.leave(executionContext, getDefaultLeavingTransition());
--
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
17 years, 3 months