[JBoss JIRA] Created: (JBPM-1126) ProcessDeifnition substates load into top level node list
by James Violette (JIRA)
ProcessDeifnition substates load into top level node list
---------------------------------------------------------
Key: JBPM-1126
URL: http://jira.jboss.com/jira/browse/JBPM-1126
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM 3.1.4
Environment: ANY
Reporter: James Violette
Assigned To: Tom Baeyens
Priority: Minor
The ProcessDefinition.hbm.xml nodes list must have a where clause to avoid loading substate nodes into the top level node list.
The released nodes list definition
<list name="nodes" cascade="all">
<cache usage="nonstrict-read-write"/>
<key column="PROCESSDEFINITION_" />
<list-index column="NODECOLLECTIONINDEX_" />
<one-to-many class="org.jbpm.graph.def.Node" />
</list>
should be
<list name="nodes" cascade="all" where="superstate is null" >
<cache usage="nonstrict-read-write"/>
<key column="PROCESSDEFINITION_" />
<list-index column="NODECOLLECTIONINDEX_" />
<one-to-many class="org.jbpm.graph.def.Node" />
</list>
--
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
16 years, 1 month
[JBoss JIRA] Updated: (JBPM-376) Scripts on a node do not get to write their variables before node.leave() causes other nodes to be executed.
by Thomas Diesler (JIRA)
[ https://jira.jboss.org/jira/browse/JBPM-376?page=com.atlassian.jira.plugi... ]
Thomas Diesler updated JBPM-376:
--------------------------------
Fix Version/s: jBPM 3.3.2 GA
Revisit open bugs
> Scripts on a node do not get to write their variables before node.leave() causes other nodes to be executed.
> ------------------------------------------------------------------------------------------------------------
>
> Key: JBPM-376
> URL: https://jira.jboss.org/jira/browse/JBPM-376
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.0.1
> Reporter: Colin Wilson-Salt
> Fix For: jBPM 3.3.2 GA
>
>
> A script on a node requires a node.leave in order to continue execution past the node. This means that the write back of the variables to the ExecutionContext does not happen until after the following nodes have been executed.
> A workaround is to set the variables yourself, by using executionContext.setVariable before calling node.leave.
> In the following example, it looks like the variable v will be available for use in the followin nodes, but the assignment doesn't happen until after those following nodes are executed (or until the process reaches a wait state).
> <node name="x">
> <script>
> <variable name='v' access='write'/>
> <expression>
> <![CDATA[
> v = true;
> node.leave(executionContext);
> ]]>
> </expression>
> </script>
> <transition to="y"/>
> </node>
--
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
16 years, 1 month
[JBoss JIRA] Updated: (JBPM-1014) Logging in often yields an error
by Thomas Diesler (JIRA)
[ https://jira.jboss.org/jira/browse/JBPM-1014?page=com.atlassian.jira.plug... ]
Thomas Diesler updated JBPM-1014:
---------------------------------
Fix Version/s: jBPM 3.3.2 GA
Revisit open bugs
> Logging in often yields an error
> --------------------------------
>
> Key: JBPM-1014
> URL: https://jira.jboss.org/jira/browse/JBPM-1014
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Console
> Affects Versions: jBPM 3.2.1
> Environment: FC6 - Sun Java 1.5.0.12 - Firefox 1.5.0.12
> Reporter: Micah Modell
> Fix For: jBPM 3.3.2 GA
>
>
> I regularly get the following error when I attempt to log in. If I go back to the console and try again from the actual page (not a reload) then it seems to remedy the problem:
> 00:14:54,587 ERROR [[Faces Servlet]] Servlet.service() for servlet Faces Servlet threw exception
> javax.faces.application.ViewExpiredException: viewId:/sa/procdef.jsf - View /sa/procdef.jsf could not be restored.
> at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:180)
> at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> at java.lang.Thread.run(Thread.java:595)
--
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
16 years, 1 month
[JBoss JIRA] Updated: (JBPM-1013) Logging out and back in seems to render an error.
by Thomas Diesler (JIRA)
[ https://jira.jboss.org/jira/browse/JBPM-1013?page=com.atlassian.jira.plug... ]
Thomas Diesler updated JBPM-1013:
---------------------------------
Fix Version/s: jBPM 3.3.2 GA
Revisit issues that have votes
> Logging out and back in seems to render an error.
> -------------------------------------------------
>
> Key: JBPM-1013
> URL: https://jira.jboss.org/jira/browse/JBPM-1013
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Console
> Affects Versions: jBPM 3.2.1
> Environment: Fedora Core 6 + Firefox 1.5.0.12 + Sun Java 1.5.0.12
> Reporter: Micah Modell
> Fix For: jBPM 3.3.2 GA
>
>
> If you log in and leave for about fifteen minutes or so, then return and attempt to log oout and back in as another user, you get the following (ugly) jsp error:
> --------------
> HTTP Status 500 -
> type Exception report
> message
> description The server encountered an internal error () that prevented it from fulfilling this request.
> exception
> javax.servlet.ServletException: viewId:/sa/identities.jsf - View /sa/identities.jsf could not be restored.
> javax.faces.webapp.FacesServlet.service(FacesServlet.java:249)
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> root cause
> javax.faces.application.ViewExpiredException: viewId:/sa/identities.jsf - View /sa/identities.jsf could not be restored.
> com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:180)
> com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
> com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
> javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> note The full stack trace of the root cause is available in the Apache Tomcat/5.5.17 logs.
> Apache Tomcat/5.5.17
> --------------
> and the following stack trace on the console:
> --------------
> javax.faces.application.ViewExpiredException: viewId:/sa/identities.jsf - View /sa/identities.jsf could not be restored.
> at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:180)
> at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> at java.lang.Thread.run(Thread.java:595)
--
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
16 years, 1 month
[JBoss JIRA] Updated: (JBPM-627) Cancel timer problem
by Thomas Diesler (JIRA)
[ https://jira.jboss.org/jira/browse/JBPM-627?page=com.atlassian.jira.plugi... ]
Thomas Diesler updated JBPM-627:
--------------------------------
Fix Version/s: jBPM 3.3.2 GA
Revisit issues that have votes
> Cancel timer problem
> --------------------
>
> Key: JBPM-627
> URL: https://jira.jboss.org/jira/browse/JBPM-627
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.1.0
> Environment: Windows XP Pro
> Database: DB2/400 v5r3, HSQLDB
> Reporter: Mark Shotton
> Fix For: jBPM 3.3.2 GA
>
> Attachments: JBPM-627-screenshots.doc
>
>
> As reported in issue JBPM-594, timers do not get deleted on the cancel-timer event. This is because in SchedulerSession.cancelTimersByName(String, Token), the timer is deleted by a call to SchedulerSession.deleteTimer:
> public void deleteTimer(Timer timer) {
> if (! deletedTimers.contains(timer)) {
> try {
> session.delete(timer);
> deletedTimers.add(timer);
> } catch (Exception e) {
> log.error(e);
> jbpmSession.handleException();
> throw new JbpmException("couldn't delete timer '"+timer+"' from the database", e);
> }
> }
> }
> but in SchedulerThread, the timer is saved again if timer.getRepeat() is not null:
> public long executeTimers() {
> long millisTillNextTimerIsDue = -1;
> boolean isDueDateInPast = true;
>
> JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext(jbpmContextName);
> try {
> SchedulerSession schedulerSession = jbpmContext.getSchedulerSession();
>
> log.debug("checking for timers");
> Iterator iter = schedulerSession.findTimersByDueDate();
> while( (iter.hasNext())
> && (isDueDateInPast)
> ) {
> Timer timer = (Timer) iter.next();
> log.debug("found timer "+timer);
>
> // if this timer is due
> if (timer.isDue()) {
> log.debug("executing timer '"+timer+"'");
>
> // execute
> timer.execute();
>
> // save the process instance
> jbpmContext.save(timer.getProcessInstance());
>
> // notify the listeners (e.g. the scheduler servlet)
> notifyListeners(timer);
>
> // if there was an exception, just save the timer
> if (timer.getException()!=null) {
> schedulerSession.saveTimer(timer);
>
> // if repeat is specified
> } else if (timer.getRepeat()!=null) {
> // update timer by adding the repeat duration
> Date dueDate = timer.getDueDate();
>
> // suppose that it took the timer runner thread a
> // very long time to execute the timers.
> // then the repeat action dueDate could already have passed.
> while (dueDate.getTime()<=System.currentTimeMillis()) {
> dueDate = businessCalendar
> .add(dueDate,
> new Duration(timer.getRepeat()));
> }
> timer.setDueDate( dueDate );
> // save the updated timer in the database
> log.debug("saving updated timer for repetition '"+timer+"' in '"+(dueDate.getTime()-System.currentTimeMillis())+"' millis");
> schedulerSession.saveTimer(timer);
>
> } else {
> // delete this timer
> log.debug("deleting timer '"+timer+"'");
> schedulerSession.deleteTimer(timer);
> }
> } else { // this is the first timer that is not yet due
> isDueDateInPast = false;
> millisTillNextTimerIsDue = timer.getDueDate().getTime() - System.currentTimeMillis();
> }
> }
>
> } finally {
> jbpmContext.close();
> }
> A work-around was suggested in JBPM-594:
> "As workaround now I do remove timer myself in action just before calling signal():
> if(flag) {
> //need to remove scheduler session as it is not removed during event with
> //cancel-timer element
> SchedulerSession schsession = ctx.getJbpmContext().getSchedulerSession();
> Timer timer=(Timer) schsession.findTimersByName("aaa",ctx.getToken()).get(0);
> log.info("found timer:"+timer.getName());
> timer.setRepeat(null);
> timer.setSuspended(true);
> schsession.saveTimer(timer);
>
> ctx.getToken().signal("tonode1");
> }
> "
> However, this does not seem to be thread-safe as the call to findTimersByName sometimes returns a zero-length array and sometimes an exception if the work-around code to cancel the timer executes before the timer is available from the SchedulerSession (and this does happen even when the code to cancel the timer is within the ActionHandler of the timer) As a different work-around, I set the timer repeat to null in the SchedulerSession.deleteTimer method to ensure that it will not be saved again in the SchedulerThread.executeTimers method:
> public void deleteTimer(Timer timer) {
> if (! deletedTimers.contains(timer)) {
> try {
> session.delete(timer);
> deletedTimers.add(timer);
> //MWS 06/04/06 workaround to ensure that timer is deleted
> timer.setRepeat(null);
> } catch (Exception e) {
> log.error(e);
> jbpmSession.handleException();
> throw new JbpmException("couldn't delete timer '"+timer+"' from the database", e);
> }
> }
> }
> However, this causes an occasional exception to be thrown:
> org.jbpm.persistence.JbpmPersistenceException: couldn't commit hibernate session
> at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:171)
> at org.jbpm.svc.Services.close(Services.java:211)
> at org.jbpm.JbpmContext.close(JbpmContext.java:138)
> at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161)
> at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70)
> Caused by: org.hibernate.StaleStateException: Unexpected row count: 0 expected: 1
> at org.hibernate.jdbc.NonBatchingBatcher.addToBatch(NonBatchingBatcher.java:27)
> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2204)
> at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2118)
> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2374)
> at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:84)
> at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:243)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:227)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:141)
> at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296)
> at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:980)
> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:353)
> On further investigation, it appears that on some occasions, when deleting a timer on a cancel-timer event, the call to session.getNamedQuery("SchedulerSession.findTimersByName") causes a hibernate flush to occur which attempts to update a timer that has already been deleted:
> public void cancelTimersByName(String timerName, Token token) {
> try {
> Query query = session.getNamedQuery("SchedulerSession.findTimersByName");
> query.setString("timerName", timerName);
> query.setEntity("token", token);
> Iterator iter = query.list().iterator();
> while(iter.hasNext()) {
> deleteTimer((Timer) iter.next());
> }
>
> } catch (Exception e) {
> log.error(e);
> jbpmSession.handleException();
> throw new JbpmException("couldn't delete timer '"+timerName+"' on '"+token+"' from the database", e);
> }
> }
> I have some screenshots below to illustrate this but cannot include them in this form. The attempt to cancel the timer ?processing_error_task_timer? causes the following query to be issued:
> <query name="SchedulerSession.findTimersByName">
> <![CDATA[
> select t
> from org.jbpm.scheduler.exe.Timer t
> where t.name = :timerName
> and t.token = :token
> ]]>
> </query>
> which in turn causes hibernate to flush and attempt to issue the SQL statement:
> update JBPM_TIMER set NAME_=?, DUEDATE_=?, REPEAT_=?, TRANSITIONNAME_=?, EXCEPTION_=?, ISSUSPENDED_=?, ACTION_=?, TOKEN_=?, PROCESSINSTANCE_=?, TASKINSTANCE_=?, GRAPHELEMENTTYPE_=?, GRAPHELEMENT_=? where ID_=?
> where the ID_ of the timer is that of a previous timer that has already been deleted from the database called ?credit_referral_task_timer? (I confirmed this by inspection of the JBPM_TIMER table).
> I am at a loss to explain how the hibernate cache contains a timer that has already been deleted from the database.
--
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
16 years, 1 month
[JBoss JIRA] Updated: (JBPM-1032) task-assign-events are sometimes fired when group assignment is performed
by Thomas Diesler (JIRA)
[ https://jira.jboss.org/jira/browse/JBPM-1032?page=com.atlassian.jira.plug... ]
Thomas Diesler updated JBPM-1032:
---------------------------------
Fix Version/s: jBPM 3.3.2 GA
Revisit issues that have votes
> task-assign-events are sometimes fired when group assignment is performed
> -------------------------------------------------------------------------
>
> Key: JBPM-1032
> URL: https://jira.jboss.org/jira/browse/JBPM-1032
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.2.1
> Reporter: Karsten Dello
> Fix For: jBPM 3.3.2 GA
>
>
> A "task-assingn"-event is sometimes fired, if only group assignment (setting pooledActors) is performed. This always happens when a swimlane is in use which specifies pooled-actors (junit test 1).
> On the other hand, when the pooled-actors are expressed via an assignment-element as an child element of a task (junit test 2), the event is not fired.
> From my point of view the engine should either:
> a) not fire an task-assign-event in case of group assignments at all
> b) fire it consequently at all group assignments events
> c) fire a different event
> Ronald suggested in the forum thread (link above) to introduce a seperate event "task-group-assign" in case a task gets assigned to a group. In my opinion this would be the best solution to this problem.
> public void testTaskAssignIsFiredWithSwimlaneGroupAssignment() {
> ProcessDefinition processDefinition = ProcessDefinition.parseXmlString(
> "<process-definition name=\"someprocessxyz\">" +
>
> " <event type=\"task-assign\">" +
> " <script>System.out.println(\"task-assign-event fired!\");" +
> " executionContext.setVariable(\"task-assign-event-has-fired\",Boolean.TRUE);</script>"+
> " </event>"+
> " <start-state>" +
> " <transition to='a' />" +
> " </start-state>" +
>
> " <swimlane name='swimlane22'>"+
> " <assignment pooled-actors='jan,nina'/>"+
> " </swimlane>"+
> " <task-node name='a'>" +
> " <task name='sometask' swimlane='swimlane22'/>" +
> " <transition to='end'/>"+
> " </task-node>"+
>
> " <end-state name='end' />" +
>
> "</process-definition>"
> );
> ProcessInstance processInstance = new ProcessInstance(processDefinition);
> Token token = processInstance.getRootToken();
>
> processInstance.signal();
> Object o=processInstance.getContextInstance().getVariable("task-assign-event-has-fired");
> assertEquals(Boolean.TRUE, o);
>
> }
> public void testTaskAssignIsNOTFiredWithSwimlaneGroupAssignment() {
> ProcessDefinition processDefinition = ProcessDefinition.parseXmlString(
> "<process-definition name=\"someprocessxyz\">" +
>
> " <event type=\"task-assign\">" +
> " <script>System.out.println(\"task-assign-event fired!\")"+
> " executionContext.setVariable(\"task-assign-event-has-fired\",Boolean.TRUE);</script>"+
> " </event>"+
> " <start-state>" +
> " <transition to='a' />" +
> " </start-state>" +
>
> " <task-node name='a'>" +
> " <task name='sometask'>" +
> " <assignment pooled-actors='jan,nina'/>"+
> " </task>"+
> " <transition to='end'/>"+
> " </task-node>"+
>
> " <end-state name='end' />" +
>
> "</process-definition>"
> );
> ProcessInstance processInstance = new ProcessInstance(processDefinition);
> Token token = processInstance.getRootToken();
> processInstance.signal();
>
> Object o=processInstance.getContextInstance().getVariable("task-assign-event-has-fired");
> assertEquals(Boolean.TRUE, o);
> }
--
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
16 years, 1 month
[JBoss JIRA] Updated: (JBPM-1067) token.getAvailableTransitions() -- need equivalent that returns ordered list.
by Thomas Diesler (JIRA)
[ https://jira.jboss.org/jira/browse/JBPM-1067?page=com.atlassian.jira.plug... ]
Thomas Diesler updated JBPM-1067:
---------------------------------
Fix Version/s: jBPM 3.3.2 GA
Revisit issues that have votes
> token.getAvailableTransitions() -- need equivalent that returns ordered list.
> -----------------------------------------------------------------------------
>
> Key: JBPM-1067
> URL: https://jira.jboss.org/jira/browse/JBPM-1067
> Project: JBoss jBPM
> Issue Type: Feature Request
> Components: Core Engine
> Affects Versions: jBPM 3.2.2
> Environment: All OS
> Reporter: s b
> Fix For: jBPM 3.3.2 GA
>
>
> This feature request is requesting:
> 1) API which adds a version of token.getAvailableTransitions() which returns an ordered List that preserves the order of the transitions as defined in the processdefinition.xml file for the node, rather than returning an unordered Set object.
> 2) Also request that TaskInstance.getAvailableTransitions() be modified to return an ordered list rather than a randomly ordered list by calling the new method.
> For example:
> ------------------------
> public class TaskInstance extends VariableContainer implements Assignable {
> ...
> public List getAvailableTransitions() {
> List transitions = null;
> if ( (! isLast())
> && (token!=null)
> ) {
> transitions = token.getAvailableTransitionsList(); // using new method
> }
> return transitions;
> }
> ...
> ----------------------------------------
> Problem:
> node.getLeavingTransitions() appears to preserve the order, but the order is apparently lost when the transistions are added to the Set which is returned by token.getAvailableTransitions().
> Preserving the ordering is highly useful when implementing a minimal data-driven interface which presents the user with the transitions to choose from. The designer could exercise some control over the presentation of the choices if only the order were preserved as defined in the processdefinition.xml file.
> Solution:
> Make a clone of "token.getAvailableTransitions()", name it "token.getAvailableTransitionsList()", and add the filtered transitions to a List instead of to a Collection, and return the list. Make sure the order is preserved the same as the transitions were defined in the "processdefinition.xml" file.
> Modify "TaskInstance.getAvailableTransitions()" to call token.getAvailableTransitionsList().
> Summary:
> Although workarounds exist with existing code, it would be very helpful (and consistent I think) to provide an API that retrieves a list of the "available transitions" that is ordered as defined in the processdefinition.xml file instead of an unordered Set or List as is currently available.
--
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
16 years, 1 month