[
https://issues.apache.org/jira/browse/TUSCANY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471700
]
Fuhwei Lwo commented on TUSCANY-1085:
-------------------------------------
Hi Kelvin,
I know my fix is a little kludge. It's probably because I am either not
familiar with EMF enough or it's an EMF design limitation.
Based on my reading into the code, my understanding is that XSDEcoreBuilder is
designed to build its in-memory model based on XSD but not the combination of
XSD and the registered types in the memory. If you looked at the existing
methods computeEClass and computeEClassifier in the SDOXSDEcoreBuilder, you
would find someone has already tried to expose the registered built-in SDO
model types, e.g. sdoModel.xsd, from the memory. What I did was to extend the
code to expose all the registered types besides the SDO core model types.
Unfortunately, exposing the types in the computeEClass and computeEClassifier
is not enough because the createFeature() will create the feature only based on
the information from the XSD. I have tried to override the
getEffectiveTypeDefinition() to return the correct type for the feature but it
seems tied to the XSD information. That's why I override the createFeature() to
set the correct containment value for the complex type feature if the type
returned by getEffectiveTypeDefinition() is incorrect which is currently the
only problem I am seeing.
I agree the fix should eventually come from EMF but am not sure about the scope
and time frame. That's why I am taking the first shot to get this going. Thanks.
> schemaLocation attribute in the <xsd:import> should be only a hint
> ------------------------------------------------------------------
>
> Key: TUSCANY-1085
> URL: https://issues.apache.org/jira/browse/TUSCANY-1085
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Affects Versions: Java-SDO-Mx
> Reporter: Fuhwei Lwo
> Fix For: Java-SDO-Mx
>
> Attachments: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt,
> patch-1085.1, simple2.xsd, simple2.xsd, SimpleDynamicTestCase.java
>
>
> Currently XSDHelper.define(InputStream inputStream, String schemaLocation)
> uses the second parameter to locate the importing XSD specified by the
> schemaLocation attribute. If the schemaLocation is incorrect, its whole
> namespace cannot be resolved.
> The SDO runtime should be able to look up the registered namespace and type
> even the xsd:import failed. Also, the users should be able to register their
> SDO types with their XSD referencing the sdoModel.xsd but without providing
> sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model.
> I will attach a test case later.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
