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
