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.
In the new window system it often happens that some or all of my open Java editor windows are not restored after an IDE restart. In my log I get a lot of messages such as: [WinSys.PersistenceManager.getTopComponentForID] Problem when deserializing TopComponent for tcID:'TestUtil#002Ejava #002A'. Reason: Top component TestUtil#002Ejava #002A could not be located or loaded from Components folder. INFORMATIONAL *********** Exception occurred ************ at Fri Dec 05 15:58:39 EST 2003 java.io.FileNotFoundException: Top component TestUtil#002Ejava #002A could not be located or loaded from Components folder. [catch] at org.netbeans.core.windows.persistence.PersistenceManager.getTopComponentPersistentForID(PersistenceManager.java:505) at org.netbeans.core.windows.persistence.PersistenceManager.getTopComponentForID(PersistenceManager.java:583) at org.netbeans.core.windows.PersistenceHandler.getTopComponentForID(PersistenceHandler.java:281) at org.netbeans.core.windows.PersistenceHandler.initModeFromConfig(PersistenceHandler.java:260) at org.netbeans.core.windows.PersistenceHandler.load(PersistenceHandler.java:154) at org.netbeans.core.windows.WindowSystemImpl.load(WindowSystemImpl.java:39) at org.netbeans.core.Main$8.run(Main.java:410) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178) at java.awt.EventQueue.dispatchEvent(EventQueue.java:454) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137) at java.awt.EventDispatchThread.run(EventDispatchThread.java:100) Note the ridiculous ID "TestUtil#002Ejava #002A" (i.e. "TestUtil.java *"). I am not sure if this odd ID is what causes the file restore to not work, but at least it would be better if CloneableEditor overrode preferredId() to return something useful, such as the absolute path of the file on disk.
Marek, you remeber the issue with the prefix/postfix marks which adds settings? Is it the same?
I do not know. Once ID is created it should be used as name of settings file and should be valid file name. If this happen can you please send me content of winsys user dir? $NBUSERDIR/system/Windows2Local
Whenever this occurs, Windows2Local/Components does not have any apparently related *.settings files - i.e. no Java editor sources. Forgot to mention that the last time I saw this, I had had several files open in the last session, including all *.java except one *.properties (edited as text, not in the table view). After restarting, only the *.properties file was still open. May be significant.
Actually my open editor windows are as a rule *never* persisted these days. It seems that this is easily reproducible - just turn on Show File Extensions in System Settings and no CloneableEditor will get restored correctly. GUI form windows are restored, as well as (text) .properties files, and the Welcome screen. I should also mention that I always run with projects.jar disabled. However that by itself does not appear to break editor persistence.
I checked it, and it is problem in winsys perstistence (maybe with settings usage). Here is testcase: 1) Start IDE anew, 2) Set the property show file extensions (this is needed to be done before the sourece component is opened!) 3) Opend some source (I did ColorPreview), 4) Exit IDE, now see bellow what is in userdir 5) Restart, and it is broken of course. The problem is that there are used another escapes (for ID like "ColorPreview.java" for settings file in Components folder and other in the wstcref, thust thre ref point to non-existitng file: From the above example you can see in Components folder file named: *ColorPreview#0023002Ejava.settings* but the wstcref ID (also name of the wstcref is: *ColorPreview#002Ejava* You can see the different dot escapes #0023002E and #002E resp. Thats the real problem. Marek I remember I fired long time ago exactly same issue on your account. Was it solved?
"ColorPreview#0023002Ejava.settings" would mean the name is getting escaped twice, since "#0023" represents '#'.
I filed a separate issue for CloneableEditor which is using inappropriate IDs anyway.
Thanks Peter for info. I will investigate and hopefully fix it soon.
Assigning to Radek. Problem is that InstanceDataObject.create escapes string which is already escaped. IDO should not do it.
OK. I agree that there is no reason why to escape character '#' with string begining with '#'.
Created attachment 12511 [details] Suggested patch - is it OK for you ?
I tested patch from Radek and it works fine with winsys.
IMHO the patch is wrong. IDO should escape whatever it gets, uniformly. '#' is an unsafe character as far as it is concerned since it is used as the hex escape character; thus if it receives a string containing '#' it needs to escape it in order to safely unescape it back to '#' later. The bug (AFAICT) is that someone is escaping a particular string twice, and later unescaping it only once. So find who is escaping it twice, and fix that. Or, if necessary, make sure it is unescaped twice.
I do not agree. Why is method escape() escaping '#' repeatedly? If there is need to unescape given string I think client do not know how many times he needs to unescape given string. I want to say if I escape '#' to '#0023' and escape it again I should get again '#0023' and not '#00230023' as it is now. I think that method escape() should simply detect that '#0023' is escape sequence and do not escape it again. I have no control what IDO.create() does. To solve it in winsys I would have to keep 2 versions of unique TopComponent ID original ID and escaped ID and always pass original unescaped TC ID to IDO.create().
Re. client not knowing how many times to unescape a string - why?! If you ever do any shell programming, you certainly need to know... or for that matter if you have ever stored freeform text in XML you would need to know how many times to escape and unescape characters like '&' or the results would sometimes be incorrect. If escaping "#0023" gave again "#0023" then a string that naturally happened to contain "#0023" to begin with would be left as is on disk and then later unescaped to "#", which is not what you started with. The behavior would be asymmetric. That is why '#' is itself escaped - to make escape & unescape inverse operations. To solve things in winsys you should simply keep the ID you want to use (the original one) and whenever it is needed in a context that requires escaping of special characters, escape it, and whenever you are getting a string back from one of those contexts, unescape it. That is not a workaround, that is just writing correct code IMHO.
Ok. Taking this issue.
core/windows/src/org/netbeans/core/windows/persistence/PersistenceManager.java r.1.5 unescape() is used for TC ID when passed as parameter to InstanceDataObject.create().
*** Issue 36849 has been marked as a duplicate of this issue. ***
verified