[JBoss JIRA] Created: (JBPM-2482) console should pass authenticated user to engine operations
by Tom Baeyens (JIRA)
console should pass authenticated user to engine operations
-----------------------------------------------------------
Key: JBPM-2482
URL: https://jira.jboss.org/jira/browse/JBPM-2482
Project: jBPM
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Console
Reporter: Tom Baeyens
Assignee: Joram Barrez
Fix For: jBPM 4.2
following pieces of console code should be revisisted so that the authenticated user is passed to the engine operations:
public ProcessInstanceRef newInstance(String definitionId, Map<String, Object> processVars)
{
Environment env = ((EnvironmentFactory)processEngine).openEnvironment();
try
{
ExecutionService execService = this.processEngine.getExecutionService();
Execution exec = execService.startProcessInstanceById(definitionId);
execService.setVariables(exec.getId(), processVars);
return ModelAdaptor.adoptExecution((ExecutionImpl)exec);
}
finally{
env.close();
}
}
First, the API needs to expose a way on how to set the authenticated user programmatically.
--
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-2553) Violation of unique constratin with two splits
by David Loiseau (JIRA)
Violation of unique constratin with two splits
----------------------------------------------
Key: JBPM-2553
URL: https://jira.jboss.org/jira/browse/JBPM-2553
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.1
Reporter: David Loiseau
Thow split steps with two identical transition names cause a violation of unique constraint in JBPM4_EXECUTION table.
Process Definition:
<?xml version="1.0" encoding="UTF-8"?>
<process key="test" name="test" xmlns="http://jbpm.org/4.0/jpdl">
<start g="82,38,41,27" name="start1">
<transition g="-43,-18" name="to fork1" to="fork1"/>
</start>
<fork g="79,112,25,20" name="fork1">
<transition name="to task1" to="task1" g="-44,-18"/>
<transition name="to task2" to="task2" g="-44,-18"/>
</fork>
<fork g="88,263,65,27" name="fork2">
<transition name="to task1" to="task4" g="-44,-18"/>
<transition name="to task3" to="task3" g="-44,-18"/>
</fork>
<task assignee="test" name="task1" g="75,189,60,42">
<transition name="to fork2" to="fork2" g="-43,-18"/>
</task>
<task name="task2" g="163,117,61,31"/>
<task name="task3" g="189,268,59,37"/>
<task name="task4" g="93,340,52,40"/>
</process>
Test code:
ProcessEngine processEngine = Configuration.getProcessEngine();
RepositoryService repositoryService = (RepositoryService) processEngine.get(RepositoryService.class);
String deploymentId = repositoryService
.createDeployment()
.addResourceFromClasspath("test.jpdl.xml")
.deploy();
Execution execution = processEngine.getExecutionService().startProcessInstanceByKey("test");
Task task = (Task)processEngine.getTaskService().findPersonalTasks("test").get(0);
processEngine.getTaskService().completeTask(task.getId(),"to fork2");
Exception:
Caused by: java.sql.SQLException: Violation of unique constraint $$: duplicate value(s) for column(s) $$: SYS_CT_970 in statement [update JBPM4_EXECUTION set DBVERSION_=?, ACTIVITYNAME_=?, PROCDEFID_=?, HASVARS_=?, NAME_=?, KEY_=?, ID_=?, STATE_=?, SUSPHISTSTATE_=?, PRIORITY_=?, HISACTINST_=?, PARENT_=?, INSTANCE_=?, SUPEREXEC_=?, SUBPROCINST_=? where DBID_=? and DBVERSION_=?]
at org.hsqldb.jdbc.Util.throwError(Unknown Source)
at org.hsqldb.jdbc.jdbcPreparedStatement.executeUpdate(Unknown Source)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2435)
... 39 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, 5 months
[JBoss JIRA] Created: (JBPM-2614) TimerSessionBinding does not allow 3rd party TimerSession implementations
by sdfsd sdfsd (JIRA)
TimerSessionBinding does not allow 3rd party TimerSession implementations
-------------------------------------------------------------------------
Key: JBPM-2614
URL: https://jira.jboss.org/jira/browse/JBPM-2614
Project: jBPM
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.x
Reporter: sdfsd sdfsd
We want to use our own scheduler for Timers but even if the infrastracture is in place one can not configure it's own implementation of TimerSession.
The <timer-session/> element allows only target ='ejb' and nothing else will be parsed by the method TimerSessionBinding.parse(). I can't understand why can't I provide my own implementation of TimerSession.
the Solution would be to change add and attribute className to <timer-session/> element and to change the TimerSessionBinding.parse() method like this :
objectDescriptor.setClassName(XmlUtil.attribute(element, "class"));
you can also add a target like 'custom' and only then check the 'class' attribute. Something like this:
public Object parse(Element element, Parse parse, Parser parser) {
ObjectDescriptor objectDescriptor = new ObjectDescriptor();
String target = XmlUtil.attribute(element, "target");
if ((target!=null){
if ("ejb".equalsIgnoreCase(target))) {
objectDescriptor.setClassName("org.jbpm.enterprise.internal.ejb.EnterpriseTimerSession");
}
else if ("custom".equalsIgnoreCase(target))) {
objectDescriptor.setClassName(XmlUtil.attribute(element, "class"));
}
} else {
// wire the JobExecutorTimerSession
objectDescriptor.setClassName(JobExecutorTimerSession.class.getName());
// inject fields
objectDescriptor.addInjection("transaction", new TransactionRefDescriptor());
objectDescriptor.addInjection("jobExecutor", new EnvDescriptor(JobExecutor.class));
objectDescriptor.addInjection("session", new ContextTypeRefDescriptor(Session.class));
}
return objectDescriptor;
}
--
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-2635) Error deploying a process with a bad version format
by Javier Alperte (JIRA)
Error deploying a process with a bad version format
---------------------------------------------------
Key: JBPM-2635
URL: https://jira.jboss.org/jira/browse/JBPM-2635
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.2
Environment: MySQL Ver 14.12 Distrib 5.0.75, for debian-linux-gnu (i486) using readline 5.2
Java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Server VM (build 14.2-b01, mixed mode)
JBoss AS 4.2.3 GA
JBoss Portal 2.7.2
Hibernate Core 3.3.2.GA
Hibernate EntityManager 3.4.0.GA
Hibernate Annotations 3.4.0.GA
Hibernate Validator 3.1.0.GA
Hibernate Commons Annotations 3.1.0.GA
Seam 2.2.0.GA
Richfaces 3.3.1.GA
Portlet Bridge 1.0.0.CR2
Reporter: Javier Alperte
Error uploading a jpdl file with a wrong version format (aka: 1.0.0) which leaves the database inconsistent (bad formatted jpdl file) and does not let upload a new process definition with the same Name, because the service attempts to retrieve the previous version and throws an exception when parse the file. (NOTE: I am uploading a BAR file and the jpdl file is inside the bar)
In the RepositorySessionImpl you are doing the following steps:
session.save(deploymentImpl); // will also save the attached resources
deployerManager.deploy(deploymentImpl);
That saves the Deployment data before checking the consistency of the jpdl file.
--
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-2807) A task is put in an unusable state if the execution it belongs to is signalled
by Ronald van Kuijk (JIRA)
A task is put in an unusable state if the execution it belongs to is signalled
-------------------------------------------------------------------------------
Key: JBPM-2807
URL: https://jira.jboss.org/jira/browse/JBPM-2807
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jBPM 4.0, jBPM 4.1, jBPM 4.2, jBPM 4.3, jBPM 4.x
Reporter: Ronald van Kuijk
Priority: Minor
Fix For: jBPM 4.x
When an execution is signalled, the task belonging to that execution becomes unusable. It is made 'not-signalling', has no exection (thus cannot be ended, which you would not want to) but it keeps showing up in the tasklist....
Proposed solution is to have an additional task state (like the 'timeout' that is introduced). If an execution is signalled, the task is 'cancelled' this is something completely different then it being completed or any other state....
The behaviour of which transition will be taken will not be different from what it is now.... A warning will be logged that a execution is signalled and it would be better to act on the task itself...
Subtasks will/should be treated the same.
--
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