Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Generating EMF EPackages for all xsd URIs
Generating EMF EPackages for all xsd URIs [message #431839] Tue, 28 July 2009 04:25 Go to next message
Derek Palma is currently offline Derek PalmaFriend
Messages: 141
Registered: July 2009
Senior Member
Hi,

I am loading xml files with the code shown below. The code was originally
from Binding XML to Java. I have a problem where I am getting inconsistent
results. Specifically I expect the document root to be a DynamicEObjectImpl
if the xsds could be resolved and the EPackages generated. I noticed when
the schema cannot be found I get and XMLTypeDocumentRootImpl. If I simply
prevent resolution of the XSDs I can force this to happen, of course.

My problem is that on a particular machine I am getting an
XMLTypeDocumentRootImpl when I expect a DynamicEObjectImpl and need a way to
troubleshoot this.

I am looking for a way I can determine whether or not the XML Resource was
able to get the schemas and create the EMF model automatically. I presume
the only reason the EMF model is not generated is that the schemas were not
found or could not be parsed. Is this correct? How can the reason
XMLTypeDocumentRootImpl was generated?

Any pointers are appreciated.

Thanks in advance.
Derek





ResourceSet resourceSet = new ResourceSetImpl();

final ExtendedMetaData extendedMetaData = new
BasicExtendedMetaData(resourceSet.getPackageRegistry());

resourceSet.getLoadOptions().put(XMLResource.OPTION_EXTENDED _META_DATA,
extendedMetaData);

resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put

(Resource.Factory.Registry.DEFAULT_EXTENSION,

new GenericXMLResourceFactoryImpl());


// Demand load the resource.

Resource resource = resourceSet.getResource(URI.createFileURI(DATA_FOLDER +
fileName), true);


// Display what was loaded.

//

resource.save(System.out, null);

System.out.println();


System.out.println("Traversing EMF AnyType");


// Get the document root instance from the resource

// and get the root object from that.

// We'll assume that it's an instance of AnyType (which isn't a good general
assumption).

//

EObject documentRoot = (EObject)resource.getContents().get(0);
Re: Generating EMF EPackages for all xsd URIs [message #431880 is a reply to message #431839] Tue, 28 July 2009 15:51 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30692
Registered: July 2009
Senior Member
Derek,

Comments below.


Derek Palma wrote:
> Hi,
>
> I am loading xml files with the code shown below. The code was
> originally from Binding XML to Java. I have a problem where I am
> getting inconsistent results. Specifically I expect the document root
> to be a DynamicEObjectImpl
There's no reason why you should ever rely on a specific EObjectImpl...
> if the xsds could be resolved and the EPackages generated. I noticed
> when the schema cannot be found I get and XMLTypeDocumentRootImpl. If
> I simply prevent resolution of the XSDs I can force this to happen, of
> course.
>
> My problem is that on a particular machine I am getting an
> XMLTypeDocumentRootImpl when I expect a DynamicEObjectImpl and need a
> way to troubleshoot this.
>
> I am looking for a way I can determine whether or not the XML Resource
> was able to get the schemas and create the EMF model automatically. I
> presume the only reason the EMF model is not generated is that the
> schemas were not found or could not be parsed. Is this correct?
Yes.
> How can the reason XMLTypeDocumentRootImpl was generated?
That sounds like the case where the root element's name space isn't
recognized and a demand created feature is used to process it. But as I
said, you should not make assumptions beyond assuming the instance
implements EObject/InternalEObject...
>
> Any pointers are appreciated.
>
> Thanks in advance.
> Derek
>
>
>
>
>
> ResourceSet resourceSet = new ResourceSetImpl();
>
> final ExtendedMetaData extendedMetaData = new
> BasicExtendedMetaData(resourceSet.getPackageRegistry());
>
> resourceSet.getLoadOptions().put(XMLResource.OPTION_EXTENDED _META_DATA,
> extendedMetaData);
>
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put
>
> (Resource.Factory.Registry.DEFAULT_EXTENSION,
>
> new GenericXMLResourceFactoryImpl());
>
>
> // Demand load the resource.
>
> Resource resource =
> resourceSet.getResource(URI.createFileURI(DATA_FOLDER + fileName), true);
>
>
> // Display what was loaded.
>
> //
>
> resource.save(System.out, null);
>
> System.out.println();
>
>
> System.out.println("Traversing EMF AnyType");
>
>
> // Get the document root instance from the resource
>
> // and get the root object from that.
>
> // We'll assume that it's an instance of AnyType (which isn't a good
> general assumption).
>
> //
>
> EObject documentRoot = (EObject)resource.getContents().get(0);
>
Re: Generating EMF EPackages for all xsd URIs [message #431889 is a reply to message #431880] Tue, 28 July 2009 16:41 Go to previous messageGo to next message
Derek Palma is currently offline Derek PalmaFriend
Messages: 141
Registered: July 2009
Senior Member
Ed,

Thanks for your help!

Just to clarify, I don't rely on a specific EObject implementation. I just
take whatever I get back and extract the EPackage from it and move on. I
just happenned to notice in the debugger that different implementations
correlate with different EPackages. Sorry for the confusion. I am just
expecting to find EPackages for the .xsds referenced.

I using the same XML file in both my Ecplise instances so I would not expect
anything in the file to affect the behavior. Could there be a variant across
the different Eclipse instance? One is Ganymede and the other is Galileo
RC2. It seems highly unlikely this functionality would vary.

Maybe I just need to step through the code which makes the decision about
converting the .xsd to and Ecore model. Would you happen to know which area
of the source I should start from?

I have attached the beginning of my test file below.

Derek

<?xml version="1.0" encoding="UTF-8"?>

<domain xsi:schemaLocation="http://www.bea.com/ns/weblogic/90/security

http://www.bea.com/ns/weblogic/90/security.xsd

http://www.bea.com/ns/weblogic/90/security/wls

http://www.bea.com/ns/weblogic/90/security/wls.xsd

http://www.bea.com/ns/weblogic/90/security/xacml

http://www.bea.com/ns/weblogic/90/security/xacml.xsd

http://www.bea.com/ns/weblogic/920/domain

http://www.bea.com/ns/weblogic/920/domain.xsd"
xmlns="http://www.bea.com/ns/weblogic/920/domain"
xmlns:sec="http://www.bea.com/ns/weblogic/90/security"
xmlns:wls="http://www.bea.com/ns/weblogic/90/security/wls"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<name>medrec</name>

"Ed Merks" <Ed.Merks@gmail.com> wrote in message
news:h4n6p6$dhg$1@build.eclipse.org...
> Derek,
>
> Comments below.
>
>
> Derek Palma wrote:
>> Hi,
>>
>> I am loading xml files with the code shown below. The code was originally
>> from Binding XML to Java. I have a problem where I am getting
>> inconsistent results. Specifically I expect the document root to be a
>> DynamicEObjectImpl
> There's no reason why you should ever rely on a specific EObjectImpl...
>> if the xsds could be resolved and the EPackages generated. I noticed when
>> the schema cannot be found I get and XMLTypeDocumentRootImpl. If I simply
>> prevent resolution of the XSDs I can force this to happen, of course.
>>
>> My problem is that on a particular machine I am getting an
>> XMLTypeDocumentRootImpl when I expect a DynamicEObjectImpl and need a way
>> to troubleshoot this.
>>
>> I am looking for a way I can determine whether or not the XML Resource
>> was able to get the schemas and create the EMF model automatically. I
>> presume the only reason the EMF model is not generated is that the
>> schemas were not found or could not be parsed. Is this correct?
> Yes.
>> How can the reason XMLTypeDocumentRootImpl was generated?
> That sounds like the case where the root element's name space isn't
> recognized and a demand created feature is used to process it. But as I
> said, you should not make assumptions beyond assuming the instance
> implements EObject/InternalEObject...
>>
>> Any pointers are appreciated.
>>
>> Thanks in advance.
>> Derek
>>
>>
>>
>>
>>
>> ResourceSet resourceSet = new ResourceSetImpl();
>>
>> final ExtendedMetaData extendedMetaData = new
>> BasicExtendedMetaData(resourceSet.getPackageRegistry());
>>
>> resourceSet.getLoadOptions().put(XMLResource.OPTION_EXTENDED _META_DATA,
>> extendedMetaData);
>>
>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put
>>
>> (Resource.Factory.Registry.DEFAULT_EXTENSION,
>>
>> new GenericXMLResourceFactoryImpl());
>>
>>
>> // Demand load the resource.
>>
>> Resource resource = resourceSet.getResource(URI.createFileURI(DATA_FOLDER
>> + fileName), true);
>>
>>
>> // Display what was loaded.
>>
>> //
>>
>> resource.save(System.out, null);
>>
>> System.out.println();
>>
>>
>> System.out.println("Traversing EMF AnyType");
>>
>>
>> // Get the document root instance from the resource
>>
>> // and get the root object from that.
>>
>> // We'll assume that it's an instance of AnyType (which isn't a good
>> general assumption).
>>
>> //
>>
>> EObject documentRoot = (EObject)resource.getContents().get(0);
>>
Re: Generating EMF EPackages for all xsd URIs [message #431900 is a reply to message #431889] Tue, 28 July 2009 23:10 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30692
Registered: July 2009
Senior Member
Derek,

Maybe try setting a breakpoint in BasicExtendedMetaData.demandPackage
since that will be called in the case that a package is created when no
existing package matches properly.


Derek Palma wrote:
> Ed,
>
> Thanks for your help!
>
> Just to clarify, I don't rely on a specific EObject implementation. I
> just take whatever I get back and extract the EPackage from it and
> move on. I just happenned to notice in the debugger that different
> implementations correlate with different EPackages. Sorry for the
> confusion. I am just expecting to find EPackages for the .xsds
> referenced.
>
> I using the same XML file in both my Ecplise instances so I would not
> expect anything in the file to affect the behavior. Could there be a
> variant across the different Eclipse instance? One is Ganymede and the
> other is Galileo RC2. It seems highly unlikely this functionality
> would vary.
>
> Maybe I just need to step through the code which makes the decision
> about converting the .xsd to and Ecore model. Would you happen to know
> which area of the source I should start from?
>
> I have attached the beginning of my test file below.
>
> Derek
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <domain xsi:schemaLocation="http://www.bea.com/ns/weblogic/90/security
>
> http://www.bea.com/ns/weblogic/90/security.xsd
>
> http://www.bea.com/ns/weblogic/90/security/wls
>
> http://www.bea.com/ns/weblogic/90/security/wls.xsd
>
> http://www.bea.com/ns/weblogic/90/security/xacml
>
> http://www.bea.com/ns/weblogic/90/security/xacml.xsd
>
> http://www.bea.com/ns/weblogic/920/domain
>
> http://www.bea.com/ns/weblogic/920/domain.xsd"
> xmlns="http://www.bea.com/ns/weblogic/920/domain"
> xmlns:sec="http://www.bea.com/ns/weblogic/90/security"
> xmlns:wls="http://www.bea.com/ns/weblogic/90/security/wls"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>
> <name>medrec</name>
>
> "Ed Merks" <Ed.Merks@gmail.com> wrote in message
> news:h4n6p6$dhg$1@build.eclipse.org...
>> Derek,
>>
>> Comments below.
>>
>>
>> Derek Palma wrote:
>>> Hi,
>>>
>>> I am loading xml files with the code shown below. The code was
>>> originally from Binding XML to Java. I have a problem where I am
>>> getting inconsistent results. Specifically I expect the document
>>> root to be a DynamicEObjectImpl
>> There's no reason why you should ever rely on a specific EObjectImpl...
>>> if the xsds could be resolved and the EPackages generated. I noticed
>>> when the schema cannot be found I get and XMLTypeDocumentRootImpl.
>>> If I simply prevent resolution of the XSDs I can force this to
>>> happen, of course.
>>>
>>> My problem is that on a particular machine I am getting an
>>> XMLTypeDocumentRootImpl when I expect a DynamicEObjectImpl and need
>>> a way to troubleshoot this.
>>>
>>> I am looking for a way I can determine whether or not the XML
>>> Resource was able to get the schemas and create the EMF model
>>> automatically. I presume the only reason the EMF model is not
>>> generated is that the schemas were not found or could not be parsed.
>>> Is this correct?
>> Yes.
>>> How can the reason XMLTypeDocumentRootImpl was generated?
>> That sounds like the case where the root element's name space isn't
>> recognized and a demand created feature is used to process it. But
>> as I said, you should not make assumptions beyond assuming the
>> instance implements EObject/InternalEObject...
>>>
>>> Any pointers are appreciated.
>>>
>>> Thanks in advance.
>>> Derek
>>>
>>>
>>>
>>>
>>>
>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>
>>> final ExtendedMetaData extendedMetaData = new
>>> BasicExtendedMetaData(resourceSet.getPackageRegistry());
>>>
>>> resourceSet.getLoadOptions().put(XMLResource.OPTION_EXTENDED _META_DATA,
>>> extendedMetaData);
>>>
>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put
>>>
>>> (Resource.Factory.Registry.DEFAULT_EXTENSION,
>>>
>>> new GenericXMLResourceFactoryImpl());
>>>
>>>
>>> // Demand load the resource.
>>>
>>> Resource resource =
>>> resourceSet.getResource(URI.createFileURI(DATA_FOLDER + fileName),
>>> true);
>>>
>>>
>>> // Display what was loaded.
>>>
>>> //
>>>
>>> resource.save(System.out, null);
>>>
>>> System.out.println();
>>>
>>>
>>> System.out.println("Traversing EMF AnyType");
>>>
>>>
>>> // Get the document root instance from the resource
>>>
>>> // and get the root object from that.
>>>
>>> // We'll assume that it's an instance of AnyType (which isn't a good
>>> general assumption).
>>>
>>> //
>>>
>>> EObject documentRoot = (EObject)resource.getContents().get(0);
>>>
>
Previous Topic:Possible to reference a xml simple type`?
Next Topic:Controlling eSuperTypes URI in XMI Serialization
Goto Forum:
  


Current Time: Sat Dec 14 18:03:34 GMT 2019

Powered by FUDForum. Page generated in 0.02987 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top