[JBoss JIRA] Created: (JBPM-2890) Reminder repeat attribute set via expression or variable
by Marta Psenkova (JIRA)
Reminder repeat attribute set via expression or variable
--------------------------------------------------------
Key: JBPM-2890
URL: https://jira.jboss.org/browse/JBPM-2890
Project: jBPM
Issue Type: Patch
Security Level: Public (Everyone can see)
Components: Runtime Engine
Reporter: Marta Psenkova
Attachments: reminder_repeat.pvm.r6402.patch
In task reminder it is not possible to use variables in repeat attribute, because it is not parsed, e.g.:
<task assignee="${user}" g="224,236,193,52" name="myTask">
<reminder duedate="#{myTask_duedate}" template="my-mail-template" repeat="#{myTask_repeat}" />
<transition to="nextStep"/>
</task>
The solution here is to parse expression when timer (TimerImpl) is created
See patch attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[JBoss JIRA] Created: (JBPM-2886) job is not released when the transaction is marked as rollback only
by Adam Laczynski (JIRA)
job is not released when the transaction is marked as rollback only
-------------------------------------------------------------------
Key: JBPM-2886
URL: https://jira.jboss.org/browse/JBPM-2886
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.3
Environment: - WebLogic 10.2.3
- jbpm 4.3
- Oracle 10g
Reporter: Adam Laczynski
Job is not released when the exception occurred during job execution and transaction is marked as rollback only because synchronization cannot be registered in transaction (according to javax.transaction.Transaction#registerSynchronization java doc: @exception RollbackException Thrown to indicate that the transaction has been marked for rollback only).
Following exception is thrown:
org.jbpm.api.JbpmException: couldn't register synchronization: test1
at org.jbpm.pvm.internal.tx.JtaTransaction.registerSynchronization(JtaTransaction.java:78)
at org.jbpm.pvm.internal.cmd.ExecuteJobCmd.handleJobExecutionException(ExecuteJobCmd.java:111)
at org.jbpm.pvm.internal.cmd.ExecuteJobCmd.execute(ExecuteJobCmd.java:92)
at org.jbpm.pvm.internal.cmd.ExecuteJobCmd.execute(ExecuteJobCmd.java:42)
at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
at org.jbpm.pvm.internal.tx.JtaTransactionInterceptor.executeInNewTx(JtaTransactionInterceptor.java:87)
at org.jbpm.pvm.internal.tx.JtaTransactionInterceptor.execute(JtaTransactionInterceptor.java:66)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
at org.jbpm.pvm.internal.tx.JtaRetryInterceptor.executeWithRetry(JtaRetryInterceptor.java:52)
at org.jbpm.pvm.internal.tx.JtaRetryInterceptor.execute(JtaRetryInterceptor.java:45)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:43)
at org.jbpm.pvm.internal.jobexecutor.JobParcel.run(JobParcel.java:48)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
After that, job could be acquired again but only after the lockMillis (default 30 minutes).
IMO in such case the job has to be released because it delay job execution. To achieve it JobExceptionHandler (with small modification) has to be register before invoking job.execute(...) in org.jbpm.pvm.internal.cmd.ExecuteJobCmd:76. Exception could be passed to the handler in the catch block.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[JBoss JIRA] Created: (JBPM-2648) Candidate-Groups
by Sebastian Castellanos (JIRA)
Candidate-Groups
-----------------
Key: JBPM-2648
URL: https://jira.jboss.org/jira/browse/JBPM-2648
Project: jBPM
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.2
Reporter: Sebastian Castellanos
Hi,
I have a problem when seeking tasks using candidate-groups.
I created tarea1 which has associated candidate-groups "Group1, Group2, Group3.
Then I have a user "sebastian" which is a member of Group 1, Group 2 and Group 3.
The problem is that when I run taskService().findGroupTasks("sebastian");
I returned a list of 3 tasks equal, Tarea1, Tarea1, Tarea1. When it should be listed just once the task (Tarea1).
I'm not sure if it's a conceptual issue or a bug in the API.
I would be grateful for your help.
P/d: I'm not using swimlane because I had problems with respect to the Fork / Join.
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, 5 months
[JBoss JIRA] Created: (JBPM-2534) add signalling action to console
by Tom Baeyens (JIRA)
add signalling action to console
--------------------------------
Key: JBPM-2534
URL: https://jira.jboss.org/jira/browse/JBPM-2534
Project: jBPM
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Tom Baeyens
Assignee: Joram Barrez
Fix For: jBPM 4.3
signalling capabilities need to be added to the console so that all examples become executable. now there are a couple excluded from deployment.
in case of a state activity, offering the signal action is obvious.
but we still need to work out in which other situations we offer signalling. if that is not clear, then we could just stick with offering the signal action for all executions for which condition (execution.isActive() && "state".equals(execution.getActivity().getType()) resolves to true
--
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, 6 months