Improve ability to support custom arguments for Fuseki Servers #2753
Comments
Improves how Fuseki arguments are customised, in particular makes the ServerConfig class public adding the ability to store extra configuration on it. It also changes the previously private static applyServerArgs() method into a protected instance method so users can extend FusekiMain and override it to use that to customise the FusekiServer.Builder further. Unit tests are added that validate that custom arguments can now be passed through CLI inputs and used to influence the Server being built.
Improves how Fuseki arguments are customised, in particular makes the ServerConfig class public adding the ability to store extra configuration on it. It also changes the previously private static applyServerArgs() method into a protected instance method so users can extend FusekiMain and override it to use that to customise the FusekiServer.Builder further. Unit tests are added that validate that custom arguments can now be passed through CLI inputs and used to influence the Server being built.
Improves how Fuseki arguments are customised, in particular makes the ServerConfig class public adding the ability to store extra configuration on it. It also changes the previously private static applyServerArgs() method into a protected instance method so users can extend FusekiMain and override it to use that to customise the FusekiServer.Builder further. Unit tests are added that validate that custom arguments can now be passed through CLI inputs and used to influence the Server being built.
|
General comment - when (if!) there is a switch to Fuseki Main + UI + Admin for the standalone server ( If that comes along, PR #2754 would be fitted into a formal lifecycle for the command line. Do you think adding a new interface |
|
@afs Yeah when we started on this work I had it in my head that we'd previously discussed an extension point for adding custom arguments into Fuseki but then I found what was there didn't really work for the reasons described here. Ideally making the arguments a more formal integration point would be useful. However not sure what that looks like in practise because there's some separation of concerns issues. Currently arguments are used to populate a I'd almost be tempted to move argument processing concerns more directly into the I'm not in a rush to get this into Let me have a play around in a separate PR for comparison purposes, this will likely be Tues next week at the earliest before I can get to this. |
|
The builder is available in The extensions would ideally not subclass It needs a "prepare args" via some provided |
Refactors how the FusekiMain CLI can be customised to make it more flexible and interface driven. CLI extensions have to be statically registered prior to invoking FusekiMain but are now able to both customise the arguments available and to directly affect the FusekiServer.Builder without needing to sub-class FusekiMain
Refactors how the FusekiMain CLI can be customised to make it more flexible and interface driven. CLI extensions have to be statically registered prior to invoking FusekiMain but are now able to both customise the arguments available and to directly affect the FusekiServer.Builder without needing to sub-class FusekiMain
|
@rvesse -- I'm working on a PR with material taken from #2773 that focuses on just a customised command line. I think there needs to more steps in the customisation process
|
|
@afs You're much more familiar with this area of rhetoric code so if you have a cleaner approach then my initial attempt happy to test that once it's ready |
Version
5.1.0
Feature
The Fuseki Modules mechanism makes it possible to add extensions to Fuseki but modules have to rely upon external configuration sources e.g. System Properties, Environment Variables, Fuseki Configuration file etc. because there isn't a meaningful way to pass configuration via the command line.
FusekiMainis built on Jena's general CLI framework which means we can in principal extendFusekiMainand add additional arguments via the constructor, or use the staticFusekiMain.addArgModule()method to register global extensions.However, it's hard to do anything meaningful with these custom arguments,
processModulesAndArgs()currently populates a privateServerConfigclass which is then used to actually populate aFusekiServer.builder()via a private staticapplyServerArgs()which cannot be modified. Thus even if a custom argument is introduced the only way for it to pass configuration to a module would be by placing it into System Properties, static variable or another JVM wide store that the module can later read back.As a practical example of this we're looking to introduce support for specifying Fuseki configuration via a YAML configuration file for which we'd like to add a
--yaml-config <yaml-file>argument and then have aFusekiModuledo aprepare()step which reads in the<yaml-file>and modifies theFusekiServer.Builderaccordingly. Right now we can't do that cleanly because there's no way to get the value of<yaml-file>passed into the builder for later access without resorting to passing it out-of-band.It would be better if we were able to carry extra configuration information via
ServerConfigand overrideapplyServerArgs()so that we can apply that to the builder this would offer users who want to extendFusekiMainmuch more flexibility.Are you interested in contributing a solution yourself?
Yes
The text was updated successfully, but these errors were encountered: