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.
Summary: | Module fails to load when installed simultaneously with dependencies | ||
---|---|---|---|
Product: | platform | Reporter: | _ briansmith <briansmith> |
Component: | Autoupdate | Assignee: | akemr <akemr> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | jglick |
Priority: | P3 | Keywords: | THREAD |
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Windows ME/2000 | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | ide.log with -J-Dorg.netbeans.core.modules=0 |
Description
_ briansmith
2002-09-28 08:02:11 UTC
Created attachment 7551 [details]
ide.log with -J-Dorg.netbeans.core.modules=0
I vote for 2. option (installing in dependency order). Slightly decreasing the priority (because existing workaround), however I'll work on this issue the problem immediately. Fixed in trunk. AU writes now Modules/*.xml files in proper order of dependency. I don't think #2 is brittle. The module system will try to process file events as they come in; note that it can get a batch of them at once. If there are several new XML files all saying "enabled", AFAIK it will first create all the modules, then enable them all in order - at least ModuleList is written to work in this way. (The unit test does not yet cover this, however.) My *guess* is that this bug was caused by the filesystem actually delivering the creation event(s) for the dependent XML files before the event(s) for the base XML files, which of course cannot work. This seems to be supported by the log file, which delivers the second file change event after ML has already started processing the first. Perhaps AU creates each new XML file in its own FileSystem.AtomicAction - that will prevent ModuleList from knowing that all the modules should be installed "together". This is not fixed completely yet. The problem is "better" now in that it doesn't happen nearly as often, but it still does occur. The times I have noticed it, it was my non-autoload module depending on my autoload module, with my non-autoload module not being able to start because it thought that the autoload module wouldn't start. I think I can produce a testcase for this that is more likely to show the problem, by creating a large number of "fake" modules with interdependcies that can then all be built into nbm's for testing. I will work on it in a few days... I meant: "...with my non-autoload module not being able to start because it thought that the autoload module was not installed." OK, probably I should create all XML files in one FileSystem.AtomicAction Fixed in trunk. AU now creates all Modules/*.xml files in one FileSystem.AtomicAction Thanks, I haven't noticed this problem at all in the last week. Probably the 3.4.1_CANDIDATE status of this bug should match issue 27600, especially since it is unlikely that somebody is going to install an autoload module without also installing a module that depends on it. I.e. either both should have it or neither should have it. Brian, if you can confirm that the bug appears to be fixed in dev builds, please mark it VERIFIED. Did you see this bug in 3.4, or only in pre-4.0 dev builds? If you think it happens also in 3.4, please change the Version field to 3.4 and feel free to add the 3.4.1_CANDIDATE keyword to it. Thanks for detailed bug reports! Marking with THREAD keyword since the bug appears to involve a race condition. verified |