Re: [mdr-users] createExtent(String, RefObject, RefPackage[])

Pieter Van Gorp wrote:

>Hi Martin,
>
>On 9/5/05, Martin Matula <[email protected]> wrote:
>  
>
>>>From the description of the method one would expect that as soon as
>>    
>>
>>>the array includes existing extents they will be shared.
>>>This is not the case.
>>>      
>>>
>>Well, I am even more confused. In the last paragraph of your e-mail you
>>say it is the case, 
>>    
>>
>They are only shared if you pass the *same* array variable.  They are
>not shared if you use different arrays that are identical by value. 
>  
>
I don't believe this. There are no special checks for the array identity 
- just for the array content.

>I'm proposing to add code that checks whether the metapackages
>contained in the array are already loaded or not.
>  
>
>  
>
>>Why do you think this is not the case? 
>>    
>>
>Because it was demonstrated by my code: as described on
>http://mdr.netbeans.org/servlets/ReadMsg?list=users&msgNo=3260 all UML
>model elements were duplicated.
>  
>
To me it seems you have something different in mind when you say 
"shared" than me. By shared I mean that if you call A.getC() you get the 
same extent as if you call B.getC(). Isn't this the case if you pass C 
to both A and B during their creation?
To me it seems your test confirmed that it *is* the case - otherwise the 
elements would not be there twice. I guess they were twice there since 
you first created something in the context of A and then the same thing 
in the context of B, but since C is shared between A and B, the things 
that come to C were created twice.
Also make sure that C in the metamodel is the same for the package A and 
package B. If A clusters a different copy of C in the metamodel than B, 
then of course, the extent instantiated from C referenced by A will only 
be used by an instance of A.

>  
>
>>>Originally, I expected that I could even load a standalone extent and
>>>then pass it to the clustering extent.  As you stated, MDR could
>>>support this but does not do this:
>>>http://mdr.netbeans.org/servlets/ReadMsg?list=users&msgNo=3259
>>>      
>>>
>>You can load a standalone extent and pass it to the clustering extent.
>>    
>>
>My test illustrated that although MDR did not throw an exception when
>passing such a standalone extent, it did *not* fill the clustered UML
>extent with the elements from the already loaded UML extent.
>
When should it fill the clustered UML extent? The createExtent operation 
does not fill anything. It just creates empty extents and possibly 
reuses some clustered extents by pointing the clustering extents to them.

>  The
>clustered UML extent remained empty.  The only fix was to load the UML
>elements in an extent conforming to the UML subpackage of the
>clustering metamodel.  As stated, the next version of my test
>demonstrated the opposite problem: all UML elements were present two
>times.
>  
>
The first problem you describe was not related to the clustering. It was 
related to the fact that you loaded two copies of UML metamodel. Only 
one of the copy was clustered by your tracing model. The extent that you 
passed to the createExtent() method was an instance of another copy.

>  
>
>>What the XMI reader does not do is it does not recognize that an object
>>is already loaded - i.e. if you load the same model 1000x times, it will
>>create 1000 same instances of the same model elements. That is not
>>related to the clustering at all.
>>    
>>
>I'm not reloading the UML model.  It was accessible from a variable
>"appMextent" and I passed it two times with an inline array
>initialization "new RefPackage[]{appMextent}.
>
>  
>
>>You can make it work smarter by writing your own reference resolver.
>>    
>>
>Could you please explain when the XMI reference resolver would be
>called again for the UML extent?
>  
>
When reading the XMI for the tracing model, the XMI reference resolver 
would be called for the hrefs pointing to the UML metamodel XMI - 
instead of loading the UML metamodel again (that's what the default 
reference resolver does), you could return the existing (already loaded) 
UML metamodel elements.
Martin