Issue generating descriptors for DiscoveryServices Model

[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

When attempting to generate descriptors for the DiscoveryServices model (which you should have access to), we get an exception. This is in the later CX release (not an old maintenance branch). The exception is:

eclipse.buildId=unknown java.version=11.0.18 java.vendor=Red Hat, Inc. BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US Command-line arguments: -os linux -ws gtk -arch x86_64

This is a continuation of log file /home/entds.ngisn.com/4j26151/workspaces/SNA_Opendds/.metadata/.bak_1.log Created Time: 2023-05-08 09:43:38.864

org.apache.log4j Error Mon May 08 10:01:47 EDT 2023 com.zeligsoft.base.zdl.oaw.ZXtendGenerator - Error in Component generator of type com.zeligsoft.base.zdl.oaw.ZXtendGenerator: EvaluationException : class org.eclipse.uml2.uml.internal.impl.ComponentImpl cannot be cast to class org.eclipse.uml2.uml.Property (org.eclipse.uml2.uml.internal.impl.ComponentImpl and org.eclipse.uml2.uml.Property are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @70cf0381) template::mainTransformAxcioma.ext[24178,208] on line 436 'DeploymentPart getPerPortDP(DeploymentPart part,DataSpace dataSpace)'
template::mainTransformAxcioma.ext[23175,31] on line 417 '.getPerPortDP(source,dataSpace)'
template::mainTransformAxcioma.ext[21916,82] on line 401 '.createDDS4CCMConnectorFragmentHelper(source,target,plan,deployment,dataSpace)'
template::mainTransformAxcioma.ext[20716,202] on line 382 'dt.deployed.select(dep|dep.modelElement==compPart).select(part|part.hasAncestor(origConnPart)).createDDS4CCMConnectorFragmentHelper(dt.deployedOn,plan,deployment,dataSpace,compPort,origConn)' template::mainTransformAxcioma.ext[19511,73] on line 367 '.visit(connector,dataSpace,plan,deployment,expansionObject,connector)'
template::mainTransformAxcioma.ext[19227,128] on line 364 'assembly.connector.select(c|c.end.zdlAsConnectorEnd().role.contains(dataSpace)).visit(dataSpace,plan,deployment,dataSpace)'
template::mainTransformAxcioma.ext[19013,72] on line 361 '.visit(dataSpace,plan,deployment,dataSpace.zdlAsProperty().eContainer)'
template::mainTransformAxcioma.ext[3571,44] on line 66 'connectors.createInstances(plan,deployment)'
template::mainTransformDispatcher.ext[1280,33] on line 37 'deployment.mainTransformAxcioma()'
nofile[0,32] on line 1 '.mainTransformDispatcher(element)'

[eposse]

Hi. I only see the .emx file for DiscoveryServices in the cx-reproducers repo. Do you have the Papyrus version?

[emammoser]

Whoops, my bad. I just pushed up our latest Discovery Services example in the cx-reproducers under /bug/445

[eposse]

Hi. When opening the model I get an error with an unresolved package import: pathmap://DISCOVERY_CONNECTORS_LIBRARY/models/CCM_Discovery.uml#_iSq60Zh1EeGMaJIogGfUbQ. This looks like it's your own library. Could you add the library as well?

Thanks

[emammoser]

I am really sorry about that. I forget about your team not having some of our internal model libraries. I have added it to the cx-reproducers folder

[eposse]

Just to give you a quick update. The problem seems related to the fact that there are some ports in the model that are not connected, namely DiscoverServices::customer_A::restaurantServicesRecept (and similarly for customer_B). In fact the same error pops-up when you are in the deployment editor and select any of these ports. The exception comes from the same function which we overhauled when dealing with Issue #428.

I'm trying to understand what should be the behaviour in both cases: when generating descriptors, and when displaying the properties in the deployment editor.

[emammoser]

Thank you for the update. Although it isn't used much now, we have always tried to support the scenario where CORBA4CCM facet/receptacles are allowed to not have matching sides at deployment time. I believe we have other model examples with non-connected facets and receptacles in models that don't have this issue, but it is possible that those ports are marked "local" only, or some other small difference to this scenario.

[eposse]

I understand. It should work even if ports are not connected.

A bit more info that narrows it down: the problem during generation occurs when you have an assembly that has at least one non-connected port and at least one connector. So it's possible that your other examples that work have a non-connected port but no connector in the same assembly.

The exception occurs in the display of the properties of an unconnected port when selecting it from the deployment editor, regardless of whether there are connectors or not. But the reason in both cases is the same.

I'm working on a solution now.

[eposse]

The PR solves the issue. You can get a build to test here.

Let me know if that works for you.

[emammoser]

I was able to test this out on my end. The descriptor generated and I was able to deploy with the generated CDP file. Thank you!

[eposse]

Great! If there are no objections, I'll merge it and close this one.

[emammoser]

Sounds good to me

[eposse]

Closing.

[emammoser]

@eposse Would we be able to get the fix that was made here applied to the 2.3.0 papyrus maintenance branch? From what I can tell from the PR, it looks fairly small and trivial to back port? We have a team that is stuck using the 2.3.0 papyrus release for another 5-8 months and this issue is biting them pretty frequently.

[eposse]

It looks like it may be doable. One thing though is that I’ll be leaving on vacations this Friday and I’ll be back the 20th, and unfortunately I won’t have my laptop with me. So I imagine this should have priority over #443, right? I will try to port it by tomorrow.

[emammoser]

Yes, since this should be a relatively short task, we would want you to prioritize this port over #443. Thank you

[eposse]

Ok, I've ported it. A couple of comments:

1. I forgot to create a separate branch so I pushed it directly to streams/v2.3.0-maintenance.
2. The build succeeds and works as expected. No exceptions in either code generation nor selecting unconnected ports and showing the Properties > CX view in the Deployment Editor.
3. Porting back also includes other changes in the generation that were introduced later, in particular, using qualified names instead of UUIDs for identifiers. I'm not sure yet which other changes from 2.4 and 2.5 might have gone in. That won't be a problem, will it?
4. The version built is 2.3.1. Is that the right one or did we already released a 2.3.1?

As I mentioned, I'm leaving on vacations on Friday, and in fact I will leave a little earlier tomorrow (Thursday), so can you test it on your end and let me know if there are any issues?

Also, I'm not sure how to do the release, as we normally only publish the new ones, not the maintenance ones. Or do you prepare your own internal release from the maintenance branch?

[emammoser]

What exactly did you port back, then? Are you sure that the commit that you pushed includes the UUID identifiers when it otherwise wouldn't have? 2.3.1 is the correct version that we would be building now. We do not need a formal release for this.

[emammoser]

I have verified it on my end though, so I think we are all set on this issue for now.

[eposse]

Thanks.

To answer your previous question, I cherry-picked commit a4dcdb3b8e6db7b2425aa84dfc17ae6213f6247e, which was used to solve this issue originally. That commit was made just before the 2.4.0 release.

I had to resolve a couple of conflicts, but the functionality that replaced UUIDs with qualified names was there. I'm tracking down where exactly it was added, but I think it was that same commit.

[eposse]

I found that the replacement of UUIDs with qualified names was done in commit 083d472156929f245d8c518aaa5a89a24a6e3323, and it was Issue #408 (PR #438). This was the last commit before the 2.3.0 tag, and before commit a4dcdb3b8e6db7b2425aa84dfc17ae6213f6247e (the one solving this issue), so it should have been already in the 2.3.0 release. However, when I tested that release yesterday, it showed UUIDs instead of qualifier names, so I'm not sure what happened there.

[eposse]

I figured out what happened. The change to replace UUIDs with qualified names was included in 2.3.0, but when I tested 2.3.0 yesterday, I did a compare of the DiscoveryServices model descriptors from the cx-reproducers repo, before and after generating descriptors, but the one in the cx-reproducers repo already included descriptors generated with 2.2.0 that still had UUIDs. So I was actually comparing 2.3.0 descriptors against 2.2.0 descriptors. I incorrectly concluded that 2.3.0 was still generating UUIDs instead of qualified names.

So all is good.

[emammoser]

Okay, glad to hear we have that all sorted out. Thank you for the fast turnaround, we appreciate it. Enjoy your vacation!

[eposse]

Great! So can we close this again?

[emammoser]

Yes we can