Re: [mdr-users] Re: XML Namespaces and Custom Metamodels

Pieter Van Gorp <[email protected]> Fri, 5 Aug 2005 11:34:29 +0200
Newsgroups gmane.comp.java.netbeans.modules.mdr.user
Message-ID <[email protected]>
Hi Martin, 
thans for your reply.  

The exception was caused by the fact that I used testcase field to
store the main metapackage of the tracing metamodel.  This field was
originally initialized by the initExtents method that was called by
the setUp method.  The field was used both within initExtents itself
and within the 'testReadTraceBetweenUmlAttributesXMI' test.  The bug
was introduced by "cleaning up" the initExtents method: the call to
getMainMP was inlined such that the test's fixture was no longer
properly maintained:
   traceMainMP= getMainMP(traceMMurl, "tracing", xmiReader); // this
call was inlined...
   // initialize tracing extent 
   try {
     traceMextent= (RefPackage) repo.getExtent(traceMextentName);
     if (traceMextent==null) {
       // create new trace extent, but initialize it with existing UML
application extent
       logger.info("Creating new tracing extent with clustered
appMextent ("+new RefPackage[]{appMextent}+")");
       traceMextent= (RefPackage) repo.createExtent(traceMextentName,
traceMainMP, new RefPackage[]{appMextent});
     }
   } catch (Exception e) {
     logger.error("error opening/creating tracing extent: "+e.getMessage());
   }

The side-effect was that within the
'testReadTraceBetweenUmlAttributesXMI' test, there was a call to
createExtent with null passed as the main metapackage with the
reported failure as its result.

Thanks for bringing this to my attention,
-- Pieter.

On 8/5/05, Martin Matula <[email protected]> wrote:
> Hi Pieter,
> your problem has nothing to do with namespaces. If "tracing" would be a
> namespace, you would see "tracing:Node" instead of "tracing.Node" in the
> XMI. According to XMI spec., fully qualified names of elements are used
> in the XML nodes, so it seems that there is a class "Node" in a package
> called "tracing" in your metamodel. If this is the case, then the XMI is
> correct. The problem seems to be in the reading phase - XMI reader is
> trying to find package "tracing" to find class "Node" in it to create an
> instance of it. However it is not able to. This usually happens if you
> pass a wrong extent to the XMI reader - make sure you pass an instance
> of your tracing metamodel to the XMI reader. If you are passing instance
> of some other metamodel that does not contain tracing package, then this
> is the error you will get.
> Martin
> 
> Pieter Van Gorp wrote:
> 
> >Looking at the XMI and the Java code over and over again, I can't find
> >why the Node element cannot be found.  Removing the "tracing." prefix
> >didn't solve the problem.  I wonder how it's possible that MDR was
> >able to write XMI that it cannot read again without throwing
> >exceptions...
> >
> >Any ideas?
> >
> >Kind regards,
> >-- Pieter.
> >
> >On 8/4/05, Pieter Van Gorp <[email protected]> wrote:
> >
> >
> >>I may have been too fast by assuming that the exception was caused by
> >>an XML namespace problem.  In fact, I now believe that the XMI reader
> >>(XML parser) is looking for elements in the default (nameless)
> >>namespace and cannot find elements like "tracing.Node".  I'm not sure
> >>why the parser complains about an unknown "package" instead of an
> >>unknown "element" though...
> >>
> >>Keep in touch,
> >>Pieter.
> >>
> >>On 8/4/05, Pieter Van Gorp <[email protected]> wrote:
> >>
> >>
> >>>Hi all,
> >>>how can I set the XML namespace to be used in the XMI for models
> >>>conforming to my own metamodel?
> >>>
> >>>I've created a metamodel for creating traceability links across UML
> >>>models.  Therefore, my metamodel clusters the UML metamodel (more info
> >>>on http://www.fots.ua.ac.be/motmot/docs/traceability-p3.php).  The
> >>>problem is that when I serialize a traceability model to XMI, only
> >>>"UML" is defined as an XML namespace and "tracing" (which should be
> >>>the namespace for elements in the clustering model) is undefined.
> >>>
> >>>This leads to exceptions when the XMI is read in again.  For example:
> >>>org.netbeans.lib.jmi.util.DebugException: Element name cannot be
> >>>resolved, unknown package: tracing.Node
> >>>        at org.netbeans.lib.jmi.xmi.XmiContext.resolveElementName(XmiContext.java:527)
> >>>        at org.netbeans.lib.jmi.xmi.XmiElement$Content.startSubElement(XmiElement.java:354)
> >>>        at org.netbeans.lib.jmi.xmi.XmiSAXReader.startElement(XmiSAXReader.java:223)
> >>>
> >>>XMI of the erraneous traceability model:
> >>><?xml version = '1.0' encoding = 'ISO-8859-1' ?>
> >>><XMI xmi.version = '1.2' xmlns:UML = 'org.omg.xmi.namespace.UML'
> >>>timestamp = 'Thu Aug 04 15:51:23 CEST 2005'>
> >>>  <XMI.header>
> >>>    <XMI.documentation>
> >>>      <XMI.exporter>Netbeans XMI Writer</XMI.exporter>
> >>>      <XMI.exporterVersion>1.0</XMI.exporterVersion>
> >>>    </XMI.documentation>
> >>>  </XMI.header>
> >>>  <XMI.content>
> >>>    <tracing.Node xmi.id = 'a1' role = 'reference to a1'>
> >>>      <tracing.Node.trace>
> >>>        <tracing.Trace xmi.idref = 'a2'/>
> >>>      </tracing.Node.trace>
> >>>      <tracing.Node.content>
> >>>        <UML:Attribute xmi.idref = 'a3'/>
> >>>      </tracing.Node.content>
> >>>    </tracing.Node>
> >>>    <tracing.Node xmi.id = 'a4' role = 'reference to a2'>
> >>>      <tracing.Node.trace>
> >>>        <tracing.Trace xmi.idref = 'a2'/>
> >>>      </tracing.Node.trace>
> >>>      <tracing.Node.content>
> >>>        <UML:Attribute xmi.idref = 'a5'/>
> >>>      </tracing.Node.content>
> >>>    </tracing.Node>
> >>>    <tracing.Trace xmi.id = 'a2'>
> >>>      <tracing.Trace.node>
> >>>        <tracing.Node xmi.idref = 'a1'/>
> >>>        <tracing.Node xmi.idref = 'a4'/>
> >>>      </tracing.Trace.node>
> >>>    </tracing.Trace>
> >>>  </XMI.content>
> >>></XMI>
> >>>I thought it may be due to a missing tag in the specification of my
> >>>metamodel but couldn't find a solution on the website for the UML
> >>>profile for MOF...
> >>>
> >>>Thanks in advance for your help,
> >>>--
> >>>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/
> >>>
> >>>
> >>>
> 
>