[JBoss JIRA] Resolved: (JBPM-1057) unsaved type for VariableInstance
by Thomas Diesler (JIRA)
[ https://jira.jboss.org/jira/browse/JBPM-1057?page=com.atlassian.jira.plug... ]
Thomas Diesler resolved JBPM-1057.
----------------------------------
Fix Version/s: (was: jBPM 3.3.2 GA )
Resolution: Out of Date
Resolve bugs older than a year as "Out of Date"
> unsaved type for VariableInstance
> ----------------------------------
>
> Key: JBPM-1057
> URL: https://jira.jboss.org/jira/browse/JBPM-1057
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.1.3, jBPM 3.1.4, jBPM 3.2.3
> Reporter: renaud chone
> Priority: Minor
>
> When creating a new process with Integer variables, I retrieve the same variables as a Long in a new session. In the database, the converter_ column contains only null values.
> I've identified the problem: there were two instances of IntegerToLongConverter. This is most likely a mistake but it's really hard to find. It would be a good idea to make the converter classes singleton or to use the class instead of the instance as a key in the HashMap of org.jbpm.db.hibernate.Converters.
--
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] Resolved: (JBPM-1056) CompositeCommand misimplementation
by Thomas Diesler (JIRA)
[ https://jira.jboss.org/jira/browse/JBPM-1056?page=com.atlassian.jira.plug... ]
Thomas Diesler resolved JBPM-1056.
----------------------------------
Fix Version/s: (was: jBPM 3.3.2 GA )
Resolution: Out of Date
Resolve bugs older than a year as "Out of Date"
> CompositeCommand misimplementation
> ----------------------------------
>
> Key: JBPM-1056
> URL: https://jira.jboss.org/jira/browse/JBPM-1056
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.1.0, jBPM 3.1.1, jBPM 3.1.2, jBPM 3.1.3, jBPM 3.1.4, jBPM 3.2.0, jBPM 3.2.1, jBPM 3.2.2
> Reporter: Edward Staub
>
> CompositeCommand doesn't copy fields from one command to the next, as I THINK is intended.
> This was reported in
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90146&postdays=0...
> on October 11 2006 at 11:23 AM., along with a proposed fix. But it was never JIRA'd and never fixed.
> Secondarily... AFAIK, there is not one word of documentation (example, test, javadoc, anything) explaining how CompositeCommand is supposed to work.
--
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] Resolved: (JBPM-1039) OutOfMemoryError While using multi h:selectOneRaido in dataform with multy columns
by Thomas Diesler (JIRA)
[ https://jira.jboss.org/jira/browse/JBPM-1039?page=com.atlassian.jira.plug... ]
Thomas Diesler resolved JBPM-1039.
----------------------------------
Fix Version/s: (was: jBPM 3.3.2 GA )
Resolution: Out of Date
Resolve bugs older than a year as "Out of Date"
> OutOfMemoryError While using multi h:selectOneRaido in dataform with multy columns
> ----------------------------------------------------------------------------------
>
> Key: JBPM-1039
> URL: https://jira.jboss.org/jira/browse/JBPM-1039
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Console
> Affects Versions: jBPM 3.2.1
> Environment: jBPM 3.2.1 Tomcat 6.0.14
> Reporter: zhou guangzhao
> Priority: Minor
>
> The following taskform code works in JBPM3.2.GA.
> But when running in JBPM 3.2.1, it causes OutOfMemoryError. By testing, I found that if I change <jbpm:dataform columns="2"> to <jbpm:dataform>, it will work well in both JBPM3.2.GA and JBPM3.2.1.
> Sometimes it maybe works in JBPM3.2.1. But while adding more h:selectOneRadio, I get the error.
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
> <!-- the DOCTYPE means we are required to use html for a root element -->
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:ui="http://java.sun.com/jsf/facelets"
> xmlns:c="http://java.sun.com/jstl/core"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:tf="http://jbpm.org/jsf/tf"
> xmlns:jbpm="http://jbpm.org/jsf">
> <ui:component>
> <jbpm:dataform columns="2">
>
> <f:facet name="header">
> <h:outputText value="#{taskName}"/>
> </f:facet>
>
> <!-- TASKFORM ROWS -->
> <jbpm:datacell>
> <f:facet name="header">
> <h:outputText value="Sex"/>
> </f:facet>
> <h:selectOneRadio id="StudentSex" value="#{var['StudentSex']}">
> <f:selectItem itemLabel="Male" itemValue="Male"/>
> <f:selectItem itemLabel="Female" itemValue="Female"/>
> </h:selectOneRadio>
> </jbpm:datacell>
> <jbpm:datacell>
> <f:facet name="header">
> <h:outputText value="HasAS"/>
> </f:facet>
> <h:selectOneRadio id="HasAS" value="#{var['HasAS']}" >
> <f:selectItem itemLabel="Yes" itemValue="Yes"/>
> <f:selectItem itemLabel="No" itemValue="No"/>
> </h:selectOneRadio>
> </jbpm:datacell>
>
> <jbpm:datacell>
> <f:facet name="header">
> <h:outputText value="Actions"/>
> </f:facet>
> <!-- TASKFORM BUTTONS -->
> <tf:saveButton value="Save"/>
> <tf:cancelButton value="Cancel"/>
> <tf:transitionButton value="Save and Close"/>
> </jbpm:datacell>
>
> </jbpm:dataform>
>
> </ui:component>
> </html>
>
--
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] Resolved: (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 resolved JBPM-1032.
----------------------------------
Fix Version/s: (was: jBPM 3.3.2 GA )
Resolution: Out of Date
Resolve bugs older than a year as "Out of Date"
> 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
>
> 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
17 years, 3 months
[JBoss JIRA] Resolved: (JBPM-627) Cancel timer problem
by Thomas Diesler (JIRA)
[ https://jira.jboss.org/jira/browse/JBPM-627?page=com.atlassian.jira.plugi... ]
Thomas Diesler resolved JBPM-627.
---------------------------------
Fix Version/s: (was: jBPM 3.3.2 GA )
Resolution: Out of Date
Resolve bugs older than a year as "Out of Date"
> 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
> 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
17 years, 3 months
[JBoss JIRA] Resolved: (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 resolved JBPM-1014.
----------------------------------
Fix Version/s: (was: jBPM 3.3.2 GA )
Resolution: Out of Date
Resolve bugs older than a year as "Out of Date"
> 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
>
> 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
17 years, 3 months
[JBoss JIRA] Resolved: (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 resolved JBPM-376.
---------------------------------
Fix Version/s: (was: jBPM 3.3.2 GA )
Resolution: Out of Date
Resolve bugs older than a year as "Out of Date"
> 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
>
> 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
17 years, 3 months