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

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 =3D
packages.put(((BaseObjectHandler)(pkg.refMetaObject()))._getDelegate().getM=
ofId(),
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 =3D
> > > packages.put(((BaseObjectHandler)pkg.refMetaObject())._getDelegate().=
getMofId(),
> > > pkg);
> > >
> > > This raises:
> > > java.lang.ClassCastException: com.io_software.catools.tas.mof.model.P=
ackageImpl
> > >       at org.netbeans.mdr.NBMDRepositoryImpl.collectPackageInstances(=
NBMDRepositoryImpl.java:752)
> > >       at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDReposit=
oryImpl.java:466)
> > >       at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDReposit=
oryImpl.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 o=
f
> > > 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]''
> >
>