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: | MultiDataObject.files() vs. PROP_FILES during init (not updating "compiled ok" status icon) | ||
---|---|---|---|
Product: | platform | Reporter: | ssffleming <ssffleming> |
Component: | Data Systems | Assignee: | David Konecny <dkonecny> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | dnoyeb, dstrupl, jbecicka, jchalupa, jglick, mentlicher, thurka, ttran |
Priority: | P2 | Keywords: | API, PERFORMANCE |
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Windows 3.1/NT | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | First draft of a patch for MultiDataObject |
Description
ssffleming
2003-01-28 00:09:20 UTC
Steve, why do you think this is a bug in core? I think java module should have to do its analysis first. Will check; still let me share sincere doubts that P1 is appropriate for this issue (even if it is a regression), if you consider this feature's impact on the user and rest of the system. I'll make this P2. In QA we get a little confused because it is often said all regressions are P1. I'll seek some clarification from my mgmt for my own information. Also feel free to re-assign to a better module. Since I see this both in Explorer and Source Editor I didn't really know where to start it...not too familiar with how Java Module fits in...I'll try to learn about this. Could you write us step-by-step instructions to reproduce it? Something like: Using internal compiler build this folder, then clean this and compile this. Thanks Sorry we cannot reproduce it in current dev builds. Please provide exact reproduction steps. Things, which may be involved: 1. the compiler compiles to another directory (Target property is set) 2. the file in question is not compiled directly (e.g. invoking Compile on it or its parent folder), but rather indirectly through dependencies. E.g. when you have Foo.java and Bar.java, Foo class references Bar and you start compilation with only Foo selected, Bar will be compiled as well. 3. 2 + the indirectly compiled file resides in another directory than the directly compiled one(s) I will ask Honza to have his engineers work with you. I see this on EE build 030203_2, but this is on a Q build that is a couple weeks old. Our latest Q build is bad so I'd like to keep this open until we see a fix has happened. If it's fixed in the new Q build I will close. I would guess it has been fixed, especially if Honza's folks can't reproduce...sound good? Confirmed. I can easily reproduce the problem with both NB dev build #200302060100 and S1S build #030205_4 on WinNT 4 SP 6, Sun JDK 1.4.1_01. Steps to reproduce: 1. Start with a clean userdir. 2. Open examples/colorpicker/ColorPreview in the Editor. 3. Make some editing changes and delete them. -> the icon is changed to the 'needs compile' status. 4. Re-compile the source (F9). 5. Watch the icon, the status badge never changes and the 'needs compile' flag stays on forever. Please investigate. Ok, I shall look at it. I believe this regression was caused by integration of issue 29002. David, Jesse can you check it. RCS file: /cvs/openide/src/org/openide/loaders/MultiDataObject.java,v Working file: MultiDataObject.java head: 1.74 branch: locks: strict access list: keyword substitution: kv total revisions: 92; selected revisions: 92 description: [...] ---------------------------- revision 1.72 date: 2003/01/13 13:33:26; author: dstrupl; state: Exp; lines: +13 -2 #29002: Jesse's code to eliminate unnecessary firing of PROP_FILES ---------------------------- Reassigning to Jesse for investigation. The fix of issue 29002 is incorrect. PROP_FILES has to be fired for newly created MultiDataObject with secondary entries. "PROP_FILES has to be fired for newly created MultiDataObject with secondary entries" - why? Where in the docs does it say anything of the sort? Why should a property change be fired for a property which has not changed? For now, will assume that JavaDataObject is simply not listening aggressively enough. For example, after DataObject.modified has changed, or after a compiler has been created for a JDO, lissenToClasses() could be called. AFAIK MultiDataObject.files() returns an incomplete set initially (before folder recognition is finished), which is arguably a bug; if you agree that this is the real problem, assign back to datasystems. IMHO it should block until all files in the folder have been recognized by some loader (not necessary for the DataObject's to be constructed, just for the file -> primary file mapping to be known). If you allow to create MultiDataObject with just primary file and add secondary entries later, that at the beginning there were no secondary file. After secondary files are recognized, there _ARE_ secondary files. So this property was changed. So PROP_FILES was fired before and must be fired now. I still suggest fixing the behavior of files() to be accurate from the start, rather than firing PROP_FILES during folder recognition. It is likely to be simpler and faster. Creating a MDO, which is by definition a collection of related files, incl. running subclass initialization code, before all of its files are even known, strikes me as bizarre at best. David can comment. Nonetheless short-term workarounds in JavaDataObject should be straightforward if they are needed, and have less impact than org.openide.loaders.* changes. *** Issue 30860 has been marked as a duplicate of this issue. *** *** Issue 30434 has been marked as a duplicate of this issue. *** 30434 has more info I think worth reviewing. *** Issue 31045 has been marked as a duplicate of this issue. *** Created attachment 9077 [details]
First draft of a patch for MultiDataObject
I have attached patch for MultiDataObject that does following: 1. does not fire before the MDO is constructed 2. fires at most twice (for each MDO) I agree that 2. is not very nice but I did not find better solution that would stay correct without a race condition. The current tests in openide pass with the patch. Also Tomas agrees that for JavaDataObject it works. So should I apply this patch or are there any improvements possible? If there are no objections I will apply this patch. Patch applied (after small change) to MultiDataObject.java 1.75. Sounds like a workaround not a fix, but probably a proper fix can wait until New Datasystems. [20030325350] verified. Not sure, If I should reopen this issue or some of its duplicates, but compile badges still does work. Steps to reproduce: 1. Mount a new filesystem and set it as a target folder for External Compilation 2. Select "examples" folder and do Build All 3. Select "colorpicker" folder and do Clean All -> compile status badges do not update its state! 4. Do refresh folder on colorpicker folder -> badges will update Please evaluate Honza you have right. If the target pacgage is not explorord in explorer the status of files is not updated. We decided to close this issue and reopen issue 30860 verified |