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 “hardInit()” 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 4:59 PM, Claude Warren <[email protected]> wrote: > > Andy, > > I checked out the Jena-1029_subsystem branch and found no problems with > jena-permissions. is your note to indicate that you made changes to the > test code? I'm not sure what you mean. > > Claude > > On Fri, Sep 18, 2015 at 10: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 >> >> > > > -- > I like: Like Like - The likeliest place on the web > <http://like-like.xenei.com> > LinkedIn: http://www.linkedin.com/in/claudewarren
