[
https://issues.apache.org/jira/browse/DAFFODIL-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Lawrence reassigned DAFFODIL-2126:
----------------------------------------
Assignee: Steve Lawrence
> XML Catalog uri should use the same semantics as import/include
> schemaLocation
> -------------------------------------------------------------------------------
>
> Key: DAFFODIL-2126
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2126
> Project: Daffodil
> Issue Type: Bug
> Components: Front End
> Affects Versions: 2.3.0
> Reporter: Steve Lawrence
> Assignee: Steve Lawrence
> Priority: Major
> Fix For: 2.4.0
>
>
> When an import/include namespces resolves to a name in an XML ctalog, we do
> not do any further processing of the URI in the ctalog. We just treat it as a
> URI. For relative paths, that means we'll endup looking relative to the
> current working directory. This should probably use the same semantics as the
> schemaLocation attribute in include/import, allowing it to resolve to jars on
> the classpath and other semantics that uses.
> Additionally, resovleResource in DaffodilXMLLoader.scala has teh following
> code:
> {code:scala}
> case Some(uri) => {
> val resourceAsStream =
> try {
> uri.toURL.openStream() // This will work.
> } catch {
> case e: java.io.IOException => Assert.invariantFailed("found resource
> but couldn't open")
> }
> }
> {code}
> There are plenty of valid reasons for openStream to fail. The most common
> being a URI specific in the XML catalog doesn't exist. By making this an
> assert, it makes it difficult to figure out why the stream failed to open. We
> should instead convert this IOException to an SDE so the user will have some
> idea of what went wrong.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
