[
http://issues.apache.org/jira/browse/TUSCANY-477?page=comments#action_12418100
]
Frank Budinsky commented on TUSCANY-477:
----------------------------------------
Yang, the adjusted code you show isn't really the "proper" way to do it. The
problem with the original code is that the XSDHelper being used to define the
types (i.e., the one returned from SDOUtil.createXSDHelper) is not the same one
that is being used to find the property (i.e., XSDHelper.INSTANCE). The proper
way to do it is like this:
XSDHelper xsdHelper =
SDOUtil.createXSDHelper(SDOUtil.createTypeHelper());
xsdHelper.define(url.openStream(), null);
Property property = xsdHelper.getGlobalProperty("http://a";, "a", true);
> SDO runtime should report unresolved types in a meaningful way if
> xsd:import/include cannot be resolved
> -------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-477
> URL: http://issues.apache.org/jira/browse/TUSCANY-477
> Project: Tuscany
> Type: Bug
> Components: Java SDO Implementation
> Versions: Java-M1
> Reporter: Raymond Feng
> Assignee: Frank Budinsky
> Attachments: TestXSDImport.jar
>
> I'm seeing different behaviors from XSDHelper.define() if the
> xsd:import/include cannot be resolved. I wonder if we should have a
> consistent error handling here. Please see the attached test case (in the
> case, I pass null as schemaLocation to the define() on purpose).
> Case 1: Unresolved XSD type is silently replaced by Object DataType
> Case 2: IllegalArgumentException is thrown due to a NPE in EMF code
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
