You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@seaborne.org> on 2017/05/29 16:18:44 UTC
Fuseki development notes
The recent Fuseki pull requests (JENA-1347:PR#254 and JENA-1350:PR#256)
are to do replacing all use of Fuseki1.
That means:
A/ Replace all testing use with Fuseki2 embedded
B/ have a simple way a Fuseki, with validators, to run with diffeent
static content and no UI.
With the PR's the codebase has no use of Fuskei1 by other modules.
Getting a Fuskei setup for sparql.org is done but not full tested and
not contributed yet (thinking about where to put the code).
Andy
Changes are:
1/ Validator reorg
The validators in Fuseki2 output JSON, expecting the client to run
javascript to format for human presentation. SPARQLer is better if it
is simple, no JS, so the HTML-generating validators from Fuseki1 have
been ported to Fuseki2 and for each there is a servlet to decide whether
it is an HTML or JSON request based on conneg, then call functions to
generate JOSN or HTML
2/ Use embedded Fuseki for testing - it has no on-disk work area and
does not run as a full webapp using web.xml for configuration.
Embedded Fuseki is jetty+servlets and so is much like Fuseki1.
jena-jdbc-driver-remote and -bundle used Fuseki1 and their usage has
been replaced.
3/ General clearing up.
No more use of "ServerCtl" from full Fuseki - use Embeded Fuseki for
testing.
4/ A command line way to use the embedded s-version of Fuseki. This can
then be run as SPARQLer at sparql.org.
What we now have a "basic Fuseki" command-line running of Fuseki without
the on-disk state area, nor Shiro. Maybe useful to people as a
development tool.
I need to integrate with the PR's in progress (it works locally) and
them I'll contribute this, either added to jena-fuseki-embedded or a new
module. It's one class - the command line code that calls the Fuseki
embedded builder - and some shading to build a single runnable jar (no
Shiro jar, no jena-text jar and includes all of jena-cmds).
So we have 3 variants of Fuseki2's: Full, Embedded and Basic.
"Fuseki Full" remains the binary put up on /dist/jena.
Fuseki1 can be removed from /dist/jena.
Structure:
The jena-fuseki2 module structure isn't really the ideal setup now but
is harmless. Might be worth sorting out eventually when the requirements
are clear and also depending on what people thing about having many
modules given that each way to shade or assembly binaries needs a module
to produce an deployable artifact (or some long names with the version
and classifier in them and use <shadedArtifactAttached>).
Re: Fuseki development notes
Posted by Andy Seaborne <an...@apache.org>.
sparql.org is now running a Fuseki2-based server.
Andy
>>> Getting a Fuskei setup for sparql.org is done but not full tested and
>>> not contributed yet (thinking about where to put the code).
Re: Fuseki development notes
Posted by Andy Seaborne <an...@apache.org>.
On 30/05/17 07:16, Osma Suominen wrote:
> Hi Andy,
>
> Just a big +1 for everything you've done here. I confess that I've still
> mostly been using Fuseki1 for various quick jobs, such as setting up a
> temporary SPARQL endpoint for myself and testing out new functionality
> related to jena-text and/or jena-spatial. I do use Fuseki2 on some
> servers, but not all of them.
>
> My general feeling has been that I know how Fuseki1 works and can run it
> from the command line whenever I want without any side effects, whereas
> with Fuseki2 I need to think hard every time I want to use it. Part of
> that is just personal inertia but it seems you are sorting out the
> actual technical issues behind this perception, which is great!
"personal inertia" - same for me. Once there is one way to do something,
there is less reason to change it. Fuseki-full from the command line is
bit odd about restart but it works.
The "basic" server is currently at:
https://github.com/afs/jena-fuseki-basic
while it gets final tiding up. The server jar is classifier "server".
jena-text adds 5M to the shaded jar of 21M.
If the embedded server is running and jena-text in in the project
dependencies, it all works anyway.
Command line args are very similar (no Jetty related ones ATM)
--desc= Assembler description file
--mem Create an in-memory, non-persistent dataset for the
server
--file=FILE Create an in-memory, non-persistent dataset for the
server, initialised with the contents of the file
--loc=DIR Use an existing TDB database (or create if does not
exist)
--port Listen on this port number
--localhost Listen only on the localhost interface
--timeout= Global timeout applied to queries (value in ms)
--update Allow updates
--config= Use a configuration file to determine the services
--gzip=on|off Enable GZip compression (HTTP Accept-Encoding) if
request header set
--base=DIR Directory for static content
Andy
>
> -Osma
>
> Andy Seaborne kirjoitti 29.05.2017 klo 19:18:
>> The recent Fuseki pull requests (JENA-1347:PR#254 and
>> JENA-1350:PR#256) are to do replacing all use of Fuseki1.
>>
>> That means:
>> A/ Replace all testing use with Fuseki2 embedded
>> B/ have a simple way a Fuseki, with validators, to run with diffeent
>> static content and no UI.
>>
>> With the PR's the codebase has no use of Fuskei1 by other modules.
>>
>> Getting a Fuskei setup for sparql.org is done but not full tested and
>> not contributed yet (thinking about where to put the code).
>>
>> Andy
>>
>> Changes are:
>>
>> 1/ Validator reorg
>>
>> The validators in Fuseki2 output JSON, expecting the client to run
>> javascript to format for human presentation. SPARQLer is better if it
>> is simple, no JS, so the HTML-generating validators from Fuseki1 have
>> been ported to Fuseki2 and for each there is a servlet to decide
>> whether it is an HTML or JSON request based on conneg, then call
>> functions to generate JOSN or HTML
>>
>> 2/ Use embedded Fuseki for testing - it has no on-disk work area and
>> does not run as a full webapp using web.xml for configuration.
>>
>> Embedded Fuseki is jetty+servlets and so is much like Fuseki1.
>>
>> jena-jdbc-driver-remote and -bundle used Fuseki1 and their usage has
>> been replaced.
>>
>> 3/ General clearing up.
>>
>> No more use of "ServerCtl" from full Fuseki - use Embeded Fuseki for
>> testing.
>>
>> 4/ A command line way to use the embedded s-version of Fuseki. This
>> can then be run as SPARQLer at sparql.org.
>>
>> What we now have a "basic Fuseki" command-line running of Fuseki
>> without the on-disk state area, nor Shiro. Maybe useful to people as a
>> development tool.
>>
>> I need to integrate with the PR's in progress (it works locally) and
>> them I'll contribute this, either added to jena-fuseki-embedded or a
>> new module. It's one class - the command line code that calls the
>> Fuseki embedded builder - and some shading to build a single runnable
>> jar (no Shiro jar, no jena-text jar and includes all of jena-cmds).
>>
>> So we have 3 variants of Fuseki2's: Full, Embedded and Basic.
>>
>> "Fuseki Full" remains the binary put up on /dist/jena.
>>
>> Fuseki1 can be removed from /dist/jena.
>>
>> Structure:
>>
>> The jena-fuseki2 module structure isn't really the ideal setup now but
>> is harmless. Might be worth sorting out eventually when the
>> requirements are clear and also depending on what people thing about
>> having many modules given that each way to shade or assembly binaries
>> needs a module to produce an deployable artifact (or some long names
>> with the version and classifier in them and use
>> <shadedArtifactAttached>).
>>
>>
>>
>>
>
>
Re: Fuseki development notes
Posted by Osma Suominen <os...@helsinki.fi>.
Hi Andy,
Just a big +1 for everything you've done here. I confess that I've still
mostly been using Fuseki1 for various quick jobs, such as setting up a
temporary SPARQL endpoint for myself and testing out new functionality
related to jena-text and/or jena-spatial. I do use Fuseki2 on some
servers, but not all of them.
My general feeling has been that I know how Fuseki1 works and can run it
from the command line whenever I want without any side effects, whereas
with Fuseki2 I need to think hard every time I want to use it. Part of
that is just personal inertia but it seems you are sorting out the
actual technical issues behind this perception, which is great!
-Osma
Andy Seaborne kirjoitti 29.05.2017 klo 19:18:
> The recent Fuseki pull requests (JENA-1347:PR#254 and JENA-1350:PR#256)
> are to do replacing all use of Fuseki1.
>
> That means:
> A/ Replace all testing use with Fuseki2 embedded
> B/ have a simple way a Fuseki, with validators, to run with diffeent
> static content and no UI.
>
> With the PR's the codebase has no use of Fuskei1 by other modules.
>
> Getting a Fuskei setup for sparql.org is done but not full tested and
> not contributed yet (thinking about where to put the code).
>
> Andy
>
> Changes are:
>
> 1/ Validator reorg
>
> The validators in Fuseki2 output JSON, expecting the client to run
> javascript to format for human presentation. SPARQLer is better if it
> is simple, no JS, so the HTML-generating validators from Fuseki1 have
> been ported to Fuseki2 and for each there is a servlet to decide whether
> it is an HTML or JSON request based on conneg, then call functions to
> generate JOSN or HTML
>
> 2/ Use embedded Fuseki for testing - it has no on-disk work area and
> does not run as a full webapp using web.xml for configuration.
>
> Embedded Fuseki is jetty+servlets and so is much like Fuseki1.
>
> jena-jdbc-driver-remote and -bundle used Fuseki1 and their usage has
> been replaced.
>
> 3/ General clearing up.
>
> No more use of "ServerCtl" from full Fuseki - use Embeded Fuseki for
> testing.
>
> 4/ A command line way to use the embedded s-version of Fuseki. This can
> then be run as SPARQLer at sparql.org.
>
> What we now have a "basic Fuseki" command-line running of Fuseki without
> the on-disk state area, nor Shiro. Maybe useful to people as a
> development tool.
>
> I need to integrate with the PR's in progress (it works locally) and
> them I'll contribute this, either added to jena-fuseki-embedded or a new
> module. It's one class - the command line code that calls the Fuseki
> embedded builder - and some shading to build a single runnable jar (no
> Shiro jar, no jena-text jar and includes all of jena-cmds).
>
> So we have 3 variants of Fuseki2's: Full, Embedded and Basic.
>
> "Fuseki Full" remains the binary put up on /dist/jena.
>
> Fuseki1 can be removed from /dist/jena.
>
> Structure:
>
> The jena-fuseki2 module structure isn't really the ideal setup now but
> is harmless. Might be worth sorting out eventually when the requirements
> are clear and also depending on what people thing about having many
> modules given that each way to shade or assembly binaries needs a module
> to produce an deployable artifact (or some long names with the version
> and classifier in them and use <shadedArtifactAttached>).
>
>
>
>
--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suominen@helsinki.fi
http://www.nationallibrary.fi