You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Laura Morales <la...@mail.com> on 2017/10/19 14:54:36 UTC
Fuseki+HDT graceful "File not found"
Hi,
I'm following this guide http://www.rdfhdt.org/manual-of-hdt-integration-with-jena/#fuseki to run a Fuseki server on top of HDT files. It works fine, but I have to move my config file around between several instances, and some graphs (HDT files) might not be available on some instances. Right now, if one HDT file is not available, Fuseki blows up with a "File not found" exception and the entire endpoint is unusable because of 1 missing file. Would it be possile, please..., to add a flag to Fuseki to simply ignore any HDT graph that has been defined in the config file, but the corresponding HDT is missing?
Thank you very much!
Re: Fuseki+HDT graceful "File not found"
Posted by Andy Seaborne <an...@apache.org>.
https://github.com/rdfhdt/hdt-java/issues/59
and specifically the question "Can you explain why returning null is
more helpful than an exception?"
Andy
Re: Fuseki+HDT graceful "File not found"
Posted by Laura Morales <la...@mail.com>.
> 2) Config it. Default setting is fail out on a missing/failed source, just as now. But provide an alternative "Expect
> weird data (un)availability" setting. This could be a property on the dataset assembler entity, e.g. ja:failFast or
something.
This would be a good option too. An additional setting "skipBadModels" or something like that, which allows Fuseki to keep working even if there is 1 or more bad graph.
Re: Fuseki+HDT graceful "File not found"
Posted by aj...@apache.org.
Two options that come to mind (maybe neither is good, but maybe one is okay):
1) Logging a missing/failed source at ERROR level. I don't like this much, for the same reasons Rob doesn't like Laura's
first suggestion.
2) Config it. Default setting is fail out on a missing/failed source, just as now. But provide an alternative "Expect
weird data (un)availability" setting. This could be a property on the dataset assembler entity, e.g. ja:failFast or
something.
(2) seems reasonable to me, although I admit I have no use cases and can't think of any that I wouldn't rather solve in
a more deterministic way, for example using some kind of templating action as Andy suggests. One of the cool things
about the assembler tech is that assemblers are RDF: it's sort of homoiconic-ish. Maybe more ish than homoiconic. :)
ajs6f
Rob Vesse wrote on 10/20/17 5:17 AM:
> While that is a simple change it is a breaking change behaviourally. You go from a situation where a user gets an explicit error message that they can do something about to a situation where some aspects of invalid configurations are silently ignored. For complex configurations this may lead to all sorts of subtle and invisible errors which uses could waste far more time trying to track down than if they had just received an error as they do currently.
>
> Rob
>
> On 20/10/2017 07:07, "Laura Morales" <la...@mail.com> wrote:
>
> The problem is here: https://github.com/apache/jena/blob/cc038809fb622779933831011909714e22ef494c/jena-arq/src/main/java/org/apache/jena/sparql/core/assembler/DatasetAssembler.java#L79
>
> This is a for() loop reading all the RDFNode in the configuration file.
> The "gName" variable corresponds to the "namedGraph" setting, and the "g" variable to the "graph" setting. When the execution reaches line #79 Model m = a.openModel(g); this (I guess) calls the "open" method overridden by hdt-java open(). So, if I return null, "Model m" will be null which is probably causing problems with the next line, ds.addNamedModel(gName, m);
> I think this should be the correct behavior instead:
>
>
> Model m = a.openModel(g);
> if (m != null)
> ds.addNamedModel(gName, m);
>
>
> it's just 1 additional line :)
> This way, if the custom assembler returned ModelFactory.createModelForGraph(null) or return ModelFactory.createDefaultModel(), Fuseki will create a new but empty graph in the dataset. If instead the custom assembler open() function returns null, the model is not added at all.
>
> What do you think? I haven't tried this because I don't know how to compile Jena/Fuseki, but I'm confident that it should work. Could somebody who knows how to compile Jena try this?
>
> Thanks!
>
>
>
>
> Subject: Re: Fuseki+HDT graceful "File not found"
> > I've put a check here, in the "open" function:
> >
> > if(!new File(file).isFile())
> > return null;
>
> In the file HDTGraphAssembler.java, adding these lines before the
> try..catch block seems to work, more or less...
>
> if (!new File (file).isFile ())
> return ModelFactory.createModelForGraph
> (null);
>
> I've tried this, and it looks like it creates an empty graph. That is,
> I find the new graph in the dataset, but it's empty, no triples. I
> don't know if or how it's possible to skip the entire graph entirely,
> such that not even an empty graph is added to the dataset.
>
>
>
>
>
>
Re: Fuseki+HDT graceful "File not found"
Posted by aj...@apache.org.
A service is a dataset (which could be on-disk or in-memory) along with some HTTP endpoints that support the protocols
like SPARQL Query, SPARQL Update, Graph Store, etc.
https://jena.apache.org/documentation/fuseki2/fuseki-data-services.html
That page is super-rough and we really need to polish and rewrite it. (Contributions welcome, and remember, to work on
Jena documentation you need nothing other than a browser and a basic knowledge of Markdown.)
ajs6f
Laura Morales wrote on 10/24/17 9:43 PM:
> Yup, I think I get this. What I don't get is what a "service" is?
>
>
>
> Sent: Tuesday, October 24, 2017 at 9:36 PM
> From: "Andy Seaborne" <an...@apache.org>
> To: users@jena.apache.org
> Subject: Re: Fuseki+HDT graceful "File not found"
>
> On 24/10/17 11:57, Laura Morales wrote:
>
>> "each data service is an RDF datasets and a configurable set of endpoints for various operations such as SPARQL query, SPARQL update and file upload" How is this different than a "normal" standalone installation?
>>
>
> It's not - the standalone server looks in run/configurartion/ directory
> and the config.ttl server file.
>
> If you create a dataset (and hence its endpoints) via the UI, that's
> where the persistent configuration goes.
>
> Andy
>
Re: Fuseki+HDT graceful "File not found"
Posted by Laura Morales <la...@mail.com>.
Yup, I think I get this. What I don't get is what a "service" is?
Sent: Tuesday, October 24, 2017 at 9:36 PM
From: "Andy Seaborne" <an...@apache.org>
To: users@jena.apache.org
Subject: Re: Fuseki+HDT graceful "File not found"
On 24/10/17 11:57, Laura Morales wrote:
> "each data service is an RDF datasets and a configurable set of endpoints for various operations such as SPARQL query, SPARQL update and file upload" How is this different than a "normal" standalone installation?
>
It's not - the standalone server looks in run/configurartion/ directory
and the config.ttl server file.
If you create a dataset (and hence its endpoints) via the UI, that's
where the persistent configuration goes.
Andy
Re: Fuseki+HDT graceful "File not found"
Posted by Andy Seaborne <an...@apache.org>.
On 24/10/17 11:57, Laura Morales wrote:
> "each data service is an RDF datasets and a configurable set of endpoints for various operations such as SPARQL query, SPARQL update and file upload" How is this different than a "normal" standalone installation?
>
It's not - the standalone server looks in run/configurartion/ directory
and the config.ttl server file.
If you create a dataset (and hence its endpoints) via the UI, that's
where the persistent configuration goes.
Andy
Re: Fuseki+HDT graceful "File not found"
Posted by Laura Morales <la...@mail.com>.
> The best Fuseki could do is scan for new services in run/services.
Could you please explain briefly what is a Fuseki service? I also don't see any "services" folder under run/. The documentation doesn't have a lot of information either (https://jena.apache.org/documentation/fuseki2/fuseki-data-services.html).
"each data service is an RDF datasets and a configurable set of endpoints for various operations such as SPARQL query, SPARQL update and file upload" How is this different than a "normal" standalone installation?
Re: Fuseki+HDT graceful "File not found"
Posted by Andy Seaborne <an...@apache.org>.
On 23/10/17 18:34, Laura Morales wrote:
>> Which again would be the task of the HDT-Fuseki library, not Jena Fuseki.
>
>
> You mean this one? https://github.com/rdfhdt/hdt-java/tree/master/hdt-fuseki
>
The best Fuseki could do is scan for new services in run/services.
Changes within a service need the implementation of service (here HDT)
to do the work. It would be
hdt:HDTdirectory
not
ja:HDTdirectory
The core Apache Jena Fuseki system does not understand HDT, HDT files or
what it takes to modify a setup. It doesn't for anything although ones
like text datasets have their jars in the Fuseki server and they wire
themselves into Fuseki transparently.
Andy
Re: Fuseki+HDT graceful "File not found"
Posted by Laura Morales <la...@mail.com>.
> Which again would be the task of the HDT-Fuseki library, not Jena Fuseki.
You mean this one? https://github.com/rdfhdt/hdt-java/tree/master/hdt-fuseki
Re: Fuseki+HDT graceful "File not found"
Posted by Lorenz Buehmann <bu...@informatik.uni-leipzig.de>.
On 23.10.2017 10:05, Laura Morales wrote:
>> I'm failing to see how this is workable - surly, you want the entire
> service to not be there if it has some/all data missing?
>
>
> Yes, I'd like the service to still be up and running even if some graphs are missing.
> What I'm trying to do is basically this:
>
> - install fuseki on some remote server
> - create a shared folder somewhere, where my friends and I can upload/remove HDT files on the fly
>
> So, it would be pretty useful and cool if, in the Fuseki config file, I could specify a "HDT directory" property instead of a "HDT graph". Something like this:
>
>
> <#dataset> rdf:type ja:RDFDataset ;
> rdfs:label "Shared Dataset" ;
> ja:HDTdirectory "shared/folder/" .
Which again would be the task of the HDT-Fuseki library, not Jena Fuseki.
Re: Fuseki+HDT graceful "File not found"
Posted by Laura Morales <la...@mail.com>.
> I'm failing to see how this is workable - surly, you want the entire
service to not be there if it has some/all data missing?
Yes, I'd like the service to still be up and running even if some graphs are missing.
What I'm trying to do is basically this:
- install fuseki on some remote server
- create a shared folder somewhere, where my friends and I can upload/remove HDT files on the fly
So, it would be pretty useful and cool if, in the Fuseki config file, I could specify a "HDT directory" property instead of a "HDT graph". Something like this:
<#dataset> rdf:type ja:RDFDataset ;
rdfs:label "Shared Dataset" ;
ja:HDTdirectory "shared/folder/" .
so, instead of specifying all graphs manually, I just tell Fuseki where it can find HDT files. Then, ideally, Fuseki should read a list of HDT files from the directory, and for each file automatically create a new graph. For example, if it finds a file called graph1.hdt, it will create a graph called <graph1> and with source graph1.hdt.
This would be really rally cool, because it means we don't have to worry about the config files, but we can just swap graphs in and out by copying files in the shared folder.
However, since this seemed like a lot of work to add to Fuseki, I was trying to think of a simpler solution... so I thought "I can write a huge config files with a list of 100s graphs, and then Fuseki could just ignore whatever graph is not available at the moment". This is the reason for my first email. However, I still think that an additional property "ja:HDTdirectory" would be awesomely useful if it can make it into Fuseki.
I hope my request is clear? Otherwise ask more questions :)
Sorry for the long email.
Re: Fuseki+HDT graceful "File not found"
Posted by Andy Seaborne <an...@apache.org>.
On 20/10/17 10:34, Laura Morales wrote:
>> While that is a simple change it is a breaking change behaviourally. You go from a situation where a user gets an explicit error message that they can do something about to a situation where some aspects of invalid configurations are silently ignored. For complex configurations this may lead to all sorts of subtle and invisible errors which uses could waste far more time trying to track down than if they had just received an error as they do currently.
>
>
> Or it could show a log message?
>
>
> if (m != null)
> print (m + " not a valid model. Skipping graph " + gName);
>
>
> Then it's the responsibility of HDT (or any other custom assembler) to decide what to do:
>
> - print "file not found" and throw an exception, or
> - return null (that in turn will trigger the "invalid model" message), or
> - return a DefaultModel
>
I'm failing to see how this is workable - surly, you want the entire
service to not be there if it has some/all data missing? I can see lots
of different variations being reasonable in different situations -
hence, don't put policy in Fuseki core.
One option is to use that fact that service configurations can go in
run/configuration, one file per service. No need to put all in config.ttl.
Then switch them in and out depending on the availability of HDT files -
some scripting around launching the Fuseki server.
Andy
Re: Fuseki+HDT graceful "File not found"
Posted by Laura Morales <la...@mail.com>.
> While that is a simple change it is a breaking change behaviourally. You go from a situation where a user gets an explicit error message that they can do something about to a situation where some aspects of invalid configurations are silently ignored. For complex configurations this may lead to all sorts of subtle and invisible errors which uses could waste far more time trying to track down than if they had just received an error as they do currently.
Or it could show a log message?
if (m != null)
print (m + " not a valid model. Skipping graph " + gName);
Then it's the responsibility of HDT (or any other custom assembler) to decide what to do:
- print "file not found" and throw an exception, or
- return null (that in turn will trigger the "invalid model" message), or
- return a DefaultModel
Re: Fuseki+HDT graceful "File not found"
Posted by Rob Vesse <rv...@dotnetrdf.org>.
While that is a simple change it is a breaking change behaviourally. You go from a situation where a user gets an explicit error message that they can do something about to a situation where some aspects of invalid configurations are silently ignored. For complex configurations this may lead to all sorts of subtle and invisible errors which uses could waste far more time trying to track down than if they had just received an error as they do currently.
Rob
On 20/10/2017 07:07, "Laura Morales" <la...@mail.com> wrote:
The problem is here: https://github.com/apache/jena/blob/cc038809fb622779933831011909714e22ef494c/jena-arq/src/main/java/org/apache/jena/sparql/core/assembler/DatasetAssembler.java#L79
This is a for() loop reading all the RDFNode in the configuration file.
The "gName" variable corresponds to the "namedGraph" setting, and the "g" variable to the "graph" setting. When the execution reaches line #79 Model m = a.openModel(g); this (I guess) calls the "open" method overridden by hdt-java open(). So, if I return null, "Model m" will be null which is probably causing problems with the next line, ds.addNamedModel(gName, m);
I think this should be the correct behavior instead:
Model m = a.openModel(g);
if (m != null)
ds.addNamedModel(gName, m);
it's just 1 additional line :)
This way, if the custom assembler returned ModelFactory.createModelForGraph(null) or return ModelFactory.createDefaultModel(), Fuseki will create a new but empty graph in the dataset. If instead the custom assembler open() function returns null, the model is not added at all.
What do you think? I haven't tried this because I don't know how to compile Jena/Fuseki, but I'm confident that it should work. Could somebody who knows how to compile Jena try this?
Thanks!
Subject: Re: Fuseki+HDT graceful "File not found"
> I've put a check here, in the "open" function:
>
> if(!new File(file).isFile())
> return null;
In the file HDTGraphAssembler.java, adding these lines before the
try..catch block seems to work, more or less...
if (!new File (file).isFile ())
return ModelFactory.createModelForGraph
(null);
I've tried this, and it looks like it creates an empty graph. That is,
I find the new graph in the dataset, but it's empty, no triples. I
don't know if or how it's possible to skip the entire graph entirely,
such that not even an empty graph is added to the dataset.
Re: Fuseki+HDT graceful "File not found"
Posted by Laura Morales <la...@mail.com>.
The problem is here: https://github.com/apache/jena/blob/cc038809fb622779933831011909714e22ef494c/jena-arq/src/main/java/org/apache/jena/sparql/core/assembler/DatasetAssembler.java#L79
This is a for() loop reading all the RDFNode in the configuration file.
The "gName" variable corresponds to the "namedGraph" setting, and the "g" variable to the "graph" setting. When the execution reaches line #79 Model m = a.openModel(g); this (I guess) calls the "open" method overridden by hdt-java open(). So, if I return null, "Model m" will be null which is probably causing problems with the next line, ds.addNamedModel(gName, m);
I think this should be the correct behavior instead:
Model m = a.openModel(g);
if (m != null)
ds.addNamedModel(gName, m);
it's just 1 additional line :)
This way, if the custom assembler returned ModelFactory.createModelForGraph(null) or return ModelFactory.createDefaultModel(), Fuseki will create a new but empty graph in the dataset. If instead the custom assembler open() function returns null, the model is not added at all.
What do you think? I haven't tried this because I don't know how to compile Jena/Fuseki, but I'm confident that it should work. Could somebody who knows how to compile Jena try this?
Thanks!
Subject: Re: Fuseki+HDT graceful "File not found"
> I've put a check here, in the "open" function:
>
> if(!new File(file).isFile())
> return null;
In the file HDTGraphAssembler.java, adding these lines before the
try..catch block seems to work, more or less...
if (!new File (file).isFile ())
return ModelFactory.createModelForGraph
(null);
I've tried this, and it looks like it creates an empty graph. That is,
I find the new graph in the dataset, but it's empty, no triples. I
don't know if or how it's possible to skip the entire graph entirely,
such that not even an empty graph is added to the dataset.
Re: Fuseki+HDT graceful "File not found"
Posted by zPlus <zp...@peers.community>.
> I've put a check here, in the "open" function:
>
> if(!new File(file).isFile())
> return null;
In the file HDTGraphAssembler.java, adding these lines before the
try..catch block seems to work, more or less...
if (!new File (file).isFile ())
return ModelFactory.createModelForGraph
(null);
I've tried this, and it looks like it creates an empty graph. That is,
I find the new graph in the dataset, but it's empty, no triples. I
don't know if or how it's possible to skip the entire graph entirely,
such that not even an empty graph is added to the dataset.
Re: Fuseki+HDT graceful "File not found"
Posted by zPlus <zp...@peers.community>.
> I've put a check here, in the "open" function:
>
> if(!new File(file).isFile())
> return null;
In the file HDTGraphAssembler.java, adding these lines before the
try..catch block seems to work, more or less...
if (!new File (file).isFile ())
return ModelFactory.createModelForGraph
(null);
I've tried this, and it looks like it creates an empty graph. That is,
I find the new graph in the dataset, but it's empty, no triples. I
don't know if or how it's possible to skip the entire graph entirely,
such that not even an empty graph is added to the dataset.
Re: Fuseki+HDT graceful "File not found"
Posted by Laura Morales <la...@mail.com>.
> It looks like it is HDT's responsibility - they provide the code to process hdt:fileName
This is the stack trace
-----------------------------------------------------------------
Deprecated: Use org.apache.jena.fuseki.cmd.FusekiCmd
[...]
[2017-10-20 06:10:58] Config INFO Loaded org.rdfhdt.hdtjena.HDTGraphAssembler
java.io.FileNotFoundException: graph.hdt (No such file or directory)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:195)
at java.io.FileInputStream.<init>(FileInputStream.java:138)
at java.io.FileInputStream.<init>(FileInputStream.java:93)
at org.rdfhdt.hdt.hdt.impl.HDTImpl.mapFromHDT(HDTImpl.java:215)
at org.rdfhdt.hdt.hdt.HDTManagerImpl.doMapIndexedHDT(HDTManagerImpl.java:62)
at org.rdfhdt.hdt.hdt.HDTManager.mapIndexedHDT(HDTManager.java:93)
at org.rdfhdt.hdtjena.HDTGraphAssembler.open(HDTGraphAssembler.java:72)
at org.rdfhdt.hdtjena.HDTGraphAssembler.open(HDTGraphAssembler.java:44)
at org.apache.jena.assembler.assemblers.AssemblerGroup$PlainAssemblerGroup.openBySpecificType(AssemblerGroup.java:157)
at org.apache.jena.assembler.assemblers.AssemblerGroup$PlainAssemblerGroup.open(AssemblerGroup.java:144)
at org.apache.jena.assembler.assemblers.AssemblerGroup$ExpandingAssemblerGroup.open(AssemblerGroup.java:93)
at org.apache.jena.assembler.assemblers.AssemblerBase.open(AssemblerBase.java:39)
at org.apache.jena.assembler.assemblers.AssemblerBase.open(AssemblerBase.java:35)
at org.apache.jena.assembler.assemblers.AssemblerGroup.openModel(AssemblerGroup.java:47)
at org.apache.jena.sparql.core.assembler.DatasetAssembler.createDataset(DatasetAssembler.java:79)
at org.apache.jena.sparql.core.assembler.DatasetAssembler.open(DatasetAssembler.java:43)
at org.apache.jena.assembler.assemblers.AssemblerGroup$PlainAssemblerGroup.openBySpecificType(AssemblerGroup.java:157)
at org.apache.jena.assembler.assemblers.AssemblerGroup$PlainAssemblerGroup.open(AssemblerGroup.java:144)
at org.apache.jena.assembler.assemblers.AssemblerGroup$ExpandingAssemblerGroup.open(AssemblerGroup.java:93)
at org.apache.jena.assembler.assemblers.AssemblerBase.open(AssemblerBase.java:39)
at org.apache.jena.assembler.assemblers.AssemblerBase.open(AssemblerBase.java:35)
at org.apache.jena.fuseki.build.FusekiBuilder.getDataset(FusekiBuilder.java:111)
at org.apache.jena.fuseki.build.FusekiBuilder.buildDataService(FusekiBuilder.java:70)
at org.apache.jena.fuseki.build.FusekiBuilder.buildDataAccessPoint(FusekiBuilder.java:61)
at org.apache.jena.fuseki.build.FusekiConfig.servicesAndDatasets(FusekiConfig.java:124)
at org.apache.jena.fuseki.build.FusekiConfig.readServerConfigFile(FusekiConfig.java:65)
at org.apache.jena.fuseki.server.FusekiSystem.processServerConfigFile(FusekiSystem.java:260)
at org.apache.jena.fuseki.server.FusekiSystem.initServerConfiguration(FusekiSystem.java:236)
at org.apache.jena.fuseki.server.FusekiSystem.initializeDataAccessPoints(FusekiSystem.java:206)
at org.apache.jena.fuseki.server.FusekiServerListener.serverInitialization(FusekiServerListener.java:88)
at org.apache.jena.fuseki.server.FusekiServerListener.contextInitialized(FusekiServerListener.java:52)
at org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:890)
at org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:532)
at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:853)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:344)
at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1501)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1463)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:785)
at org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:261)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:131)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:105)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:113)
at org.eclipse.jetty.server.handler.gzip.GzipHandler.doStart(GzipHandler.java:272)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:131)
at org.eclipse.jetty.server.Server.start(Server.java:452)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:105)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:113)
at org.eclipse.jetty.server.Server.doStart(Server.java:419)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.apache.jena.fuseki.jetty.JettyFuseki.start(JettyFuseki.java:139)
at org.apache.jena.fuseki.cmd.FusekiCmd.runFuseki(FusekiCmd.java:367)
at org.apache.jena.fuseki.cmd.FusekiCmd$FusekiCmdInner.exec(FusekiCmd.java:351)
at jena.cmd.CmdMain.mainMethod(CmdMain.java:93)
at jena.cmd.CmdMain.mainRun(CmdMain.java:58)
at jena.cmd.CmdMain.mainRun(CmdMain.java:45)
at org.apache.jena.fuseki.cmd.FusekiCmd$FusekiCmdInner.innerMain(FusekiCmd.java:103)
at org.apache.jena.fuseki.cmd.FusekiCmd.main(FusekiCmd.java:67)
at org.apache.jena.fuseki.FusekiCmd.main(FusekiCmd.java:25)
-----------------------------------------------------------------
I looked into hdt-java source code; it looks like the class https://github.com/rdfhdt/hdt-java/blob/7c05411992cd3f2bd648c698e87054b3ce70d974/hdt-jena/src/main/java/org/rdfhdt/hdtjena/HDTGraphAssembler.java is the entry point, where Fuseki calls HDT classes. The "open" function is overriding https://jena.apache.org/documentation/javadoc/jena/org/apache/jena/assembler/assemblers/AssemblerBase.html#open-org.apache.jena.assembler.Assembler-org.apache.jena.rdf.model.Resource-org.apache.jena.assembler.Mode-
I've put a check here, in the "open" function:
if(!new File(file).isFile())
return null;
but now I get an uncaught NULL exception. Could somebody please give me a hint where/how to handle a "file not found" here? I simply want to ignore a graph if the file doesn't exist, but as far as I understand open() must always return an object?
Re: Fuseki+HDT graceful "File not found"
Posted by Andy Seaborne <an...@apache.org>.
It looks like it is HDT's responsibility - they provide the code to process
hdt:fileName.
Andy
(why not preprocess a template file to produce the instance specific
config.ttl as you move it around?)
On 19 October 2017 at 11:20, Rob Vesse <rv...@dotnetrdf.org> wrote:
> HDT is an external project which Jena itself does not support
>
> As described we can’t tell if the project is with Jena Fuseki or HDT, a
> stack trace and/or log output would be useful here to determine which is
> the case
>
> Rob
>
> On 19/10/2017 15:54, "Laura Morales" <la...@mail.com> wrote:
>
> Hi,
>
> I'm following this guide http://www.rdfhdt.org/manual-
> of-hdt-integration-with-jena/#fuseki to run a Fuseki server on top of HDT
> files. It works fine, but I have to move my config file around between
> several instances, and some graphs (HDT files) might not be available on
> some instances. Right now, if one HDT file is not available, Fuseki blows
> up with a "File not found" exception and the entire endpoint is unusable
> because of 1 missing file. Would it be possile, please..., to add a flag to
> Fuseki to simply ignore any HDT graph that has been defined in the config
> file, but the corresponding HDT is missing?
>
> Thank you very much!
>
>
>
>
>
>
Re: Fuseki+HDT graceful "File not found"
Posted by Rob Vesse <rv...@dotnetrdf.org>.
HDT is an external project which Jena itself does not support
As described we can’t tell if the project is with Jena Fuseki or HDT, a stack trace and/or log output would be useful here to determine which is the case
Rob
On 19/10/2017 15:54, "Laura Morales" <la...@mail.com> wrote:
Hi,
I'm following this guide http://www.rdfhdt.org/manual-of-hdt-integration-with-jena/#fuseki to run a Fuseki server on top of HDT files. It works fine, but I have to move my config file around between several instances, and some graphs (HDT files) might not be available on some instances. Right now, if one HDT file is not available, Fuseki blows up with a "File not found" exception and the entire endpoint is unusable because of 1 missing file. Would it be possile, please..., to add a flag to Fuseki to simply ignore any HDT graph that has been defined in the config file, but the corresponding HDT is missing?
Thank you very much!