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.
Description: 1.mounted cvs direcory. 2.created simple_bug package. 3.Performed add operation using cvs. 4.Performed commit operation. 5.created cmp bean with schema and all interfaces. 6.selected all the files in the package, performed add and commit operations. 7.Selected all the files, used delete key to delete all the files. 8.Selected all the files, performed cvs operation remove and commit. 9.Selected the same package created the cmp bean with same schema(table) with all the interfaces. Exception is throwed at this point. Annotation: Exception occurred in Request Processor java.lang.ClassCastException: org.netbeans.modules.vcscore.util.virtuals.VirtualsDataObject at com.sun.forte4j.j2ee.ejb.EJBeanDataObject.createFromWizard(EJBeanDataObject.java :424) at com.sun.forte4j.j2ee.ejb.wizard.GenericEJBWizard$2.run(GenericEJBWizard.java:145 ) at org.openide.util.Task.run(Task.java:136) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:328) [catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:668) A comment.
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