Got the load of Ecore models it working again...
Using the SDOFactoryImpl.SDOEcoreFactory to load the Ecore file
does covert all org.eclipse.emf.ecore.* to
org.apache.tuscany.sdo.impl.*
The problem arose as Ecore Datatypes were being created like
<DataTypeImpl proxyURI="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EString"/>
When datatype is retrieved, the proxyURI is resolved and the Tuscany
DataTypeImpl is changed to an EMF EDataTypeImpl.
So after loading I have to post process the models and replace all the
EDataTypes via
TypeHelper.INSTANCE.getType("commonj.sdo","String");
I hate this approach but It'll do till I can have a more "robust"
approach...
e.g. figure out a way to fix all proxies... at load time
Anyway, now that I have this code would/should I create "Helper" like
the XSDHelperImpl ? e.g. EcoreHelper ?
Johan Gielstra wrote:
<div class="moz-text-flowed" style="font-family: -moz-fixed">
Be happy to,
As Tuscany's SDO is still built ontop of EMF's model.
The SDOFactoryImpl.SDOEcoreFactory is doing the brunt of the work.
It already "converts" E* to their SDO counter parts. for example
"EClass" to "commonj.sdo.Class" during the load of the EMF Model.
I dug further since my last email and discovered the problem is
actually the attributes' eTypes are simple types String,Integer, etc
containing an instance of EDataType representing EString, EInteger,..
and should instead be an Instances of commonj.sdo.Type.
So I'll have to see what to enhance to make the Factory convert from
EDataType to Type..
During load time as I am hoping to avoid having to post process the
model..
kelvin goodson wrote:
Hi Johan,
Having looked back at the minimal changes between 1.0 RC2 and the
final release I spotted that you said May 2007, which was the RC2 for
the beta1 release, so if it is these two distros you have been using
then there are a large number of changes between them, see [1]. I'm
not an expert on the details of ecore model formats, but aside from
that, my main worry would be that you have been building a solution by
working inside the Tuscany implementation which is subject to change;
the breaking change you point out being a case in point, I can see
this is an area in which the implementation is likely to change more
in the future too. Clearly you could get round this by building a
converter which uses the EMF APIs to traverse the ecore models and the
SDO API to dynamically build SDO metadata. Is this something you'd be
interested in contributing to Tuscany?
Best Regards, Kelvin.
[1]
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&fixfor=12312521&resolution=1&sorter/field=issuekey&sorter/order=DESC&sorter/field=issuetype&sorter/order=DESC
On 24/09/2007, Johan Gielstra <[EMAIL PROTECTED]> wrote:
Hi All,
I have some ecore models that I want to load directly, rather than
exporting them to a schema and using XSDHelper to load them in.
I have experimented with the Tuscany SDO 1.0rc2 (May 2007 ) to and
loaded + used the model successfully...
The code I was using stopped working in Tuscany SDO 1.0 release
(August
2007). and I made the changes below..
Anyway, I get the model loaded and when I call
somedo.getInstanceProperty("name") it fails and their are no
attributes ?
When I dump somedo.getInstanceProperties() I see only Reference and
no Attributes ?
I am unable to share my models but I can make some sample
models+code if
someone is willing to help ?
//////////////////////////////////////////////////////////
For 1.0 rc2
//////////////////////////////////////////////////////////
public class CreateSDODatagraph {
// TODO this is a hack need to figure out how to properly
initialize
// SDOEcoreFactory...
// thepack is hack something change in the initialization code that
cuased problems...
private static EcorePackage thepack = EcorePackage.eINSTANCE;
static {
EPackage.Registry.INSTANCE.put(EcorePackage.eNS_URI,
new EPackage.Descriptor() {
public EPackage getEPackage() {
return thepack;
}
public EFactory getEFactory() {
return new SDOFactoryImpl.SDOEcoreFactory();
}
});
}
public void loadModel(URI uri) {
Resource r =
datagraph.getResourceSet().getResource(uriConverter.normalize(uri),
true);
EPackage pack = getEPackage(r);
//String prefix = pack.getNsPrefix();
String namespace = pack.getNsURI();
// Do both just in case ...
EPackage.Registry.INSTANCE.put(namespace, pack);
datagraph.getResourceSet().getPackageRegistry().put(namespace,
pack);
pack.setEFactoryInstance(new
DynamicDataObjectImpl.FactoryImpl());
}
............
}
/////////////////////////////////
For 1.0
///////////////////////////////
public void init(){
....
EcorePackage.eINSTANCE.setEFactoryInstance(new
SDOFactoryImpl.SDOEcoreFactory());
....
}
public void loadModel(URI uri) {
// internally the normalized URI is used to resolve
inter-related models
Resource r = datagraph.getResourceSet().getResource(
uriconverter.normalize(uri), true);
EPackage pack = getEPackage(r);
String prefix = pack.getNsPrefix();
String namespace = pack.getNsURI();
// EPackage.Registry.INSTANCE.put(namespace, pack);
HelperContextImpl.getBuiltInModelRegistry().put(namespace,
pack);
pack.setEFactoryInstance(new
DynamicDataObjectImpl.FactoryImpl());
prefix2namespace.put(prefix, namespace);
}
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
</div>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
