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.
This is probably a bug related to my evangelism activities, but it's a serious bug none-the-less. In order to demonstrate some NetBeans feature, I usually maintain a "clean" version of my project that I can reset back to in order to do the demo again next time. Here's an example of a reproducible test case: I just tested this on the 20060619 build and I can still corrupt the MDR storage following these steps (sorry, they're complicated, but reproducable): 1) Download and install JBoss 4.0.4 GA and add the JBoss Server to NetBeans. 2) Create 2 class libraries using the attached jar files: - JBossSeam - jboss-seam.jar - JBossSeamUI - jboss-seam-ui.jar 3) Unzip the attached RegistrationInterceptorAnnotation.zip and open the project. Allow the classpath scanning to finish. Close the project and close NetBeans. 4) Delete the project folder (regisration). 5) Unzip the attached RegistrationReset.zip 6) Start NetBeans and open the Registration project again. 7) Open User.java and try to add an annotation @Name at the top of the class file. You'll get the InvalidObjectException and code completion will no longer work. Here are the links to the attached files: http://www.netbeans.org/nonav/issues/showattachment.cgi/31318/jboss-seam.jar http://www.netbeans.org/nonav/issues/showattachment.cgi/31319/jboss-seam-ui.jar http://www.netbeans.org/nonav/issues/showattachment.cgi/31320/RegistrationInterceptorAnnotation.zip http://www.netbeans.org/nonav/issues/showattachment.cgi/31321/RegistrationReset.zip
Created attachment 31323 [details] messages.log
FWIW, I have also been able to end up with corrupted MDR storage on recent trunk builds. Since issue 73679 was a P1, changing the priority of this one as well. I will try to provide some additional sets of steps that can cause cache corruption.
There is j2ee.metadata.NNMDRListener on the stack trace again. I suppose the problem could be there (or somwhere between listener and javacore). Dan also work on additionl fixes which can cause InvalidObjectExceptions..
I've tried to reproduce it, but I cannot. Is it a random bug? Or does it happen regularly? There were some fixes on javacore side (issue 77982) and also registration of NNMDRListener was imroved. The stack trace seems to be old. NNMDRListener does not use non-API UsageFinder any more, but correctly uses API method getReferences. Can anyone reproduce this issue? Jirko? Thanks
I managed to reproduce it. Here is my messages.log
Created attachment 31505 [details] messages.log
*** Issue 77565 has been marked as a duplicate of this issue. ***
I'm not sure, weather this issue is still stopper. If I open attached projects, they are not properly configured. I must resolve broken reference, but OK. Then if I open User.java, most lines are underlined because of missing persitence API. If I add javaee.jar, and then add @Name, everything is OK. But If I add @Name not having javaee.jar on the project classpath, I get some exceptions (but not those from attachment). It is definitely bug, but code completion still works for me.
Checking in ProblemFindingUtils.java; /cvs/j2ee/verification/src/org/netbeans/modules/j2ee/verification/Attic/ProblemFindingUtils.java,v <-- ProblemFindingUtils.java new revision: 1.1.2.9; previous revision: 1.1.2.8 done Jirko, please verify
I have better fix.
Fixed in trunk JavaUpdater.java (in directory D:\sources\release55\java\javacore\src\org\netbeans\modules\javacore\scanning\) Checking in ClassUpdater.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/scanning/ClassUpdater.java,v <-- ClassUpdater.java new revision: 1.17; previous revision: 1.16 done Checking in JavaUpdater.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/scanning/JavaUpdater.java,v <-- JavaUpdater.java new revision: 1.26; previous revision: 1.25 done fixed in release55 Checking in java/javacore/src/org/netbeans/modules/javacore/scanning/ClassUpdater.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/scanning/ClassUpdater.java,v <-- ClassUpdater.java new revision: 1.11.34.5; previous revision: 1.11.34.4 done Checking in java/javacore/src/org/netbeans/modules/javacore/scanning/JavaUpdater.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/scanning/JavaUpdater.java,v <-- JavaUpdater.java new revision: 1.23.14.1.2.2; previous revision: 1.23.14.1.2.1 done Checking in j2ee/verification/src/org/netbeans/modules/j2ee/verification/ProblemFindingUtils.java; /cvs/j2ee/verification/src/org/netbeans/modules/j2ee/verification/Attic/ProblemFindingUtils.java,v <-- ProblemFindingUtils.java new revision: 1.1.2.10; previous revision: 1.1.2.9 done fixed release55_beta2 JavaUpdater.java (in directory D:\sources\release55\java\javacore\src\org\netbeans\modules\javacore\scanning\) Checking in ClassUpdater.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/scanning/ClassUpdater.java,v <-- ClassUpdater.java new revision: 1.11.34.3.2.1; previous revision: 1.11.34.3 done Checking in JavaUpdater.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/scanning/JavaUpdater.java,v <-- JavaUpdater.java new revision: 1.23.14.1.2.1.2.1; previous revision: 1.23.14.1.2.1 done
Unfortunatelly it still doesn't work properly (NB Dev 200607131800). IOE is thrown when caret is placed in the editor. See the attached messages.log It's IMHO not a P1, since there is no datalost or deadlocks. External changes in code are always dangerous and hard to handle.
Created attachment 31880 [details] new messages.log
Ooops. Fixed in trunk and release55. Checking in ClassUpdater.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/scanning/ClassUpdater.java,v <-- ClassUpdater.java new revision: 1.18; previous revision: 1.17 done Checking in ClassUpdater.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/scanning/ClassUpdater.java,v <-- ClassUpdater.java new revision: 1.11.34.3.2.2; previous revision: 1.11.34.3.2.1 done
Reorganization of java component