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.
I have just enhancd the HTTP Javadoc file system to change its display name to show its state at it retrieves its structure from the web server. During the time the FS is scanning, the name should change to "URL (scanning...)," and when it is done, it should revert back to just the URL. When I first made these changes, I noticed the UI wasn't reacting to the property event changes I was firing for PROP_DISPLAY_NAME. I modified org.openide.code.RootFolderNode to change its display name on PROP_DISPLAY_NAME changes instead of PROP_SYSTEM_NAME changes, (which itself already fires a PROP_DISPLAY_NAME change event). After I made this change, the UI appeared to be working correctly. Unfortunately, I discovered after I checked in my change that it was only working intermittently. In addition, when the FS fires two PROP_DISPLAY_NAME change events during its initialization, the FS doesn't appear in the UI until after it's done scanning the web server. If I remove the second property change event during initialization, it appears immediately when it is mounted as it had before. I have checked in the HTTP Javadoc file system code that is demonstrating this problem. When the FS is first mounted, it should appear with the name of the URL that was mounted. Immediately after that, the name should change to "URL (scanning...)" when it begins scanning the web server, and then change back when it is done. The name should also change when the user selects "Refresh File System" from the context menu and the web server is rescanned. If after looking at this, you see something I've done incorrectly in the FS code, please let me know.
passing to FS guys.
AWT thread is waiting for lock. Problem of synchronization. Should be solve in javadoc.httpfs. See attchement.
Created attachment 6308 [details] thread dump
As I began looking into how to resolve the locking issues demonstrated in the attached thread dump, I discovered that this issue is no longer occurring.
Resolved for 3.4.x or earlier, no new info since then -> closing.
Resolved for 3.3.x or earlier, no new info since then -> closing.