Hi Andy, thanks for looking into it. After further investigation; the
C:some.rules only occurs when using an absolute path with windows separators
(see below).I've now updated all our code to indeed use linux separators to get
consistent behavior and this solved theses problems for me. Thanks you very
much.
Regarding the C:some.rules issue; I've updated the github code and it gives the
following outcomes for each commented/uncommented option on lines 9-12
(probably requires windows):
- absolute windows path (line 9):
builder.parseConfigFile("C:\\Users\\nouwtb\\git\\jena-example\\src\\test\\resources\\config.ttl");
- fails, with org.apache.jena.shared.RulesetNotFoundException:
C:some.rules
- relative windows path (line 10):
builder.parseConfigFile("src\\test\\resources\\config.ttl");
- fails, with org.apache.jena.shared.RulesetNotFoundException:
file:///C:/Users/nouwtb/git/jena-example/some.rules
- absolute linux path (line 11):
builder.parseConfigFile("C:/Users/nouwtb/git/jena-example/src/test/resources/config.ttl");
- succeeds, path at RuleSetAssembler.addExternalRules is:
C:/Users/nouwtb/git/jena-example/src/test/resources/some.rules
- relative linux path (line 12):
builder.parseConfigFile("src/test/resources/config.ttl");
- succeeds, path at RuleSetAssembler.addExternalRules is:
file:///C:/Users/nouwtb/git/jena-example/src/test/resources/some.rules
Regards, Barry
-----Original Message-----
From: Andy Seaborne <[email protected]>
Sent: donderdag 30 juli 2020 10:56
To: [email protected]
Subject: Re: load rules file via class loader (as a resource)
On 07/07/2020 12:56, Nouwt, B. (Barry) wrote:
> Hey Andy, thanks for helping out!
>
> I've tried to setup a stripped down version of the behavior here:
> https://github.com/barrynl/jena-example
>
> The idea was to run *JenaPathTest.java* from your IDE (in my case Eclipse)
> and demonstrate the inconsistent behavior, but I cannot reproduce the
> behavior I was describing below.
>
> One of the differences I notice in this example using the debugger (if I set
> a breakpoint in
> org.apache.jena.assembler.assemblers.RuleSetAssembler.addExternalRules(Resource,
> List<Rule>)) is that the object resource of the ja:rulesFrom triple is an
> absolute full path string
> (file:///C:/Users/.../jena-example/src/test/resources/some.rules) to the
> some.rules file, while in our actual application it stays a relative url
> (C:some.rules).
This is the part I can't reproduce nor see in the code where it might become
"C:some.rules". I'm probably looking in the right place but I'm not seeing it.
"C:some.rules" vs "file:///C:/.../some.rules" is a matter of what the base URI
is set to though I don't see why there is no "file:".
> I'll check out if I can find differences between these Java applications that
> might explain it.
>
> ----- intercepted this email before actual sending to give additional
> info where I could reproduce the issue -----
>
> I've probably found the cause of this difference in behavior. Depending on
> the slashes (forward or backward) you use in the path string you pass to
> org.apache.jena.fuseki.main.FusekiServer.Builder.parseConfigFile(String), the
> behavior changes. So:
>
> - if you use backward slashes (either in an absolute or relative path), it
> fails because it resolves the some.rules file relative to the working
> directory root of the jena-example. It does fail differently between absolute
> and relative.
> - if you use forward slashes (either in an absolute or relative path), it
> succeeds and loads the some.rules file relative to the config.ttl location.
>
> This might happen because backward slashes (those that windows uses) trigger
> some obscure code located in java.io.WinNTFileSystem...in an attempt to
> normalize the path.
Within Jena, you can always use forward-slash - i.e. URL style, with or without
URI scheme "file:", "file:///"
Did you find anything else out? because this one is quite strange.
Andy
>
> Regards, Barry
>
> -----Original Message-----
> From: Andy Seaborne <[email protected]>
> Sent: dinsdag 7 juli 2020 12:08
> To: [email protected]
> Subject: Re: load rules file via class loader (as a resource)
>
> Could you provide a stripped down file that illustrates the effect?
> And what does "riot --pretty TTL FILE" show as output.
>
> One last factor - I presume you use
> FusekiServer.create().parseConfigFile(FILE)
>
> URIs should be relative to the config file unless it has a BASE.
>
> On 07/07/2020 07:35, Nouwt, B. (Barry) wrote:
>> Hi Andy, thanks, I'm indeed using Apache Jena Main (i.e. embedded into a
>> Java application).
>>
>> One of our developers uses a Mac with Eclipse and the problem we are
>> experiencing is that we cannot find a value for the ja:rulesFrom that works
>> both from Windows Eclipse and on Mac Eclipse (that's why I want to try
>> classpath, because it might be more consistent between OSs).
>>
>> On Windows it resolves the relative path relative to the working directory
>> of the JVM (so it needs a value like <src/test/resources/some.rules>), while
>> on Mac it seems to resolve it relative to the location of the config.ttl
>> file (so it needs a value like <some.rules>.
>
> If debugging trace is on, it should show the full URI.
>
> If it is relative after reading the config file, then there wasn't a base at
> parse time which I can't understand.
>
>>
>> I am not sure what causes this difference, but one of the things I noticed
>> is that the resource gets translated to <C:some.rules> while I think on a
>> Mac it will not.
>
> C:foo is relative as a file name, to the current directory on the C:
> drive. Jena treats one character URI schemes as Windows drives
> (hopefully! I don't have Windows)
>
> If the attempt to read is <C:some.rules> then again it suggests no base URI.
>
>>
>> Thanks for the pointers to a custom "cp:" LocationMapper...I'll check it
>> out, although I do consider this divergence between the Windows and Mac
>> platform undesirable. Not sure if it's the JVM or Apache Jena code that
>> causes this...though.
>>
>> Kind regards, Barry
>>
>> -----Original Message-----
>> From: Andy Seaborne <[email protected]>
>> Sent: maandag 6 juli 2020 17:08
>> To: [email protected]
>> Subject: Re: load rules file via class loader (as a resource)
>>
>> Hi Barry,
>>
>> Plain <some.rules> is a relative URI so it is going to be resolved in
>> parsing the assembler to file:///.../some.rules before it even looks for the
>> rules.
>>
>> Finding files will include the classpath but it would need a trick to get
>> round the resolution.
>>
>> <cp:some.rules> will ve left alone and the resource looked for should
>> "cp:some.rules"
>>
>> I can't remember which packing of Fuseki you use.
>>
>> If its the Fuseki main, launched from a java app, you can add a Locator to
>> the global StreamManager and control the interpreation of URI so seeing,
>> e.g. <file:///../some.rules> look for "some.rules".
>>
>> It might work with a LocationMapper but if you are taking control of rule
>> file mgt, maybe its better to have a custom locator as LocationMapper has
>> only a fixed few rename policies.
>> On 06/07/2020 13:02, Nouwt, B. (Barry) wrote:
>>> Hi everyone,
>>>
>>> I am starting Apache Jena Fuseki with a Turtle configuration file to set up
>>> our services and dataset. We have a problem with loading the separate
>>> some.rules file from the classpath (or via the classloader) using the
>>> 'ja:rulesFrom' predicate of the reasoner.
>>>
>>> If we set the 'ja:rulesFrom' predicate to '<some.rules>' (it expects a
>>> resource not a literal), the configuration fails to load because it cannot
>>> find this file. If we look a bit deeper (using the Java debugger), we
>>> notice that the 'some.rules' gets transformed to 'C:some.rules' somewhere
>>> internally and it therefore does not look at the classpath, but at the
>>> local file system. Is there a way to reference the 'some.rules' file from
>>> the class path if the Turle configuration file is in the same location of
>>> the JAR? Something like: classloader:some.rules...or just '/some.rules' as
>>> would work with the this.getClass().getResourceAsStream('/some/rules').
>>> I've tried several options, but all fail.
>>>
>>> I did notice this in the documentation, which might be what explains
>>> the behaviour: "A resource name with no URI scheme is assumed to be
>>> a local file name."
>>> (https://jena.apache.org/documentation/io/rdf-input.html#api)
>>
>> That's in the RDFDataMgr etc.
>>
>> "foo" will be looked up as-is, via the Locators of the StreamManger. The
>> global stream a manager includes looking in the classpath for "foo" (no URI
>> resolution).
>>
>> "classpath" counts as "file system".
>>
>> Andy
>>
>>>
>>> Regards, Barry
>>>
>>>
>>> This message may contain information that is not intended for you. If you
>>> are not the addressee or if this message was sent to you by mistake, you
>>> are requested to inform the sender and delete the message. TNO accepts no
>>> liability for the content of this e-mail, for the manner in which you use
>>> it and for damage of any kind resulting from the risks inherent to the
>>> electronic transmission of messages.
>>>
