Hi, >From our side, the only distribution of Fuseki we are using is the Docker image (plain server without UI).
On Sun, Jan 2, 2022 at 5:23 PM Andy Seaborne <a...@seaborne.org> wrote: > > 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
