can't order the listeners

[dragon1]

open the task properties tab, switch to Listener, then change the Listeners's order, then save the diagram.
after reopen the task Listener tab, the order is not the last change.

[littletaffer]

I also have a similar problem. Is there any solution to this?

[ronald_van_kuij]

edit them in the source?

[littletaffer]

Currently one workaround is to edit the workflow file and move the order in the way is preferred then refreshing the diagram file again.

Editing the source is the issue. Which file exactly? It has to be somewhere before the bpmn.xml file is generated. That's the tough part.

The XML extract below is from the bpmn file. If the reordering has to take effect, the field extension entries have to be changed before it goes to bpmn20.xml.

  <bpmn2rocess id="Diagram2" name="diagram2">
    <documentation id="documentation_process" text="Place documentation for the 'diagram2' process here."/>
  </bpmn2rocess>
  <bpmn2tartEvent id="startevent1" name="Start" outgoing="flow1"/>
  <bpmn2erviceTask id="servicetask1" name="Service Task" incoming="flow1" outgoing="flow2" implementation="my.mimos.workflow.sdl.ListenerX" fieldExtensions="/7 /8 /9 /10 /11 /12 /13 /14 /15 /16" resultVariableName="a"/>
  <bpmn2equenceFlow id="flow1" name="" sourceRef="startevent1" targetRef="servicetask1"/>
  <bpmn2:EndEvent id="endevent1" name="End" incoming="flow2"/>
  <bpmn2equenceFlow id="flow2" name="" sourceRef="servicetask1" targetRef="endevent1"/>
  <bpmn2:FieldExtension fieldname="a" expression="$1"/>
  <bpmn2:FieldExtension fieldname="b" expression="2"/>
  <bpmn2:FieldExtension fieldname="c" expression="3"/>
  <bpmn2:FieldExtension fieldname="d" expression="4"/>
  <bpmn2:FieldExtension fieldname="e" expression="5"/>
  <bpmn2:FieldExtension fieldname="f" expression="6"/>
  <bpmn2:FieldExtension fieldname="g" expression="7"/>
  <bpmn2:FieldExtension fieldname="h " expression="8"/>
  <bpmn2:FieldExtension fieldname="i" expression="9"/>
  <bpmn2:FieldExtension fieldname="j" expression="10"/>
Any idea where could it be?

[ronald_van_kuij]

There only is one file in the newer editors (5.8 adn up I believe, but might be 5.9 and up). So 'generation' does not take place anymore

[littletaffer]

The extract that I've put up there is based on version 5.8.

Correct me if I am wrong, according to the documentation, the values that are in there will not be re-injected again right, even if we try to rearrange the order?

The bulk of code that I've looked through, from BPMN20Marshaller to ServiceTaskExport mostly deal with the generating the bpmn20.xml related files, but never on that workflow file above.

Unless, there's something amiss in one of the codegen files.

[littletaffer]

The extract that I've put up there is based on version 5.8.

Correct me if I am wrong, according to the documentation, the values that are in there will not be re-injected again right, even if we try to rearrange the order?

The bulk of code that I've looked through, from BPMN20Marshaller to ServiceTaskExport mostly deal with the generating the bpmn20.xml related files, but never on that workflow file above.

Unless, there's something amiss in one of the codegen files.

Hi Ronald and Dragon,

There's something that I noticed in FieldExtensionsEditor class file that is related to our problem.


//FieldExtension fieldExtension = fieldExtensionExists(serviceTask, fieldName);
       
/*if(fieldExtension != null) {
   fieldExtension.setExpression(fieldExpression);
} else {
   FieldExtension newFieldExtension = Bpmn2Factory.eINSTANCE.createFieldExtension(); //this line is from v5.8
   newFieldExtension.setFieldname(fieldName);
   newFieldExtension.setExpression(fieldExpression);
   diagram.eResource().getContents().add(newFieldExtension);
   serviceTask.getFieldExtensions().add(newFieldExtension);
}*/


If there is an existing FieldExtension object, that object surely would have been indexed, which is likely the reason why that object can be moved up or down, except at the initial stage as it has yet to be instantiated.

To address the problem, the solution would be not to do fieldExtensionExists check function and add another function just before the loop that will clear off the existing list. I know this would solve the problem, however I would like to find out from Tijs, Tom or others whether that thing above was deliberately put in as well as the logic behind it

[trademak]

Hi,

I reproduced this issue in the latest version of the Designer.
Would it be enough for you if I fix the issue in the 5.9.x version of the Designer?
The 5.8.x version is not under active development anymore and I see no reason to not upgrade to 5.9.x.
Please let me know your thoughts / experiences on this.

Thanks,

[littletaffer]

Hi Tijs,

The sooner if the fix is committed into the trunk version in the Codehaus SVN, the better.

I've just experimented by replacing that portion with my own small changes and adding a remove list function. Works nicely though.

Anyway, maybe there is an explaination or reason behind having in the first place of that if/else condition, that I would really like to find out.

Thanks.

[trademak]

Hi,

I committed a fix to trunk, can you please try it to see if it solves your issue?

Thanks,