I’ll offer my comments here, for what they’re worth: 1) It’s not clear to me what the purpose of JenaInitLevel0 is. Is it just to log on init and shutdown? Maybe a comment there would be good…
2) It seems to me that the pattern to use an alternative registry would be: do JenaSystem.set(myRegistryImpl) and then proceed to use Jena code (and at various points in the Jena code JenaSystem.init() occurs)? Correct? But there are places in this branch (e.g. ModelCom) wherein JenaSystem.init() occurs inside a static initializer block. How would people have the chance to call JenaSystem::set before those static initializers run? Or am I misunderstanding the use of the hook? 3) Just a typo: the Javadoc on JenaSubsystemRegistry uses the name JenaSubsystemCollector (maybe an older draft?). 4) JenaSubsystemRegistry::load is described as being called only once. That seems to mean that it won’t be possible to dynamically add services during runtime. I understand that this isn’t meant to be a replacement for heavier systems, but it might be nice to offer a “Init()” or something like that which _would_ load a new snapshot from the registry for dynamic action. But maybe that’s something that needs real examples to be discussed. --- A. Soroka The University of Virginia Library On Sep 18, 2015, at 5:30 AM, Andy Seaborne <[email protected]> wrote: JENA-1029 I've just pushed a new branch 'Jena-1029_subsystem' which replaces the Class.forName used by Jena core to write in RIOT, together with various subsystem init functions. It uses ServiceLoader by default. Th following initialization happens: Core, RIOT, ARQ, TDB (in that order) Text, Spatial, SDB (in any other afterwards) Rob - Not done (yet): Elephas and Jena JDBC both have a few ARQ.init() calls (looks to me that the ones in tests "just to be sure") - these are better JenaSystem.init() now. I can change and test those easily enough. What I'm not sure is if either system itself needs or wants to be initialized in this new way. I can add the necessary logic and services/ file if there is. Jena JDBC "MemDriver.register()" and "RemoteEndpointDriver.register()" would be candidates though java.sql.DriverManager already plays the ServiceLoader game when the code first touches DriverManager. (?? It's been a long since I went near JDBC.) Then we'll see just how many ingenious ways people have of using Jena that break the default ServiceLoader mechanism. There is a simple hook to inject a different way of providing the initialization calls. Andy Claude - bug fix in jena-permissions (bad test data) Commit: 8389829d6ae15ad0a2a0214b72035283d110d69e
