Yeah, this looks like a bug. Based on where that exception is thrown, it
does look like it's able to find the file in the jar, but cannot open it
for some reason. Unfortunately, our code to open it looks like this:
try {
uri.toURL.openStream() // This will work.
} catch {
case _: java.io.IOException => Assert.invariantFailed("found
resource but couldn't open")
}
So the comment "This will work" is clearly wrong, and we end up masking
the reason why it failed. That definitely needs to be fixed.
If you bump the log level to LogLevel.Resolver, e.g.:
Daffodil.setLoggingLevel(LogLevel.Resolver);
Then it should output to the console a log starting with "Found on
classpath" followed by the URI that import resolved to. That might help
us figure out why it can't open a stream to the file if something looks off.
- Steve
On 5/9/19 8:04 AM, Christofer Dutz wrote:
> Hi Steve,
>
> well if that's the case, then I am having trouble doing this.
>
> So In this case I have a base schema in "base.jar" and I add a dependency to
> this in "protocol" module.
> If I try to use it I get an error message that daffodil has found something
> but it unable to open it.
>
> [ERROR] getTestsuiteTests[40] Time elapsed: 0.013 s <<< ERROR!
> org.apache.daffodil.exceptions.Abort:
> Invariant broken. Unexpected exception type
> org.apache.daffodil.exceptions.Abort: Invariant broken. found resource but
> couldn't open
> org.apache.daffodil.exceptions.Assert$.abort(Assert.scala:129)
> org.apache.daffodil.exceptions.Assert$.invariantFailed(Assert.scala:175)
> org.apache.daffodil.xml.DFDLCatalogResolver.resolveResource(DaffodilXMLLoader.scala:244)
> org.apache.xerces.util.DOMEntityResolverWrapper.resolveEntity(Unknown Source)
> org.apache.daffodil.exceptions.Assert$.abort(Assert.scala:129)
> org.apache.daffodil.exceptions.Assert$.invariantFailed(Assert.scala:175)
> org.apache.daffodil.dsom.DFDLSchemaFile.$anonfun$iiXMLSchemaDocument$1(DFDLSchemaFile.scala:155)
> org.apache.daffodil.oolag.OOLAG$OOLAGValue.liftedTree1$1(OOLAG.scala:585)
> at
> org.apache.plc4x.protocols.AbstractProtocolTest.lambda$getTestsuiteTests$0(AbstractProtocolTest.java:54)
>
>
> Chris
>
>
>
> Am 09.05.19, 13:25 schrieb "Steve Lawrence" <[email protected]>:
>
> You should be able to import/include files in jars on the classpath
> using the full path inside the jar, i.e. what "jar -jt foo.jar" outputs.
> So if foo.jar was on your classpath and contained the following
>
> $ jar -jt foo.jar
> META-INF/MANIFEST.MF
> com/foo/dfdl/types.dfdl.xsd
>
> Your schema could reference the types.dfdl.xsd file with:
>
> <xs:include schemaLocation="com/foo/dfdl/types.dfdl.xsd" />
>
> You don't need to specify which jar to import from or even that the
> file comes from a jar. Daffodil will just search for that path in all
> jars on the classpath.
>
> - Steve
>
>
> On 5/9/19 6:19 AM, Christofer Dutz wrote:
> > Hi all,
> >
> > after solving my last problem, I am stuck with another one … as I
> mentioned in
> > the other thread I have one DFDL schema, which defines all the simple
> types that
> > will be used by any PLC4X schema.
> >
> > In order to do so, this is located in a dedicated maven module and a
> dedicated jar.
> >
> > Now I added a dependency to that jar an now want to reference this in
> my
> > protocol jar.
> >
> > No matter what I try, DFDL always complains about not being able to
> resolve this.
> >
> > So how can I reference and/or import schemas contained in another jar
> that’s in
> > my classpath?
> >
> > Chris
> >
>
>
>
