[
http://issues.apache.org/jira/browse/TUSCANY-477?page=comments#action_12417010
]
Yang ZHONG commented on TUSCANY-477:
------------------------------------
Here're more details why NPE:
a1.xsd has
substitutionGroup="b:b"
since null is passed as schemaLocation on purpose in that particular case,
XSDSchemaImpl#resolveElementDeclaration fails to resolve then delegates to
XSDSchemaImpl(XSDConcreteComponentImpl)#createUnresolvedElementDeclaration
which creates an empty XSDElementDeclaration without typeDefinition.
When SDOXSDEcoreBuilder(XSDEcoreBuilder) builds eCore model for that empty
XSDElementDeclaration,
null typeDefinition causes the NPE.
> 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]
