Andy,
This code is from the jena-core test code base.
getFileName("modelReading/based.n3") returns something like:
jar:file:/home/claude/.m2/repository/org/apache/jena/jena-core/2.10.1/jena-core-2.10.1-tests.jar!/modelReading/based.n3
When the tests are run from the jar (extending
om.hp.hpl.jena.rdf.model.test.AbstractTestPackage to verify that a model is
correct).
perhaps we need something like IRIResolver.resolveURL( String url ) that
would use the registered StreamManager Locator's to determine if a url is
understood and if not convert it as the file version does now.
Otherwise I am not certain how we could implement testSimpleLoadImplictBase
(as posted above) and handle the case where developers are trying to verify
that their model implementation is correct.
Claude
On Fri, Jul 12, 2013 at 4:32 PM, Andy Seaborne <[email protected]> wrote:
> Claude,
>
> IRIResolver.resolveFileURL() works on filenames only and
> "jar:file://[jarPath]![**enclosedFile]" isn't a filename.
>
> But as a filename "jar:file:" is legal, albeit rather wierd (so for that
> matter is "http:" -- try it) and so it looks like "./jar:file:/".
>
> So IRIResolver.resolveFileURL() isn't the right function to call. You
> want the non-existent IRIResolver.resolveJarURL() as access to some
> implementation for jarfiles.
>
> The general IRIResolver.resolveString returns
> "jar:file://[jarPath]![**enclosedFile]"
> because there is no code to handle the "jar:" URI scheme (or that that URI
> is already correct).
>
> The deep change is to add to the jena-iri codebase. Statics on
> IRIResolver only work on the global resolver.
>
> What is the correct absolute URI for
>
>
> "jar:file://[jarPath]![**enclosedFile]"
>
> or rather, what do you want it to be?
>
> Andy
>
>
>
> On 12/07/13 15:58, Claude Warren wrote:
>
>> I am looking at TestModelRead.**testSimpleLoadImplictBase() where the
>> test
>> cases are being read from the jena-core tests jar v 2.10.1.
>>
>> public void testSimpleLoadImplictBase() throws IRIException,
>> FileNotFoundException
>> {
>> final Model mBasedImplicit = createModel();
>> final String fn = IRIResolver
>> .resolveFileURL( getFileName("modelReading/**based.n3"));
>> final Model wanted = createModel().add(ModelHelper.**resource(fn),
>> ModelHelper.property("ja:**predicate"),
>> ModelHelper.resource("ja:**object"));
>> mBasedImplicit.read(fn, "N3");
>> ModelHelper.assertIsoModels(**wanted, mBasedImplicit);
>> }
>>
>>
>> the method getFileName("modelReading/**based.n3") returns a
>> jar:file://[jarPath]![**enclosedFile] url. I have registered a new
>> Locator
>> (LocatorJarURL) using StreamManager.get().**addLocator( new
>> LocatorJarURL()
>> );
>>
>> LocatorJarURL does as you would expect and extracts the stream from the
>> jar.
>>
>> The problem is that the IRIResolver.resolveFileURL() does not recognize
>> the
>> jar: URL and converts it to
>> file://[directory]/jar:file://**[jarPath]![enclosedFile]
>>
>> While I could patch
>> IRIResolver.resolveFileURL() to handle the jar based URL I think this
>> points to a larger problem wherein file locators added to the
>> StreamManager
>> do not add capabilities to the IRIResolver.
>>
>> Is there a recommended way to register file based scheme (like jar) with
>> the IRIResolver? I am more than happy to code it if we have a
>> recommendation.
>>
>> Claude
>>
>>
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
Identity: https://www.identify.nu/[email protected]
LinkedIn: http://www.linkedin.com/in/claudewarren
