Re: [mdr-users] Clustering the UML for Traceability

I changed the order of the createExtent/getExtent calls and most
exceptions disappeared.  As stated in my other mail, I had to move the
shutdownall calls as well to remove a "missing storage files"
exception with the in-memory implementation (btree impl was already
doing fine).

Best regards,
-- Pieter.

On 7/21/05, Martin Matula <[email protected]> wrote:
> Also, from the maven.log and from the source code I found out there
> might be several problems:
> 1) in initMDR() you first try to call createExtent(), if that fails you
> call getExtent() - from the log I see the create extent fails saying
> that extent with the same name already exists - this means you are
> trying to run the test with existing storages that were created by a
> previous test.
> 2) if you still want to run with existing storage, you should reverse
> the order of createExtent and getExtent operations - first call
> getExtent() to check whether the extent already exists, then call
> createExtent() if getExtent() returned null. This way you will prevent
> the exception and switching MDR to a "fail" state.
> 3) if createExtent() fails, it initiates a rollback (switches the
> transaction into a "fail" state to make sure a rollback is performed
> when the outer transaction is finalized) - however, you just catch the
> exception (do not end the transaction), log it and continue performing
> further operations - this may cause problems - you should finalize the
> transaction and do the other stuff in a separate transaction
> Regards,
> Martin
> 
> Pieter Van Gorp wrote:
> 
> >Hi Martin and others,
> >I've managed to generate the JMI interfaces for a tracing metamodel
> >that clusters the UML metamodel.  I've attached the MOF-XMI (see
> >traceMMmof.xml).
> >
> >I have a test in which I create a trace between two UML attributes.
> >I'm not sure if I'm using the NB/JMI API right when creating the
> >clustering extent: I create a new extent and pass an array of size one
> >in which the UML application model is stored.  When serializing the
> >trace extent to XMI, no problems are reported but the references to
> >the UML attributes are in fact dangling IDREFs instead of HREFs to the
> >original UML-XMI file.
> >
> >Even worse, I get a classcastexception when trying to create a new
> >trace extent to test whether the XMI for the traceability model
> >contains the required information:
> >org.netbeans.api.mdr.CreationFailedException: Cannot instantiate
> >package because of unexpected exception: java.lang.ClassCastException
> >        at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:472)
> >        at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:292)
> >        at be.ac.ua.fots.motmot.prototypes.crossreferences.TestMDR.testReadTraceBetweenUmlAttributes(TestMDR.java:176)
> >
> >I've attached the source of my test and the output of its execution by Maven.
> >
> >I hope I've simply used the API "a little bit" wrong... by the way,
> >I'm setting up some documentation about MOF clustering that I'll
> >publish on my website once I've get this prototype right...
> >
> >Looking forward to hear from you,
> >Pieter Van Gorp.
> >
> >
> >
> 
>