Re: Fuseki context path?

On 14/02/2022 21:31, Andy Seaborne wrote: On 14/02/2022 20:59, aj...@apache.org wrote: I'm afraid that doesn't work because I'm interested in proxying the entire application, not a single dataset. I want to expose the whole UI, admin, SPARQL editor and all. I've tried proxying as you

Re: Fuseki context path?

I can if needed, but it seems like a simple thing for the standalone to do. If it can't be done now I will put in a PR. Adam On Mon, Feb 14, 2022, 4:29 PM Martynas Jusevičius wrote: > Adam, > > Why not use the WAR file then in a servlet container? > > On Mon, 14 Feb 2022 at 21.59, wrote: > >

Re: Fuseki context path?

On 14/02/2022 20:59, aj...@apache.org wrote: I'm afraid that doesn't work because I'm interested in proxying the entire application, not a single dataset. I want to expose the whole UI, admin, SPARQL editor and all. I've tried proxying as you describe using --localhost, but the static

Re: Fuseki context path?

Adam, Why not use the WAR file then in a servlet container? On Mon, 14 Feb 2022 at 21.59, wrote: > I'm afraid that doesn't work because I'm interested in proxying the entire > application, not a single dataset. I want to expose the whole UI, admin, > SPARQL editor and all. > > I've tried

Re: Fuseki context path?

I'm afraid that doesn't work because I'm interested in proxying the entire application, not a single dataset. I want to expose the whole UI, admin, SPARQL editor and all. I've tried proxying as you describe using --localhost, but the static resources and JavaScript that compose the UI don't come

Re: How to resolve a transaction error

Hi Erik, Do you have a small example that reproduces this? (outisde of your docker setup) The SLF4J warning shouldn't happen either. Andy On 14/02/2022 16:56, Erik Bijsterbosch wrote: Hi Lorenz, We base all functionality on docker, so we dockerise every new application we develop

AW: xloader "Can't find gzip program"

Thanks for the details. Good to add to the collective experience. One reason to parse the file to /dev/null before trying to load it. It doesn't look like there is much you can do. Reading the man page for bzip2recover, it's going to loose some data and if that is not aligned to N-triples,

Re: Does Jena need maintainance regarding to disk space?

Yes, it's a good idea. TDB2 in Fuseki has the "compact" operation to do this without stopping the server. It creates a new "Data-/" directory and you can delete lower numbered databases. TDB1 - needs the server stopping for a rebuild. If you can stop updates, stop updates, 9server now

Re: Fuseki context path?

On 14/02/2022 17:30, aj...@apache.org wrote: I'm probably missing something obvious, because I haven't looked at Fuseki in quite some time. I cannot seem to find any way to set the servlet context path for Fuseki in its standalone (non-WAR) incarnation, which I want to do in order to get it

Fuseki context path?

I'm probably missing something obvious, because I haven't looked at Fuseki in quite some time. I cannot seem to find any way to set the servlet context path for Fuseki in its standalone (non-WAR) incarnation, which I want to do in order to get it proxied behind httpd. Is there a setting here, or

Re: How to resolve a transaction error

Hi Lorenz, We base all functionality on docker, so we dockerise every new application we develop locally and want to ship/deploy to a server. Docker limitations could bother us, that's what I keep in mind too, but so far application errors still lead the way in debugging. It could be that the TX

AW: AW: AW: AW: AW: xloader "Can't find gzip program"

The error was in the binary: lbzcat: "/zbw/var/wikidata/2022-02-03/rdf/latest-truthy.nt.bz2": compressed data error: bad block header magic That created non-RDF input: [nbt@e6810f891672 ~]$ bzcat /zbw/var/wikidata/2022-02-03/rdf/latest-truthy.nt.bz2 | sed -n

Re: AW: AW: AW: AW: xloader "Can't find gzip program"

On 14/02/2022 08:01, Neubert, Joachim wrote: Thanks, Andy, the TDB2 assembler fixed it, and all worked well. I've tried to load wikidata-truthy then, but apparently the bzip file was damaged at line 4052914959 - have to try again How annoying. Is it an RDF syntax error or bad binary or

Does Jena need maintainance regarding to disk space?

Hi, we have now 13M triples and space usage of Jena data folder is 88G which seems high. This is not including text index. Should we cleanup/compress/rebuild etc the database regularly in order to keep disk usage lower, or is this normal disk usage? BR

Re: How to resolve a transaction error

Hi On 14.02.22 09:26, Erik Bijsterbosch wrote: Hi, I want to resolve the transaction error I mentioned before in an earlier post/conversation. This question was cluttered too much with context to get noticed, I guess. So here's a new attempt... After starting a (4.4.0 docker) fuseki server

How to resolve a transaction error

Hi, I want to resolve the transaction error I mentioned before in an earlier post/conversation. This question was cluttered too much with context to get noticed, I guess. So here's a new attempt... After starting a (4.4.0 docker) fuseki server or a fuseki geosparql server with inference enabled

AW: AW: AW: AW: xloader "Can't find gzip program"

Thanks, Andy, the TDB2 assembler fixed it, and all worked well. I've tried to load wikidata-truthy then, but apparently the bzip file was damaged at line 4052914959 - have to try again Cheers, Joachim > -Ursprüngliche Nachricht- > Von: Andy Seaborne > Gesendet: Samstag, 12. Februar