Bug 103159 - FileEvents delivered sooner than Modules enabled/disabled
FileEvents delivered sooner than Modules enabled/disabled
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Module System
6.x
All All
: P2 (vote)
: 7.2
Assigned To: Jaroslav Tulach
issues@platform
: 7.1_WAIVER_APPROVED, API_REVIEW_FAST
: 184302 (view as bug list)
Depends on:
Blocks: 99466 195388
  Show dependency treegraph
 
Reported: 2007-05-02 17:35 UTC by mslama
Modified: 2012-05-04 09:52 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Wraps Mutex into filesystem AtomicAction; removes mutexPriviledged() (129.74 KB, patch)
2011-06-30 09:08 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description mslama 2007-05-02 17:35:07 UTC
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.
Comment 1 mslama 2007-05-02 17:37:52 UTC
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.
Comment 2 Jaroslav Tulach 2007-05-03 15:43:35 UTC
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

Possible fixes:
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 
reloaded
c) change module system to not fire the filesystem events before the module is 
reloaded

Radek, what do you think? Can you try to write a test for the problem Marek 
reported? Then we can try various solutions...
Comment 3 Jaroslav Tulach 2007-05-03 15:45:23 UTC
There is no core/settings category in IZ, sorry for selecting wrong one.
Comment 4 mslama 2007-05-03 16:30:48 UTC
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".
Comment 5 Antonin Nebuzelsky 2008-04-15 17:15:24 UTC
Reassigning to new module owner jskrivanek.
Comment 6 Jiri Skrivanek 2008-11-21 08:08:57 UTC
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.
Comment 7 Antonin Nebuzelsky 2009-07-24 13:30:08 UTC
Reassigning back to window system. This is not a FS issue.
Comment 8 Stanislav Aubrecht 2009-09-08 08:33:24 UTC
imho, this is a problem in module system. other modules than window system may listen to changes in xml file system
Comment 9 Jesse Glick 2009-09-17 00:08:12 UTC
We don't support reloading any more so I am unlikely to spend time on this.
Comment 10 Jaroslav Tulach 2011-06-30 07:41:49 UTC
*** Bug 184302 has been marked as a duplicate of this bug. ***
Comment 11 Jaroslav Tulach 2011-06-30 09:08:37 UTC
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.
Comment 12 Jaroslav Tulach 2011-12-05 13:26:36 UTC
Possibly cause for bug 195388, I'd like this to be fixed for 7.2.
Comment 13 Jesse Glick 2011-12-05 14:01:52 UTC
(In reply to comment #12)
> Possibly cause for bug 195388

Doubtful.


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.
Comment 14 Jaroslav Tulach 2012-05-02 11:14:36 UTC
ergonomics#2e4d2a356bcd
Comment 15 Quality Engineering 2012-05-04 09:52:33 UTC
Integrated into 'main-golden', will be available in build *201205040400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/2e4d2a356bcd
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #103159: First of all initialize the module code and only then deliver file change events


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo