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). 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. 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. >>
