Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UUID Issue in Addresses-Recipients Demo Tests #426

Closed
HeikoKlare opened this issue Feb 19, 2021 · 3 comments · Fixed by #432
Closed

UUID Issue in Addresses-Recipients Demo Tests #426

HeikoKlare opened this issue Feb 19, 2021 · 3 comments · Fixed by #432

Comments

@HeikoKlare
Copy link
Contributor

In the Addresses-Recipients tests in tools.vitruv.applications.demo.addressesrecipients.tests, a bunch of warnings occurs because UUIDs for elements with proxy URIs are not found. This behavior seems to occur since #419, in which the change recorders were unified.
To me, this looks like a bug revealed by the changes in #419, but we should figure out the reason and fix it. The warnings especially slow down the build by several minutes due to thousands of warnings being printed.

@jGleitz
Copy link
Contributor

jGleitz commented Feb 22, 2021

These warnings occur only when executing multiple test methods, never when executing only one. This may point to an issue with the test setup.

@jGleitz
Copy link
Contributor

jGleitz commented Feb 22, 2021

The root issue here is the code that is generated by the Mappings Language: Every mapping has an AbstractMappingRuntime, which is a singleton. This seems to be something like a poor man’s intermediate model. However, since it is a singleton, it is not tied to the lifecycle of a VSUM (even though it absolutely should be).

I could reproduce the problem in the debugger: After a test has been executed, theAbstractMappingRuntime#instance (e.g. DeleteAdRootXReRootMappingInstancesRoutine#instance) still references an object from the last test run (which is a proxy by now). It is completely valid that the UUIDGeneratorAndResolverImpl doesn’t find a UUID for this object.

I think that the mappings continue to work because the InternalCorrespondenceModelImpl doesn’t return correspondences for elements without a UUID.

@HeikoKlare
Copy link
Contributor Author

Thank you for the investigation! Taking a look into that project shows that it actually has nothing to do with the current Mappings language implementation :-/
It was used as a development project, in which Mappings were defined by hand to develop the language against. But after the language was implemented, the scenario was not re-implemented with that language but still uses some old development artifacts (such as the AbstractMappingRuntime).

In consequence, the project only serves as a documentation of some design ideas for the Mappings language and how that language could have been implemented (in addition to a really minimalist example case study).
I am not sure whether the project gives us a single benefits and thus whether we should keep the project at all. Adapting a pretty broken implementation (AbstractMappingRuntime) that no one needs anyway does not make that much sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants