Hello César Le 05/02/2018 à 18:57, César Martínez Izquierdo a écrit :
> I think that JNDI may be relevant to specify the database used by a > specific SIS deployment. > Yes, but an issue is that there is no JNDI environment by default in a standard Java installation. JNDI environments come with container like Tomcat. We could provide our own micro-JNDI environment when none is present (it is not difficult to do), but wasn't sure we want to go that path. > For the user case I was describing, I think the method you cited > (Initializer.getDataSource()) is more than enough (and also generic), > as I just want to launch queries against the configured database > (whichever it is). However, it will be useless if it is not visible on > Java 9. > In Java 9, it it still possible to bypass the restriction with an option given to Java on command-line. Even with restriction enabled, that functionality can still be available in next SIS version; we just need to decide how (JNDI or otherwise). A possible approach may be to use Initializer.getDataSource() for now, and switch to the public API later after we provided one. > In any case, now I realise that for a particular deployment, if I know > I will be using epsg with derby, I can just create a new data source > to "SpatialMetadata" database, using Java standard procedures. > The difficulty is to determine in which directory is located the database (unless using the embedded database, or the default Derby location). I would suggest to use Initializer.getDataSource() instead, and try to agree on a public API for next SIS release. I opened a JIRA issue if anyone want to comment on that: https://issues.apache.org/jira/browse/SIS-395 Martin