Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6568540

(prefs) Preferences not saved in Webstart app, even after synch()

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: P3 P3
    • None
    • 6
    • core-libs

      FULL PRODUCT VERSION :
      java version "1.6.0"
      Java(TM) SE Runtime Environment (build 1.6.0-b105)
      Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)


      ADDITIONAL OS VERSION INFORMATION :
      Linux dot-desktop 2.6.17-11-386 #2 Thu Feb 1 19:50:13 UTC 2007 i686 GNU/Linux

      Ubuntu 6.10 (Edgy) - 32 bit


      A DESCRIPTION OF THE PROBLEM :
      I have a java webstart app the uses the Preferences API to store settings. These settings are successfully persisted w/ JRE 1.4, and 1.5. With JRE 6, I can see empty (0 byte) files being created in my home/.java/.userPrefs dir, but even after the app calls prefsNode.synch() and after the app closes, these prefs files remain empty. When the app restarts and attempts to read the prefs nodes that should have been saved, the nodes are empty.

      The webstart app is signed. I've tried clicking "Always Trust..." in the webstart dialogs, but this has no effect.

      Attempts to trigger a preferenece store (using the default provider ie FileSystemPreferences) fail with a java.util.prefs.BackingStoreException caused by java.lang.IllegalArgumentException due to XmlSupport.writeDoc attempting to set the "indent-number" attribute on the TransformerFactory (stack trace at end).

      Since IllegalArgumentException is the proper response for an unrecognised attribute, and the indent is not essential to prefences operation it is reasonable to expect prefences to catch and ignore the exception. (1.5.0 works bacuase it does not set this attribute)

      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      Get a prefs node via Preferences.userNodeForPackage(this.getClass()) in a webstart app. put new prefs in this node via prefs.put("newKey", "newValue"), and call prefs.synch(). No errors occur, and some empty preferences files will be created. Close the webstat app, and restart and try to read this value and it will not have been set.

      To reproduce:
        1) compile test case
        2) run test case under jdk 1.6.0 beta with saxon8.jar as jaxp transform provider:
      java -cp .:saxon8.jar testing.PrefTest

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      Saved preferences in a webstart app worked in Ubuntu under jre 1.4 and 1.5. They should also work in 6.0.
      ACTUAL -
      Preferences are not saved, and no error is thrown.

      ---------- BEGIN SOURCE ----------

      /*
       * PrefTest.java
       *
       * Created on 1 March 2006, 10:44
       * $Id: $
       * Altered on 11 April 2007
       */

      package testing;

      /**
       * Test for preferences sync
       * nb to reproduce issue must run with saxon8 as jaxp transform provider on a platform that uses FileSystemPreferences
       *
       * @author Clive Brettingham-Moore
       * @author Dan Rollo - adapted for saxon8, jdk6
       */


      public class PrefTest {

          /**
           * @param args the command line arguments
           */
          public static void main(String[] args) {
              // do pref sync
              try {
                  java.util.prefs.Preferences prefs = java.util.prefs.Preferences.userRoot();
                  prefs.put("test", String.valueOf(Math.random()));
                  prefs.sync();
              } catch (java.util.prefs.BackingStoreException e) {
                  // Exception due to issue
                  e.printStackTrace();
              }
          }

      }
      ---------- END SOURCE ----------

      ERROR MESSAGES/STACK TRACES THAT OCCUR :
      ~/jreBugReport944608-WebstartPrefs/bugreport944608/src/main/java$ java -cp .:saxon8.jar testing.PrefTest
      Apr 11, 2007 11:53:44 PM java.util.prefs.FileSystemPreferences$7 run
      WARNING: Prefs file removed in background /home/dan/.java/.userPrefs/prefs.xml
      java.util.prefs.BackingStoreException: java.lang.IllegalArgumentException: Unknown attribute indent-number
              at java.util.prefs.FileSystemPreferences$8.run(FileSystemPreferences.java:615)
              at java.security.AccessController.doPrivileged(Native Method)
              at java.util.prefs.FileSystemPreferences.writeBackCache(FileSystemPreferences.java:600)
              at java.util.prefs.FileSystemPreferences.syncSpiPrivileged(FileSystemPreferences.java:784)
              at java.util.prefs.FileSystemPreferences.access$2300(FileSystemPreferences.java:33)
              at java.util.prefs.FileSystemPreferences$13.run(FileSystemPreferences.java:754)
              at java.security.AccessController.doPrivileged(Native Method)
              at java.util.prefs.FileSystemPreferences.syncSpi(FileSystemPreferences.java:752)
              at java.util.prefs.AbstractPreferences.sync2(AbstractPreferences.java:1317)
              at java.util.prefs.AbstractPreferences.sync(AbstractPreferences.java:1308)
              at java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:731)
              at testing.PrefTest.main(PrefTest.java:30)
      Caused by: java.lang.IllegalArgumentException: Unknown attribute indent-number
              at net.sf.saxon.Configuration.setConfigurationProperty(Configuration.java:2211)
              at net.sf.saxon.TransformerFactoryImpl.setAttribute(TransformerFactoryImpl.java:342)
              at java.util.prefs.XmlSupport.writeDoc(XmlSupport.java:247)
              at java.util.prefs.XmlSupport.exportMap(XmlSupport.java:333)
              at java.util.prefs.FileSystemPreferences$8.run(FileSystemPreferences.java:607)
              ... 11 more
      Apr 11, 2007 11:53:45 PM java.util.prefs.FileSystemPreferences syncWorld
      WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: java.lang.IllegalArgumentException: Unknown attribute indent-number


      REPRODUCIBILITY :
      This bug can be reproduced always.

      Release Regression From : 5.0u11
      The above release value was the last known release where this
      bug was not reproducible. Since then there has been a regression.

            sherman Xueming Shen
            ndcosta Nelson Dcosta (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: