On 05/01/2023 09:59, Simon Bin wrote:
On Thu, 2023-01-05 at 09:47 +0000, [email protected] wrote:
So, this sounds like an XY problem. You haven’t described why it’s
necessary to change Jena initialisation (which is generally a bad
idea), presumably it causes you some problem, but without knowing
what that problem is we can’t give you an answer on whether this is
the right solution
If you really want to change anything ServiceLoader based (not just
Jena) then the way to do that is to re-pack the JARs, e.g., with
Maven Shade plugin, filtering out the META-INF services files you
don’t want and inserting your own hand-crafted one(s).
Let me describe one concrete example in more detail; for a command line
tool that is supposed to be quick to run, can and should pick up jena-
geosparql from the classpath in order to provide geo functionality.
However if the user already knows that they won't need it, they should
be able to skip it with a command line flag thus saving precious
startup time. Messing with shading and manually crafting service files
does not seem like the best way to me.
Jena System initialization is quick. (For commands, classloading costs
are much longer - you could precompile Jena with Graalvm)
Initialization is also assumed to have happened; mostly its fill
reigistries (Java maps). Code afterwards does not recheck whether
initialization has been done or skipped.
If you skip something, then don't rely on anything working.
You can add you own initialization - see "SubSystem" (which is what
Fuseki does for modules - it means modules can assume the core system is
initialized).
jena-geosparql initialization from the service loader is not doing any
long operations that I can see but if that is the problem you're
encountering, it would be better to fix it in jena-geosparql than risk
instability everywhere.
Another way: If you want to customize what's run, a shell script to
calculate the classpath then if you don't need geosparql, don't put it
on the classpath. That's a benefit of the ServiceLoader approach.
Andy
Rob
From: Simon Bin <[email protected]>
Date: Wednesday, 4 January 2023 at 19:37
To: [email protected] <[email protected]>
Subject: Re: Re: Question concerning Subsystem Registry
On Wed, 2023-01-04 at 15:59 +0000, Andy Seaborne wrote:
What are you trying to change?
Currently I want to stop some JenaSubsystemLifecycles from loading
and
run some alternate action even if they are present in a META-INF
services file, for example if they are on the class path. The old
docs
sound like they would have allowed me to do so.
Thanks,
Andy
On 04/01/2023 13:08, Simon Bin wrote:
Hi,
I'm trying to change the Subsystem Registry in order to have a
better
control about JenaSystem.init, I found this page ==>
https://jena.apache.org/documentation/notes/system-initialization.html
However I cannot follow it, as there is no
JenaSystem.setSubsystemRegistry.
Any ideas?
