I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=218937
In the meantime if you can supply the data I requested earlier I think we
may be able to work around this.
Kelvin.
On 14/02/2008, kelvin goodson <[EMAIL PROTECTED]> wrote:
>
>
> 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]
> >
> >
>
