This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Let's have an old .settings file containing a persisted setting in the serial data format. In order to start using a convertor you have to follow the convertor registration. Having that if the system encounters the old setting it is read with SerialDataConvertor and any modification of the setting is stored via the new registered convertor. If you like to upgrade both the format (new convertor) and the setting's class, the documentation advises to use META-INF/netbeans/translate.names and implement readResolve in the old class. That is correct. Old instanceof elements are translated so that the old setting acts as the new one. So far so good. Issues arise when the SerialDataConvertor tries to read persisted data via NBObjectInputStream which uses Utilities.translate too. Then it tries to deserialize old object using new class. It is wrong from the settings support point of view. So I would propose the following change. The NbObjectInputStream could check if an old class exists and if so then do not use the translation.
Priority changed to P2 because it blocks possibility to upgrade any settings rewritten to new Settings Convertor API.
You should first fix issue #27584.
Created attachment 7524 [details] Real example -- Utilities module.
I have attached Utilities module patch to demonstrate upgrade on real situation. It contains new PDF Viewer settings. 1) In unpatched IDE change PDF Viewer property. [IDE Configuration > Server and External Tool Settings > PDF Settings] (Tip: Save ${userdir}/system/Services/org-netbeans-modules-pdf-PDFSettings.settings for future debugging.) 2) Apply patch; in utilities module execute: patch -p0 < utilities.diff 3) Build changed Utilities module: nbbuild$ ant -Dmodules=utilities merge 4) Run IDE and try to change PDF Viewer property again. Now you get exception and depends on it if you have META-INF/netbeans/translate.names in module or not.
Created attachment 7525 [details] With translate.names: NPE - cannot deserialize old PDFSettings to new Settings class.
Created attachment 7526 [details] WithOUT translate.names + try to change property value: IAE - it is instance of Settings class but PDFSettings is expected.
Created attachment 7559 [details] patch for core/settings
The patch adds a special object input stream solving the issue to org.netbeans.modules.settings.convertors.XMLSettingsSupport.
Created attachment 7560 [details] unit tests patch testing the proposed modification
Thanks to Jan fixed. Tested also real example - utilities module. Info for Libor: PDFSettings.java needs modification, else you can expect endless loop or IllegalArgumentException. diff PDFSettings.java PDFSettings.ok 35c35 < public File getPDFViewer () { --- > private File getPDFViewer () { 47c47,52 < Settings settings = new Settings(); --- > Settings settings = Settings.getDefault(); > > if ( settings == null ) { > // Create new default Settings instance > settings = new Settings(); > }
Patch works, i.e. it correctly reads old settings format and delegate to new class. But I have different problem with such new settings. If I change Settings' properties they are not persistent, i.e. it is not stored to system/Services/...settings file. It looks that nobody adds PropertyChangeListener to ...pdf.Settings in this case. -- Other strange thing is that pdf.Settings.Default() does not return all time same instance! I have added simple debug code to openfile.Settings, i.e. if you select "Open File Server" settings then pdf.Settings.getDefault() is called and the Settings instance is written to console. Sometimes it does not display same value during IDE run. Open Options dialog, select "Open File Server". Restart IDE. Two instances of Settings are created. -- [I will add new complete patch for debug purposes.]
Created attachment 7580 [details] Utilities module patch #2.
1) Read old settings format: pdf.Settings instance is created in PDFSettings.readResolve: Settings.addPropertyChangeListener: org.netbeans.core.projects.SerialDataConvertor$SaveSupport@...... 2) NO old settings format: pdf.Settings instance is created dirrectly: Settings.addPropertyChangeListener: org.netbeans.modules.settings.convertors.XMLPropertiesConvertor@...... -- 3) Described problem with two instances causes ols transient settings -- listener is added to first instance only, but user edit second one, i.e. nobody listents on it and then nothing is stored to file.
Fixed in trunk (manifest.mf). File DTD_Session_settings_1_0.instance in session layer overwrites core definition then dependency necessary. Else not ensured, which Env.Provider will be used. Then may occur (even if settings present), that provider comes from core.
Verified - now I can read old settings and change is stored in new format (with exception (3) described in my previous comment).
New issue for (3) problem - issue #27812.