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

Hi Martin,
indeed the array identity doesn't seem to be of any importance.  I
thought it was so since it was the only thing that I changed at the
beginning of the week.  Yesterday my test started producing duplicate
model elements again while they disappeared after writing an
additional test today.  To me this starts to look like complete random
behavior which may be caused by an obscure side-effect of MagicDraw's
HREFs.  Since I have so little clues of the cause of the problem that
occured a couple of times, I have to continue with other components. 
Definitely, I have put a CVS tag on my complete test code and the
input models such that I can create precise diffs when the problem
pops up again.

Sorry that I cannot pinpoint what happened after such a long mail
thread, it's actually quite frustrating for me as well.  Perhaps I'll
come back to this later...

Kind regards and thanks for following up this thread,
Pieter.

On 9/7/05, Martin Matula <[email protected]> wrote:
> 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
> 
>