Summary: | o.e.g.tests.runtime.emf.core do not run | ||||||
---|---|---|---|---|---|---|---|
Product: | [Modeling] GMF-Runtime | Reporter: | Christian Damus <give.a.damus> | ||||
Component: | General | Assignee: | Christian Damus <give.a.damus> | ||||
Status: | RESOLVED FIXED | QA Contact: | |||||
Severity: | critical | ||||||
Priority: | P1 | Keywords: | contributed | ||||
Version: | 1.0 | ||||||
Target Milestone: | --- | ||||||
Hardware: | PC | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Christian Damus
2005-10-19 10:50:15 EDT
Created attachment 28456 [details]
Patch to fix test plug-in
The problem in running the tests traces to a ClassCircularityError in
initializing the MListener class. This error is thrown
- when the MetamodelProviderTestCase's inner-class provider is being asked
whether it provides for the Ecore package
- when the MSLAdapterFactoryManager forces initialization of all providers
by asking for the provider for the Ecore package
- when the MSLPlugin (o.e.g.runtime.emf.core) is initializing
- when the o.e.g.tests.runtime.emf.core.AllTests class is initializing
one of its test cases which depends on MListener and is, therefore,
already trying to initialize MListener
The re-entrance into the initialization of the MListener class is the
circularity in question. The simplest fix is just to force the initialization
of the o.e.g.runtime.emf.core plug-in before initializing any of the test
classes.
Just to clarify the remark about "this is not reproducible on Windows": the problem is not actually a platform issue, but a VM-dependent issue. The Sun VM manifests the problem because of an apparently more aggressive class verification strategy, which causes classes to be loaded sooner than in some other VMs such as the IBM runtime. Committed the patch to CVS [GMF Restructure] Bug 319140 : product GMF and component Runtime EMF was the original product and component for this bug |