|
|
| Re: Generating EMF EPackages for all xsd URIs [message #431889 is a reply to message #431880] |
Tue, 28 July 2009 16:41   |
 Derek Palma
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 |
Ed Merks
Messages: 33142
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);
>>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03277 seconds
] 
Search
Help
Register
Login
Home
