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.

Bug 27595

Summary: serial data settings upgrade
Product: platform Reporter: Jan Pokorsky <jpokorsky>
Component: -- Other --Assignee: rmatous <rmatous>
Severity: blocker CC: jglick, lkramolis
Priority: P2    
Version: 3.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:
Bug Depends on: 27584    
Bug Blocks: 27163, 27164, 27165    
Attachments: Real example -- Utilities module.
With translate.names: NPE - cannot deserialize old PDFSettings to new Settings class.
WithOUT translate.names + try to change property value: IAE - it is instance of Settings class but PDFSettings is expected.
patch for core/settings
unit tests patch testing the proposed modification
Utilities module patch #2.

Description Jan Pokorsky 2002-09-25 18:47:49 UTC
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 

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.
Comment 1 _ lkramolis 2002-09-26 07:53:31 UTC
Priority changed to P2 because it blocks possibility to upgrade any
settings rewritten to new Settings Convertor API.
Comment 2 _ lkramolis 2002-09-26 08:21:44 UTC
You should first fix issue #27584.
Comment 3 _ lkramolis 2002-09-26 09:10:03 UTC
Created attachment 7524 [details]
Real example -- Utilities module.
Comment 4 _ lkramolis 2002-09-26 09:26:21 UTC
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
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.
Comment 5 _ lkramolis 2002-09-26 09:40:51 UTC
Created attachment 7525 [details]
With translate.names: NPE - cannot deserialize old PDFSettings to new Settings class.
Comment 6 _ lkramolis 2002-09-26 09:48:19 UTC
Created attachment 7526 [details]
WithOUT translate.names + try to change property value: IAE - it is instance of Settings class but PDFSettings is expected.
Comment 7 Jan Pokorsky 2002-10-01 14:59:58 UTC
Created attachment 7559 [details]
patch for core/settings
Comment 8 Jan Pokorsky 2002-10-01 15:03:46 UTC
The patch adds a special object input stream solving the issue to
Comment 9 Jan Pokorsky 2002-10-01 15:05:53 UTC
Created attachment 7560 [details]
unit tests patch testing the proposed modification
Comment 10 rmatous 2002-10-02 18:46:27 UTC
Thanks to Jan fixed. Tested also real example - utilities module. Info
for Libor: needs modification, else you can expect
endless loop or IllegalArgumentException.

diff PDFSettings.ok
<     public File getPDFViewer () {
>     private File getPDFViewer () {
<         Settings settings = new Settings();
>         Settings settings = Settings.getDefault();
>         if ( settings == null ) {
>             // Create new default Settings instance
>             settings = new Settings();
>         }
Comment 11 _ lkramolis 2002-10-03 10:02:42 UTC
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.]
Comment 12 _ lkramolis 2002-10-03 10:14:05 UTC
Created attachment 7580 [details]
Utilities module patch #2.
Comment 13 _ lkramolis 2002-10-03 10:23:49 UTC
1) Read old settings format: pdf.Settings instance is created in

2) NO old settings format: pdf.Settings instance is created dirrectly:

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.
Comment 14 rmatous 2002-10-03 17:38:54 UTC
Fixed in trunk ( 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.  
Comment 15 _ lkramolis 2002-10-04 08:26:35 UTC
Verified - now I can read old settings and change is stored in new
format (with exception (3) described in my previous comment).
Comment 16 _ lkramolis 2002-10-04 08:57:59 UTC
New issue for (3) problem - issue #27812.