-
assigned issue to
Structural weaver merges class and implementation class by name for extends
The following can be reproduced using Association based on commit 3720a76.
- Create an aspect
- Create class A and B
- Create association A ---> B (with 1..* multiplicity)
- Select HashMap and then select a Key (e.g.,
String
) - Weave
The result will contain HashMap
and Collection<B>
. However, this collection (java.util.Collection
) contains methods that are from KeyIndexed.Collection
.
I.e., KeyIndexed contains the implementation class java.util.Collection
and maps Association.Collection
to KeyIndexed.Collection
.
Because of the equal names it seems that Collection
is also merged into java.util.Collection
. In fact, the PreProcessor
in processExtends()
only checks the name. Instead, it should check the instanceClassName
for implementation classes and also never do it (based on name equality) from Class
to ImplementationClass
.
Comments (4)
-
reporter -
reporter Also, in
PostProcessor
, duplicates are detected and merged. Here, if the two classes that are compared are notImplementationClasses
, a simple name check is performed. This leads to the case thatObject
(implementation class) andObject
(class) are considered the same. -
reporter - changed status to resolved
Resolves
#365: Changes Pre and Post processor to use utility method for classfier comparison.Instead of defining/implementing the equality check for classifiers in the weaver, the already existent utility method from RAMModelUtil is used. This method already takes care of properly distinguishing between ImplementationClass and Class.
→ <<cset f24579a92d01>>
-
reporter Models: Updates Association models to reflect changes to weaver.
The Object class is now concern partial, but needs to be redeclared in each lower-level model which doesn't map it to somethin concrete.
References
#365.→ <<cset 61ce12f45660>>
- Log in to comment