[
https://issues.apache.org/jira/browse/DAFFODIL-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16836559#comment-16836559
]
Michael Beckerle commented on DAFFODIL-2126:
--------------------------------------------
Actually, I view XML Catalogs as an alternative to classpath/jar organization.
That said, when an XML Catalog contains a relative URL, that needs
interpretation somehow, and current directory isn't the right choice most
likely. I think either some environmental root specified with an env var, or
the classpath thing.
What I also don't know is whether once things are being looked up by the
catalog part of the catalog resolver, does it recursively call back to us to
resolve those URIs, or does it do its own thing? Easy to check, but the catalog
aspects of the DaffodilCatalogResolver (which actually does both regular
classpath and catalog based resolving) are black box to us.
> 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
> 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)
