Missing Name attribute on ownedConnector causes null pointer exception when generating descriptors

[emammoser]

Issue and tracking information

Developer's time Estimated effort to fix (hours):

Developer's Actual time spent on fix (hours)

Issue reporter to provide a detailed description of the issue in the space below

A missing name attribute on an owned connector line (and I'm guessing other types of connector lines as well) causes a series of Java null pointer exceptions when generating descriptors.

In this case, the model validates without any issue but gets the exceptions when generating descriptors.

Best case fix is the above. which is invisible to the end user.

Next best fix is to flag it during validation and provide a means through the GUI to fix the problem.

Note, we are guessing that our model got in the following configuration due to either an automatic or manual model merge mistake. While we agree that the model should probably never be in this state, I think we need to try to increase the robustness of the descriptor generation tool to handle edge cases like this.

Excerpt of exception:

java.lang.NullPointerException EvaluationException : java.lang.NullPointerException codegen::debug.ext[1859,120] on line 62 'String getNameOrId(Object obj)' template::mainTransformAxcioma.ext[22501,22] on line 388 '.getNameOrId(connector)' template::mainTransformAxcioma.ext[23110,126] on line 393 'assembly_impl.connector.select(c|c.end.port.contains(connectedPort)).visit(dataSpace,plan,deployment,compPart,origConn)' template::mainTransformAxcioma.ext[21995,73] on line 383 '.visit(connector,dataSpace,plan,deployment,expansionObject,connector)' template::mainTransformAxcioma.ext[21384,128] on line 379 'assembly.connector.select(c|c.end.zdlAsConnectorEnd().role.contains(dataSpace)).visit(dataSpace,plan,deployment,dataSpace)' template::mainTransformAxcioma.ext[20900,72] on line 375 '.visit(dataSpace,plan,deployment,dataSpace.zdlAsProperty().eContainer)' template::mainTransformAxcioma.ext[4129,44] on line 72 'connectors.createInstances(plan,deployment)' template::mainTransformDispatcher.ext[1280,33] on line 37 'deployment.mainTransformAxcioma()' nofile[0,32] on line 1 '.mainTransformDispatcher(element)'

Excerpt of area in UML file that needed to be fixed:

      <ownedConnector xmi:type="uml:Connector" xmi:id="_mLDR81PxEeqNpdmZFi99Lg">
        <end xmi:type="uml:ConnectorEnd" xmi:id="_mLDR9FPxEeqNpdmZFi99Lg" role="_mLDR8lPxEeqNpdmZFi99Lg"/>
        <end xmi:type="uml:ConnectorEnd" xmi:id="_mLDR9VPxEeqNpdmZFi99Lg" partWithPort="_mLDR8VPxEeqNpdmZFi99Lg" role="_mLDSfVPxEeqNpdmZFi99Lg"/>
      </ownedConnector>
      <ownedConnector xmi:type="uml:Connector" xmi:id="_mLDR9lPxEeqNpdmZFi99Lg" name="">
        <end xmi:type="uml:ConnectorEnd" xmi:id="_mLDR91PxEeqNpdmZFi99Lg" partWithPort="_mLDR8FPxEeqNpdmZFi99Lg" role="_mLDSAlPxEeqNpdmZFi99Lg"/>
        <end xmi:type="uml:ConnectorEnd" xmi:id="_mLDR-FPxEeqNpdmZFi99Lg" role="_mLDR8lPxEeqNpdmZFi99Lg"/>
      </ownedConnector>

To Reproduce: Find any "ownedConnector" lines with xmi:type="uml:Connector" in the BasicPubSub example and simply remove the "name" attribute like the above excerpt. Then, open the model in papyrus and try to generate descriptors.

[eposse]

Hi. I can reproduce it, but only by manually removing the name attribute from the connector, and I'm wondering if you can reproduce it at all from the UI? What kind of workflow leads you to removing attributes like that from a model?

UPDATE: Never mind the last question. I didn't read your last comment about this possibly happening on a merge. That would be a rather strange thing to happen, knowing what I know now about EMF Compare, but it may warrant some investigation.

The code generation fix should be relatively simple, but I'm left wondering how this could have happened in the first place.

[emammoser]

The code generation fix should be relatively simple, but I'm left wondering how this could have happened in the first place.

I share your interest in finding this out too, but unfortunately, we don't have much to go on at the moment. I think we may have to just settle with the easy fix in the code generation and hope that solves the issue going forward.

[eposse]

The v2 build is ready for you to test here.

[emammoser]

I have verified this on v2. Once cherry-picked to v3, you can merge both and close this issue

[emammoser]

Actually, can we also get this change cherrypicked to our 2.5 maintenance stream?

[eposse]

Will do.

[eposse]

Merged on v2, v3 and v2.5 maintenance.