localization/i18n: geotools map

[bernhardreiter]

The swing map component of geotools in the gui is still in English.

[bernhardreiter]

de71d5612f3d375e4cfbe20ab72f92e2baaa10dc activates the localization of the geotools wms swing map, though this does not work with geotools 14.3 and (probably) not with 15.0 because 15.0 possibly has the same code.

The 14.3 jar installed by maven contains the necessary property files: (probably ~/.m2 if not symlinked to a different place) cd ~/.m2/repository/org/geotools/gt-swing/14.3 jar -vtf gt-swing-14.3.jar | grep properties shows that there are translations for de and it.

However debugging shows that PropertiesFileFinder.scan() from swing/src/main/java/org/geotools/swing/locale/PropertiesFileFinder.java does not find the embedded properties files. entry = jarFile.getNextJarEntry() within in that method does not return something.

Debugging was done with a bare-bones method aka mvn exec:exec -Dexec.executable="java" -Dexec.args="-classpath %classpath -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=2066 de.bayern.gdi.App"

and then attach to it with jdb -attach 2066 stop in org.geotools.swing.locale.LocaleUtils.loadLocaleInfo and subsecquent "next" or "step" commands, with "print" commands like

print path path = "jar:/home/ber/.m2/repository/org/geotools/gt-swing/14.3/gt-swing-14.3.jar!/org/geotools/swing/locale/PropertiesFileFinder.class"

Next steps:

• find out why this fails precisely.
• Report the issue to geotools.
• try building the gt-swing module of geotools separately.

[bernhardreiter]

Okay, let me see where the defect is and if I can rebuild only gt-swing-14.3.jar with modifications.

[bernhardreiter]

The path like mentioned above does not result into a stream that discovers jarEntry(s) in PropertiesFileFinder.getAsJarInputStream().

Here is a patch against 14.3 which makes it work in my testing situation:

--- swing.org/src/main/java/org/geotools/swing/locale/PropertiesFileFinder.java2016-03-21 21:13:00.000000000 +0100
+++ swing/src/main/java/org/geotools/swing/locale/PropertiesFileFinder.java    2016-06-03 00:25:18.898023059 +0200
@@ -30,8 +30,11 @@
 import java.util.Locale;
 import java.util.jar.JarEntry;
 import java.util.jar.JarInputStream;
+import java.util.logging.Level;
+import java.util.logging.Logger;

 import org.geotools.data.DataUtilities;
+import org.geotools.util.logging.Logging;

 /**
  * Searches for properties files in a resource directory within the gt-swing module
@@ -64,15 +67,18 @@
      * @return
      * @throws IOException 
      */
+    private static final Logger LOGGER = Logging.getLogger("org.geotools.swing");
     public List<PropertiesFileInfo> scan(String resourceDir) throws IOException {
         List<SingleFileInfo> infoList = new ArrayList<SingleFileInfo>();

         String path = getSelfPath();
         if (isJarPath(path)) {
+            LOGGER.log(Level.FINE, "Reading JarPath({0}).", path);
             JarInputStream jarFile = getAsJarInputStream(path);
             JarEntry entry;
             while ((entry = jarFile.getNextJarEntry()) != null) {
                 String name = entry.getName();
+                LOGGER.log(Level.FINER, "Found JarEntry {0}.", name);
                 if (name.startsWith(resourceDir) && name.endsWith("properties")) {
                     infoList.add(parseEntry(resourceDir.length(), name));
                 }
@@ -135,8 +141,18 @@
     private JarInputStream getAsJarInputStream(String jarPath) throws IOException {
         JarInputStream jis = null;

+        // under some circumstances (reproduced with java8 and maven builds
+        // on Debian Jessie and OpenSUSE GNU/Linux) a jarPath here like
+        // "jar:file:/home/ber/.m2/repository/org/geotools/gt-swing/14.3/gt-swing-14.3.jar!/org/geotools/swing/locale/PropertiesFileFinder.class"
+        // will not result in a stream which contains jarEntry(s). 
+        // So we try converting it to a file url, which works on the platforms
+        // mentioned above:
+        if (jarPath.startsWith("jar:file:/")) {
+            jarPath = jarPath.substring(4, jarPath.lastIndexOf("!"));
+        }
+
         URL jarUrl = new URL(jarPath);
-        
+        LOGGER.log(Level.FINE, "using jarURL = {0}.", jarUrl);
         InputStream is = jarUrl.openStream();
         jis = new JarInputStream(is);

Rebuilding a single module with geotools was fairly easy:

• downloaded e15824eeafa33947a95b8d3c54d3c20dc363c209 geotools-14.3-project.zip

unzip geotools-14.3-project.zip
cd /geotools-14.3/modules/unsupported/swing
mvn compile
mvn install

The combination with 2 cores also works: mvn compile install -T 2C

[bernhardreiter]

I've reported the defect to geotools upstream: https://osgeo-org.atlassian.net/projects/GEOT/issues/GEOT-5432

I had the problem under GNU/Linux with mvn compile exec:java openjdk and oracle java8. The behaviour may be different when deployed, started in different ways or used on different platforms. At least this is what is reported in a number of articles and tutorials on the web. This is why the fix is quite minimal and the results should be tested under production conditions on different platforms.

+        if (jarPath.startsWith("jar:file:/")) {

could potentially replaced with

+        if (jarPath.startsWith("jar:file:")) {

if the path on windows has a backslash there.

enabling debug output.

Just for reference here is one way to enable the FINER diagnostic output for the module. Use a custom logging configuration file like

::::::::::::::
logging.properties
::::::::::::::
handlers= java.util.logging.ConsoleHandler
.level = INFO

java.util.logging.ConsoleHandler.level = FINER
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter

org.geotools.swing.level = FINER
::::::::::::::

which is adapted from the system default file (e.g. found in $JAVA_HOME/jre/lib/logging.properties and start with it like

mvn  exec:java -Djava.util.logging.config.file=/home/bernhard/werkbank/downloadclient/logging.properties