Window system uses InstanceDataObject to create TopComponent instances. When
module is enabled it adds new data to filesystem. Winsys listens to chanegs on
filesystem and processed newly created data in Windows2 folder. Problem is when
winsys asks for InstanceCookie for newly added TC settings file IDO returns null.
For more details and info how to reproduce it see issue #99466. Shortly when CVS
module is deactivated and then deactivated creating TC instance from
synchronize.settings fails. This is not problem of settings file as it works
fine when TC is instantiated from Versioning menu.
1. WinSys listens on FileSystem events.
2. FileSystems delivers these events before module seems to be initialized
1+2 => IDO thinks the module should be disabled
a) change WinSys to listen on IDO and their getLookup for IC
b) change core/settings impl of IC to understand that a module is being
c) change module system to not fire the filesystem events before the module is
Radek, what do you think? Can you try to write a test for the problem Marek
reported? Then we can try various solutions...
There is no core/settings category in IZ, sorry for selecting wrong one.
I could delay filesystem events in ModuleChangeListener in winsys (it processes
added winsys config files in Windows2 folder) but I need to know what event will
tell me: "Process delayed events now".
Reassigning to new module owner jskrivanek.
I don't understand what can be done in filesystems to fix this issue. I am willing to help if you give me some background.
Reassigning back to window system. This is not a FS issue.
imho, this is a problem in module system. other modules than window system may listen to changes in xml file system
We don't support reloading any more so I am unlikely to spend time on this.
*** Bug 184302 has been marked as a duplicate of this bug. ***
Created attachment 109163 [details]
Wraps Mutex into filesystem AtomicAction; removes mutexPriviledged()
The basic change is trivial. Before changing layers, start runAtomicAction and deliver events only when it is over - e.g. without Mutex.isWriteAccess().
The diff is huge, as it is common in tests to rely on mutexPriviledged() being available. For the safety reasons, I removed the method (visible by my laziness anyway) and everywhere I now have to use Mutex.writeAccess.
OK? I know I proposed similar fix once for project mutex and it did not work, as essential events were delivered too late. This time it should be safer, as ModuleManager.mutex() is friend API and the usages I could find look sane.
Possibly cause for bug 195388, I'd like this to be fixed for 7.2.
(In reply to comment #12)
> Possibly cause for bug 195388
For patches like this that involve changes in logical indentation level of many code blocks without other interesting changes, I would strongly suggest you leave the physical indentation of the block untouched, so that hg diff, hg annotate, etc. do not consider the block itself modified. (Using diff -w to produce the patch for review would make the patch look smaller, but would still mess up annotate.)
Patch to ModuleSystem.java also looks suspiciously long - was code rearranged for some reason? Try to undo.
Also the patch does not apply against trunk for me:
patching file core.netigso/test/unit/src/org/netbeans/core/netigso/EnabledAutoloadTest.java
Hunk #1 FAILED at 53
Hunk #2 succeeded at 94 with fuzz 2 (offset 6 lines).
1 out of 2 hunks FAILED -- saving rejects to file core.netigso/test/unit/src/org/netbeans/core/netigso/EnabledAutoloadTest.java.rej
patching file core.netigso/test/unit/src/org/netbeans/core/netigso/IntegrationTest.java
Hunk #2 FAILED at 100
1 out of 2 hunks FAILED -- saving rejects to file core.netigso/test/unit/src/org/netbeans/core/netigso/IntegrationTest.java.rej
patching file core.startup/src/org/netbeans/core/startup/ModuleList.java
Hunk #1 succeeded at 94 with fuzz 1 (offset 2 lines).
Hunk #2 succeeded at 1206 with fuzz 2 (offset 23 lines).
patching file core.startup/test/unit/src/org/netbeans/core/startup/ModuleListTest.java
Hunk #1 FAILED at 70
1 out of 6 hunks FAILED -- saving rejects to file core.startup/test/unit/src/org/netbeans/core/startup/ModuleListTest.java.rej
patching file o.n.bootstrap/manifest.mf
Hunk #1 FAILED at 0
1 out of 1 hunks FAILED -- saving rejects to file o.n.bootstrap/manifest.mf.rej
Other than that, the content of the patch seems OK to me.
Integrated into 'main-golden', will be available in build *201205040400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jaroslav Tulach <email@example.com>
Log: #103159: First of all initialize the module code and only then deliver file change events