You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@netbeans.apache.org by "Thierry Danard (JIRA)" <ji...@apache.org> on 2018/06/14 16:30:00 UTC

[jira] [Commented] (NETBEANS-934) A lock is kept on window settings file

    [ https://issues.apache.org/jira/browse/NETBEANS-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16512715#comment-16512715 ] 

Thierry Danard commented on NETBEANS-934:
-----------------------------------------

Running from code, we found that calling Mode.getTopComponents() prior to clearing the .settings files was the culprit. Hard to tell, but it seems NetBeans keeps input streams open for a while when Mode.getTopComponents() is called

> A lock is kept on window settings file
> --------------------------------------
>
>                 Key: NETBEANS-934
>                 URL: https://issues.apache.org/jira/browse/NETBEANS-934
>             Project: NetBeans
>          Issue Type: Bug
>          Components: platform - Window System
>    Affects Versions: 9.0
>            Reporter: Thierry Danard
>            Priority: Minor
>             Fix For: 9.0
>
>
> I have an application that is based upon the NetBeans platform. In this application, we have a session mechanism where users can save and restore the state of the windows. The way this session mechanism works is:
> To save:
>  * force a serialization of the window state (calling org.netbeans.core.WindowSystem.save)
>  * save the content of all files in Windows2Local in a "session" file
>  * save the content of the tracker.properties file in the same "session" file
> To restore:
>  * wipe out the content of the Windows2Local directory and replace it with the saved content, then
>  * replace the content of the tracker.properties file
>  * force a clear/reload using reflection:
> // load netbeans state from disk
>  System.gc();
>  System.gc();
>  FileUtil.refreshAll(); // needed to discard any caches copy of the setting files
> Class windowSystemClass = Thread.currentThread().getContextClassLoader().loadClass("org.netbeans.core.WindowSystem");
>  Class windowManagerClass = Thread.currentThread().getContextClassLoader().loadClass("org.netbeans.core.windows.WindowManagerImpl");
>  Class persistenceHandlerClass = Thread.currentThread().getContextClassLoader().loadClass("org.netbeans.core.windows.PersistenceHandler");
>  Class persistenceManagerClass = Thread.currentThread().getContextClassLoader().loadClass("org.netbeans.core.windows.persistence.PersistenceManager");
> Object windowSystem = Lookup.getDefault().lookup(windowSystemClass);
> Method method = windowSystemClass.getMethod("hide");
>  method.invoke(windowSystem);
> method = windowManagerClass.getMethod("getInstance");
>  Object windowManager = method.invoke(windowManagerClass);
>  windowManager.getClass().getMethod("resetModel").invoke(windowManager);
>  windowManagerClass.getMethod("setRecentViewList", String[].class).invoke(windowManager, new Object[]{new String[0]});
> method = persistenceManagerClass.getMethod("getDefault");
>  Object persistenceManager = method.invoke(persistenceManagerClass);
>  persistenceManager.getClass().getMethod("clear").invoke(persistenceManager);
> method = persistenceHandlerClass.getMethod("getDefault");
>  Object persistenceHandler = method.invoke(persistenceHandlerClass);
>  persistenceHandler.getClass().getMethod("clear").invoke(persistenceHandler);
> method = windowSystemClass.getMethod("load");
>  method.invoke(windowSystem);
> method = windowSystemClass.getMethod("show");
>  method.invoke(windowSystem);
> This used to work in versions 8.x, but no longer. Some ".settings" files are locked. The files that stay locked vary, which points to something related to garbage collection. File.canWrite() actually returns false for some files. 
> After some investigation, I found that the lock issue is probably a permission issue (I am on Windows). It looks like that some process is removing the ownership/permissions of the .settings files that are being created. Some .settings files have no owner and no permissions. This explains why File.canWrite returns false for these files.
> What is this mechanism in NetBeans that changes the ownership or permissions of the settings files?
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@netbeans.apache.org
For additional commands, e-mail: commits-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists