#9 Linux: annoying preferences warning messages

alpha_pre-1.0
closed-fixed
Laurent Cohen
GUI (22)
5
2006-03-14
2006-03-09
Laurent Cohen
No

when starting the monitoring and admin tool, I get a
series of warning messages such as this one:

[java] Mar 9, 2006 3:10:21 AM
java.util.prefs.FileSystemPreferences$7 run
[java] WARNING: Prefs file removed in background
/home/lcohen/.java/.userPrefs/jppf/ChartConfigurations/_!%)!}@"y!&8!@w"o!'%!cg"0!(:!|w"&!(g!~@"j!(`!d!"p!'8!bg"f!(@!a@"t!'`!|w"i!'%!cg"f!':!a!"h!()!d!"f/prefs.xml

This happens when saving chart configurations through
the default Java preferences mechanism.

From what I've seen in the Java forums, this seems to
be tied to an inherent design issue with the file
system preferences in Sun's JDK, ever since JDK 1.4.

This does not occur on Windows, I guess because the
default on Windows is to use the registry.

Discussion

  • Laurent Cohen
    Laurent Cohen
    2006-03-14

    • status: open --> closed-fixed
     
  • Laurent Cohen
    Laurent Cohen
    2006-03-14

    Logged In: YES
    user_id=1252190

    There were actually 2 problems:

    1) The Preferences implementation used on Linux does not
    handle non alphanumeric names for the preferences nodes.
    I fixed this problem by only using alphanumeric names for
    the nodes JPPF creates.

    2) Once I solved thie first problem, I started getting
    messages like this:
    WARNING: Invalid preferences format in
    /home/lcohen/.java/.userPrefs/jppf/TabConfigurations/TabConfiguration0/prefs.xml

    After a long investigation, I could determine the problem
    was due to the preferences system using the wrong XML parser
    to read the preferences files (which are in XML).
    It relies on the parser that comes with the JDK.
    However, the JFreeChart libraries come bundled with a
    different version of the Apache Xerces parser, and that was
    the one the rpeferences were picking up.

    From there, I had to find a way to ensure that when Java
    looks for a parser, it finds the JDK's first.
    I achieved this by using the services API, creating the file
    META-INF/javax.xml.parsers.DocumentBuilderFactory under the
    source root, with the name of the class to use as the
    default DocumentBuilderFactory (in this case
    com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl).

    This issue is now fixed, and the fix will be included in the
    next release.