Daniel,
I'll check up on your last question, but I don't think multiple
registration of factories is the root of your issue. I am just submitting
an EMF bug report to cover the issue, and I'll put you on the cc list. I'd
be interested to know more about what your metadata looks like, and what
the value of rootElementUri and rootElementName are in the above snippet,
and do they vary? Are you in a position to post the schema that you use to
generate the static SDO classes?
Regards, Kelvin.
On 14/02/2008, Daniel Peter <[EMAIL PROTECTED]> wrote:
>
> Hi Kelvin
>
> Yes, I finally call the XMLHelper.save method, whereas
> the exception occurs during the createDocument method
> call:
>
> HelperContext hc = HelperProvider.getDefaultContext();
> XMLDocument xmldoc =
> hc.getXMLHelper().createDocument(dataObject,
> rootElementURI, rootElementName);
> ....
> hc.getXMLHelper().save(xmldoc, os, options);
>
> The register method of the corresponding factory has
> been invoked before the code sequence above is called
> for a given dataObject.
> But my code currently does not avoid that the register
> method of the same factory is invoked again while the
> sequence above is executed concurrently.
> If this is the cause of the problem, I will enforce
> that the registration is done at most once and
> synchronized.
> When it comes to multiple factories: would it be a
> problem if the register method of another factory
> (same scope) is called at a later point in time, while
> the metadata of the first factory is accessed
> concurrently?
>
> Regards, Daniel.
>
> --- kelvin goodson <[EMAIL PROTECTED]>
> schrieb:
>
>
> > 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.
>
>
>
> Lesen Sie Ihre E-Mails jetzt einfach von unterwegs.
> www.yahoo.de/go
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
