A collection of thoughts and discussion points about Fuseki.
== Jena 4.4.0
There is a vue-based rewrite of the UI thanks to Bruno (yea!). The new
UI is in the codebase and the LICENSE and NOTICE files updated. There
are no blockers for releasing this in 4.4.0 release. Prior to the
kerfuffle over security, the hope was an earlier-then-usual 4.4.0
because the UI only just missed 4.3.x.
== javax-jakarta transition
jakarta is JavaEE at the Eclipse Foundation).
At some time, there will need to be transition from javax.* to jakarta.*
for the package imports of javax.* that relate to Java EE.
For Fuseki that is mainly for javax.servlet but also an implication for
the WAR file.
For the Fuseki code itself, there isn't much impact, just a rename.
Partially this is because Fuseki does not use JavaEE features. For
example, request dispatch is not done with web.xml (Fuseki dispatch is
dynamic, not a static setup). FusekiMain does not use web.xml at all.
Jetty version 11 is the same as Jetty version 10 except that "javax" ->
"jakarta" renaming. A big bang switch over but it should be mechanical
translation.
There are two dependencies that use javax.servlet -- commons-fileupload
and shiro.
commons-fileupload code does not update very often (last version was
2018). It is small and Fuseki only uses a small part of it so we could
adopt the code we need for file upload from HTML pages.
shiro is an unknown.
The WAR file is more of a problem - we have already had someone try to
run Fuseki in Tomcat 10 and it fails. All Tomcat 9 webapps fail in
Tomcat 10.
Tomcat10 is based on jakarta while Tomcat9 is javax.
Tomcat has a migration tool: tomcat-jakartaee-migration but otherwise
it's a incompatible change. (I haven't tried the tool).
I haven't come across the reverse conversion. Maybe maven-shade-plugin
will do it.
== Distributing the WAR file.
The apache-jena-fuseki zip/tar.gz download is getting quite big. It has
both the war file and the standalong Fuseki server (jena-fuseki-fulljar).
One option is to change to providing the WAR file by a link on the
project download page, and note in the apache-jena-fuseki README.
The link could be in /binaries or to maven central.
What is hard to determine is how important the war file version actually
is nowadays. Should we focus on a runnable server Fuseki or are
multi-webapp hosting containers still common for semantic web data?
Or change the WAR file to be less webapp internally? Have a simple "all
URLs" grabber in web.xml and feed it into a wrapped FusekiMain?
== Standalone server - switch to Fuseki Main+UI
Ideally, long term, the standalone server would switch to being
Fuseli/Main + UI + Admin module. At the moment it is Jetty+and the same
code as the war file version.
More on Fuseki modules below.
Fuseki/main and Fuseki/webapp differ in how they startup and whether the
additional servlets like admin are routed by web.xml or configured by
the HTTP server builder in java code setup directly into Jetty.
== Modules
A Fuseki Module is loadable code that gets called in the server
lifecycle, principally getting called during server build with direct
access into the Fuseki server datastructures. A module can add new
features, modify the Fuseki server as it is being built or simply
monitor operations.
It only works with FusekiMain - FusekiMain has a clearly defined
lifecycle. The webapp is a "build-once" but also tied to the fixed
web.xml routing.
https://github.com/apache/jena/blob/main/jena-fuseki2/jena-fuseki-main/src/main/java/org/apache/jena/fuseki/main/sys/FusekiModule.java
This has been "experimental" in 4.3.x. I have (not-production-ready)
modules:
FMod_UI: jar file serving the static content of the UI JS/CSS/HTML
directly from the jar file. No fixed disk area for static content.
FMod_Admin: makes the admin code work as a Fuseki module.
This would also be a chance to simplify the design.
Thius experimental module is compatible with the on-disk layout of
FusekiWebapp admin.
FMod_Shiro (sktech): looks possible. A Fuseki module can add servlet
filters to the servlet dispatch chain.
FMod_FusekiKafka: Adds Kafka topics as an data input channel to Fuseki.
It can transport data, patches or SPARQL Update requests and routes them
to a dataset. (£job related.)
FMod_ProvidePATCH: Add handling of HTTP verb PATCH.
This is in "ExFusekiMain_3_FusekiModule.java"
FMod_GraphAccessCtl: Configure the graph level security
(jena-fuseki-access).
FMod_ABAC: (£job related). Triple level attribute-based security.
And recently mentioned: FMod_GeoSPARQL as a way of delivering
jena-fuseki-geosparql capability in a general FusekiMain server.
Some of these generate a new requirement not currently supported - the
ability to add arguments to the command line.
Andy
