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
