Daniel,
yes, this looks like a concurrency issue to me. The null pointer
exception is occurring because the demand create metadata package doesn't
have a document root. Here's the EMF code that creates a demand created
package in EMF 2.2.3 ...
EPackage ePackage = demandRegistry.getEPackage(namespace);
if (ePackage == null)
{
ePackage = EcoreFactory.eINSTANCE.createEPackage();
ePackage.setNsURI(namespace);
setQualified(ePackage, namespace != null);
if (namespace != null)
{
ePackage.setNsPrefix
(namespace.equals(ExtendedMetaData.XMLNS_URI) ?
namespace.equals(ExtendedMetaData.XML_URI) ?
"xml" :
"xmlns" :
computePrefix(namespace));
}
demandRegistry.put(namespace, ePackage);
// demandDocumentRoot(ePackage);
EClass documentRootEClass = EcoreFactory.eINSTANCE.createEClass();
documentRootEClass.getESuperTypes().add(
XMLTypePackage.eINSTANCE.getXMLTypeDocumentRoot());
documentRootEClass.setName("DocumentRoot");
ePackage.getEClassifiers().add(documentRootEClass);
setDocumentRoot(documentRootEClass);
}
note that the new package is put into the demand registry before the
document root class for that package is created. Hence there's an
opportunity for another thread to get hold of the demand created package
before it has a document root class.
One thing you may be able to do is to avoid demand creating metadata by
explicitly creating that metadata in the first place. Maybe you could
describe what is happening from your application logic point of view. I
could take a guess that you are doing an XMLHelper.save with string
arguments that give a namespace uri and an element name for the root element
of the XML document, and these two data don't relate to existing metadata.
If this is a single pairing of ns/uri and element name, or a small known
set, then preparing static metadata for the global elements would avoid
this issue.
I haven't yet looked to see if this has been raised as an EMF issue, or
fixed in a later version of EMF. I'll take a look later.
Kelvin.
On 13/02/2008, Daniel Peter <[EMAIL PROTECTED]> wrote:
>
> I got the following exception:
> java.lang.NullPointerException
> at org.eclipse.emf.ecore.util.BasicExtendedMetaData.getAllElements(
> BasicExtendedMetaData.java:845)
> at org.eclipse.emf.ecore.util.BasicExtendedMetaData.getLocalElement(
> BasicExtendedMetaData.java:745)
> at org.eclipse.emf.ecore.util.BasicExtendedMetaData.demandFeature(
> BasicExtendedMetaData.java:1938)
> at org.eclipse.emf.ecore.util.BasicExtendedMetaData.demandFeature(
> BasicExtendedMetaData.java:1929)
> at org.apache.tuscany.sdo.helper.XMLDocumentImpl.<init>(
> XMLDocumentImpl.java:149)
> at org.apache.tuscany.sdo.helper.XMLHelperImpl.createDocument(
> XMLHelperImpl.java:185)
> ...
>
> I suppose it is a multi-threading issue related to emf ecore metadata.
>
> Some background information about how I currently use SDO:
> I use static SDO with several factories, while some factories reference
> other factories. (E.g. FactoryA and FactoryB both reference FactoryC.)
> I use the same scope, HelperProvider.getDefaultContext(), for all factory
> register method calls.
> The register methods of FactoryA and FactoryB are called at different
> moments (lazy).
> The metadata does NOT change at runtime.
> I currently do not avoid that the the register method is invoked more than
> once per factory and scope.
>
> I understand that "emf ecore metadata is intended to be thread-safe for
> read-only access".
> What does this mean regarding factory initialization?
> What kind of factory initialization strategy or synchronization is needed
> in own application code? E.g.:
> - Assure that access to register method of one specific factory is
> synchronized.
> - Assure that register method is called at most once per factory and
> scope.
> - Assure that all factories are initialized before any metadata
> read-access per scope?
> …
>
> Regards, Daniel.
>
>
> ---------------------------------
> Beginnen Sie den Tag mit den neuesten Nachrichten. Machen Sie Yahoo! zu
> Ihrer Startseite!
