systemPrefs

[gajowi]

the current container has the error described at: http://www.unidata.ucar.edu/software/thredds/current/tds/faq.html#javaUtilPrefs I've not seen the issue manifest until I use godiva and load WMS content (then I get warnings logged each 30s).

I've managed to fix this by changing javaopts.sh to have:

JAVA_PREFS_SYSTEM_ROOT="-Djava.util.prefs.systemRoot=$CATALINA_HOME/javaUtilPrefs -Djava.util.prefs.userRoot=$CATALINA_HOME/javaUtilPrefs"

mkdir -p $CATALINA_HOME/javaUtilPrefs/.systemPrefs

Note that I've changed the location of the javaUtilPrefs directory - this was not necessary. The functional part of the fix is to have a .systemPrefs directory ready before it is needed.

[julienchastang]

@gajowi Thanks for catching this, and thanks for participating in this project. Could you submit a pull request with your change? Also note that javaopts.sh is getting slightly rejigged in #48. (Speaking of which, any opinions about #48?). Though the next couple of weeks are very busy, I aim to tackle some of the issue list this week including the versioning mess and migrating towards dockerhub automated builds.

[gajowi]

I'd be happy enough to submit a pull request. It would seem prudent to wait for #48 to merge or to make a pull request to that fork/branch. The revised setup will need a different fix, possibly to create a directory in the Dockerfile and/or to push the problem upstream to the tomcat setup. I'd be happy to test at some point.

[julienchastang]

@gajowi Upon closer examination, there was an issue I did not notice earlier. The recommendation according to the documentation you referenced is to:

cd ${tomcat_home}/content/thredds
mkdir javaUtilPrefs
mkdir javaUtilPrefs/.systemPrefs
mkdir javaUtilPrefs/.userPrefs

But in a typical scenario ${tomcat_home}/content/thredds will live outside the container, and you will have to awkwardly address that issue outside rather than inside the container which will burden whomever is running the container. Your solution of javaUtilPrefs directory living inside the container is the better option as we can take care of this problem on the user's behalf in the Dockerfile. I assume that the javaUtilPrefs directory is not going to be filling up with log files or some such. You mention that it was not necessary, and maybe, strictly speaking, it is not but this is an opportunity to make life easier for the user. Maybe this was your thinking all along.

[gajowi]

agreed. javaUtilPrefs being inside the container makes more sense and avoids issues of the uid in the container not necessarily mapping nicely to the host.. Also taking care of this in the Dockerfile seems best - especially with the shift to a different underlying tomcat container and the apparent/related deprecation of javaopts.sh. In my limited experience, there is not a great deal of content involved. It seems to be state/persisted content from 'geotoolkit' as used by ncWMS - and lockfiles. Note that the .userPrefs directory get created automatically if possible. with an additional intermediate .java directory. I see small content (prefs.xml file) in: javaUtilPrefs/.java/.userPrefs/org/geotoolkit/referencing/factory and javaUtilPrefs/.systemPrefs/org/geotoolkit/referencing/factory and intermediate directories. We would need to read ncWMS code and/or ask the author if we wanted to be more sure.

By the way, I'm not mapping all of ${tomcat_home}/content/thredds into the container, just the config files I want to override and a single data directory that I'm putting at ${tomcat_home}/content/thredds/public/all. I have a single datasetscan catalog entry for that directory, keeping things simple.