Re: [mdr-users] Clustering extents managed by non-MDR repositories

Martin Matula <[email protected]> Thu, 16 Feb 2006 18:39:35 +0100
Newsgroups gmane.comp.java.netbeans.modules.mdr.user
Message-ID <[email protected]>
I think it will not be that simple. For all relationships between 
objects (not just for clustering) MOFID object is used instead of the 
actual object. MDR is then able to retrieve the object based on a MOFID. 
refMofId() returns String, not MOFID object. You can create a MOFID 
object from a String, however the internals of MDR may rely on some 
lookups of objects by MOFID which will not work if the object is not 
managed by MDR.
In the light of this, I don't know this for sure, but I think the simple 
solution you propose will not work.
Martin

Pieter Van Gorp wrote:
> Hi again, we've digged into the MDR sources a bit deeper and here's
> our current understanding:
> 
> Clustering one extent in the other is possible as soon as MDR can
> retrieve MOF IDs from the clustered elements.  Currently, only
> clustering of extents managed by MDR is possible due to the following
> line:
> Object result =
> packages.put(((BaseObjectHandler)(pkg.refMetaObject()))._getDelegate().getMofId(),
> pkg);
> 
> More specifically, the MOF ID is retrieved through the delegate, which
> is MDR specific.  Would it be sufficient if we added a type-check for
> finding model elements managed by other repositories?  We could check
> whether pkg is an instance of BaseObjectHandler and if it is not we
> could query for MOF IDs by means of refMofId() instead of going over
> the delegate...
> 
> Perhaps there's more to it, but this already seems like a feasible
> plan.  If you would acknowledge that there will not be too much extra
> code to be changed, we could give it a try.  Any changes can be
> integrated into the latest official MDR source later.
> 
> Thanks again,
> Pieter.
> 
> On 2/16/06, Pieter Van Gorp <[email protected]> wrote:
> 
>>Would we open Pandora's box by trying to pass our own implementation
>>of RefPackage that also implements BaseObjectHandler (and wraps the
>>MagicDraw model elements) when creating an extent?
>>
>>This seems feasible when we only have to override a couple of methods
>>(like refMetaObject())... Do you know of other assumptions about
>>RefPackage in this context?
>>
>>Thanks a lot in advance,
>>Pieter
>>
>>On 2/15/06, Martin Matula <[email protected]> wrote:
>>
>>>Hi Pieter,
>>>this is a limitation of MDR.
>>>Martin
>>>
>>>Pieter Van Gorp wrote:
>>>
>>>>Hi all,
>>>>is it possible to cluster extents managed by non-MDR repositories?
>>>>
>>>>More specifically, we're trying to create a cluster of the UML extent
>>>>in MagicDraw 10.  If you look at the interfaces of MagicDraw and MDR,
>>>>everything seems fine.  However, we've just encountered a class cast
>>>>exception on line 752 of NBMDRepositoryImpl, which contains:
>>>>Object result =
>>>>packages.put(((BaseObjectHandler)pkg.refMetaObject())._getDelegate().getMofId(),
>>>>pkg);
>>>>
>>>>This raises:
>>>>java.lang.ClassCastException: com.io_software.catools.tas.mof.model.PackageImpl
>>>>      at org.netbeans.mdr.NBMDRepositoryImpl.collectPackageInstances(NBMDRepositoryImpl.java:752)
>>>>      at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:466)
>>>>      at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:292)
>>>>      at org.segravis.icons.helper.Driver.loadClusteringExtent(Driver.java:196)
>>>>
>>>>Reading the source, it seems like our MDR/MagicDraw integration will
>>>>not work since  the MagicDraw classes do not implement internal MDR
>>>>classes like BaseObjectHandler.  Is this a fundamental limitation of
>>>>MDR or are we overlooking something?
>>>>
>>>>Note that we've passed MagicDraw's repository as the single element of
>>>>the RefPackage array argument to createExtent.  On a type level,
>>>>that's OK but it's at the dynamic type cast that things go wrong...
>>>>
>>>>Thanks in advance,
>>>>--
>>>>Pieter Van Gorp
>>>>       Teaching and Research Assistant
>>>>       FOrmal Techniques in Software engineering (FOTS)
>>>>       University of Antwerp
>>>>       Middelheimlaan 1
>>>>       2020 Antwerpen - Belgium
>>>>       Office: G.304
>>>>       Phone: +32 3 265 38 71
>>>>       Fax: +32 3 265 37 77
>>>>       http://www.fots.ua.ac.be/~pvgorp/research/
>>>>       http://motmot.sourceforge.net/
>>>>
>>>>``A man has to live with himself, and he should see to it that he
>>>>always has good company [Charles Evans Hughes]''
>>>