| Generating EMF EPackages for all xsd URIs [message #431839] |
Tue, 28 July 2009 00:25  |
Eclipse User |
|
|
|
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 #431889 is a reply to message #431880] |
Tue, 28 July 2009 12:41  |
| Eclipse User |
|
|
|
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 19:10 |
| Eclipse User |
|
|
|
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);
>>>
>
|
|
|
Powered by
FUDForum. Page generated in 0.07366 seconds
Home