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: | (vcs generic) exception while creating the cmp bean second time after deleting | ||
---|---|---|---|
Product: | obsolete | Reporter: | Peter Liu <petertliu> |
Component: | vcscore | Assignee: | Martin Entlicher <mentlicher> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | mentlicher, ttran |
Priority: | P1 | ||
Version: | -S1S- | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
The context diff of the fix.
The binary patch for NB 3.5 / S1S 5.0. To apply, copy into <NB-install>/modules/autoload/patches/org-netbeans-modules-vcscore/ folder. |
Description
Peter Liu
2003-04-02 21:39:59 UTC
I was able to reproduce the bug. It's strange that it's remembered somewhere, that our virtuals loader was used for these files even after they disappear. I know where is the problem. If you do System.gc() after step 8., no exception is thrown! The reason is, that I store some information in the FileObject reference. But this reference is not destroyed when the FileObject disappears. So when the same FileObject is created again (or the old is cached somewhere??), it gets the same reference. IMHO this is a bug of org.openide.filesystems.*, I would suppose, that whan a FO is removed, the appropriate reference should be removed as well and the new FO should get a new reference. Radek, I'm sorry that I bothered you with this problem, it seems so far, that filesystems are innocent here. I'm going to investigate the problem on the VCS side... The problem is in VcsFileSystem.nonLocals field, which collects the virtual files, but they are not removed in this case. It would be better to get rid of this field and extract the information directly from the cache system when needed. Scheduling for 4.0 for now. If this is a low risk fix and you have time, I think it would be better we fix it for 3.5. What do you think? Martin, if you and your QA agree that this bug can be deferred util 4.0, please file for a waiver. Thanks. We think this bug should be fixed for S1S5 release. Increasing the priority. The problem is fixed in the main trunk: Checking in VcsAttributes.java; /cvs/vcscore/src/org/netbeans/modules/vcscore/VcsAttributes.java,v <-- VcsAttributes.java new revision: 1.26; previous revision: 1.25 done Checking in VcsFileSystem.java; /cvs/vcscore/src/org/netbeans/modules/vcscore/VcsFileSystem.java,v <-- VcsFileSystem.java new revision: 1.218; previous revision: 1.217 done Also issue #32562 happens to be fixed by the same commit. Created attachment 9736 [details]
The context diff of the fix.
Created attachment 9737 [details]
The binary patch for NB 3.5 / S1S 5.0. To apply, copy into <NB-install>/modules/autoload/patches/org-netbeans-modules-vcscore/ folder.
Fix reviewed without objections. New code doesn't store virtual files in HashSet and this should fix problem with reference. I tested the binary patch on NB3.5dev #200304062350 and on S1S5 #030406 approved for 3.5 by release coordinator Thanks for the review, verification and approval. The fix is merged into the release35 branch: Checking in VcsAttributes.java; /shared/data/helm/cvs/repository/vcscore/src/org/netbeans/modules/vcscore/VcsAttributes.java,v <-- VcsAttributes.java new revision: 1.22.36.5; previous revision: 1.22.36.4 done Checking in VcsFileSystem.java; /shared/data/helm/cvs/repository/vcscore/src/org/netbeans/modules/vcscore/VcsFileSystem.java,v <-- VcsFileSystem.java new revision: 1.207.2.9; previous revision: 1.207.2.8 done |