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