[JBoss JIRA] Created: (JBPM-2287) Can't fork to Task
by Oliver Lauer (JIRA)
Can't fork to Task
------------------
Key: JBPM-2287
URL: https://jira.jboss.org/jira/browse/JBPM-2287
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jBPM 4.0.0.Beta2
Environment: JBPM 4.0 Beta2 with JBoss 5.0 Windows XP
Reporter: Oliver Lauer
Hi,
I can't fork to a or several tasks. I get the following exception:
19:33:30,514 INF | [DefaultCommandService] exception while executing command org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd@1075056
org.jbpm.api.JbpmException: unsuppported extension org.jbpm.jpdl.internal.model.JpdlExecution
at org.jbpm.pvm.internal.model.ExecutionImpl.getExtension(ExecutionImpl.java:1108)
at org.jbpm.jpdl.internal.activity.TaskActivity.execute(TaskActivity.java:48)
When I debug the source code I see the last method called is the following which always throw an exception:
public <T> T getExtension(Class<T> extensionClass) {
if (extensionClass == null) {
throw new JbpmException(
"extensionClass is null. and this execution doesn't support extensions");
}
throw new JbpmException("unsuppported extension "
+ extensionClass.getName());
}
--
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, 6 months
[JBoss JIRA] Created: (JBPM-2079) optimistic locking test
by Tom Baeyens (JIRA)
optimistic locking test
-----------------------
Key: JBPM-2079
URL: https://jira.jboss.org/jira/browse/JBPM-2079
Project: JBoss jBPM
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Tom Baeyens
Assignee: Alejandro Guizar
Fix For: jBPM 4.0.0.Beta1
create a minimal test that produces an optimistic locking failure.
I believe the simplest way to test this is something like this:
Start a process instance with 2 wait states and put it in the first wait state.
EnvironmentFactory environmentFactory = get it from some configuration file
Environment environment1 = environmentFactory.openEnvironment();
Session session1 = environment1.get(Session.class);
ExecutionImpl processInstance1 = session1.load(ExecutionImpl.class, processInstanceDbid);
Environment environment2 = environmentFactory.openEnvironment();
Session session2 = environment2.get(Session.class);
ExecutionImpl processInstance2 = session2.load(ExecutionImpl.class, processInstanceDbid);
processInstance1.signal();
processInstance2.signal();
environment2.close();
environment1.close();
--
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, 6 months
[JBoss JIRA] Created: (JBPM-1701) in WireContext: bug when elements inside a list are referenced from outside the list.
by Guillaume Porcher (JIRA)
in WireContext: bug when elements inside a list are referenced from outside the list.
-------------------------------------------------------------------------------------
Key: JBPM-1701
URL: https://jira.jboss.org/jira/browse/JBPM-1701
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: PVM
Reporter: Guillaume Porcher
Priority: Critical
In this example:
public void testNamedElements() {
String contextText =
"<objects>" +
" <list name='l'>" +
" <object class='java.lang.Object' name='s'/>" +
" </list>" +
" <ref name='r' object='s' />" +
"</objects>";
WireContext wireContext = createWireContext(contextText);
assertNotNull(wireContext.get("s"));
assertNotNull(wireContext.get("l"));
assertNotNull(wireContext.get("r"));
assertSame(wireContext.get("s"), wireContext.get("r"));
wireContext = createWireContext(contextText);
assertNotNull(wireContext.get("r"));
assertNotNull(wireContext.get("l"));
assertNotNull(wireContext.get("s"));
assertSame(wireContext.get("s"), wireContext.get("r"));
}
the last assertion fails.
If the reference is accessed first, the object s is created when the reference is created, and then when the list is created.
If the list is created first, the reference uses the object in the list.
To fix this bug, I see 2 solutions:
- we can prevent the user from defining objects with names in lists.
- we can fix the creation of the list to check if some of the elements have already been created.
I think the first solution is better. If an element can be shared by more than one entity, it should be defined outside of all the entities and the entities should use ObjectReferences to access the shared element.
--
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, 6 months