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.
refactoring/qa-functional/jdk15 automated tests There are failing Find usages tests: findClassAllSubtypes test doesn't find a subtype with declared generic (finding class A): public class B<T> extends A<T> findField - doesn't find a field occurance with generic list = new ArrayList<String>(); There are also thrown some NPE into the ide.log.
Created attachment 18427 [details] NPE's stacktrace
*** This issue has been marked as a duplicate of 50666 ***
Where are the refactoring/qa-functional/jdk15 automated tests, and how do I run them? I found a refactoring/test/qa-functional directory, but it doesn't have a jdk15 subdirectory. Running ant in refactoring/test only ran the unit tests. Thanks!
jdk15 is a testattribute of qa-functional test. Try to run build.xml in refactoring/test fodler with set properties: xtest.testtype=qa-functional xtest.attribs=jdk15
The tests are still failing. They don't find some occurances of some classes.
I cannot reproduce it manually. I assume, that Find Usages does not work, because some refactoring in previous tests did not finish correctly.
This bug is RANDOM, not reproducible manually (at least I cannot reproduce it) and unfortunately I cannot reproduce it while the tests are running under the debugger. Problem in findField test is, that some occurences of "list" are sometimes resolved to UnresolvedClass. BTW refactoring operations made by these tests are not enclosed by MDR transaction.
Should be Find usages enclosed by mdr transactions? I assumed that it shouldn't. Am I wrong? (All find usages tests are not done in transactions.)
> Should be Find usages enclosed by mdr transactions? I assumed that it shouldn't. Am I wrong? Yes it should. > (All find usages tests are not done in transactions.) Some are done, some not, why? e.g. WhereUsedTestCase.findFiled() is enclused by transaction, but findClass() doesn't. Why? Anyway - this is not the problem in this case. This bug happens sometimes even if I added those transactions.
I've repaired the tests.
I found out, that parser is sometimes unable to resolve several classes. I'm attaching series of dumpStacks showing that parser failed to resolve classes.
Created attachment 18516 [details] Stacktraces
*** Issue 50214 has been marked as a duplicate of this issue. ***
We did some improvements, but this bug is still reproducible: User: jbecicka Date: 04/10/27 00:34:13 Modified: javacore/src/org/netbeans/modules/javacore RepositoryUpdater.java ExclusiveMutex.java Log: + Resources are deleted during start of outer transaction + parseIfNeeded is called during start of outer transaction (not every transaction) this should supress some InvalidObjectExceptions User: mmatula Date: 04/10/27 06:23:47 Modified: javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel ResourceImpl.java Log: Another up-to-date checking bug fixed.
I cannot reproduce this bug, If I remove other tests from this test bag. It looks like the problem is not with JDK 1.5.
Finally I found reproducible "manual" test case!!! 1. Open refactoring/test/qa-functional/data/projects/default2 2. Do Find Usages on abc.A (10 occurences found) 3. Do Rename on abc.A -> RenamedA 4. Do Find Usages on abc.RenamedA (only 3 occurences found) Exceptions thrown to console.
Problem is, that some MultipartIds has isNew==true even after successful commit.
We have a fix for my test case, but unfortunately not for original report. Emane, please where is test spec. describing what these tests does?
2 bugs fixed here: 1. change of multipartid was not propagated correctly to it's parent 2. NameRef in SemiPersistentElement was constructed from simple name instead of full name Fixes applied to trunk. It is hard for us to verify random bug. Please check latest test results and let us now, if this bug is still there. Thanks Checking in FieldImpl.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/FieldImpl.java,v <-- FieldImpl.java new revision: 1.18; previous revision: 1.17 done Checking in JavaClassImpl.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/JavaClassImpl.java,v <-- JavaClassImpl.java new revision: 1.38; previous revision: 1.37 done Checking in MethodImpl.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/MethodImpl.java,v <-- MethodImpl.java new revision: 1.16; previous revision: 1.15 done Checking in ParameterImpl.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/ParameterImpl.java,v <-- ParameterImpl.java new revision: 1.10; previous revision: 1.9 done Checking in SemiPersistentElement.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/SemiPersistentElement.java,v <-- SemiPersistentElement.java new revision: 1.57; previous revision: 1.56 done
Emane, please can you provide detail description of what these tests exactly does? Thanks
Pavel will try to find it...
Failing tests are Find usages and Rename. But there are Move class tests and Encapsulate fields tests running before. Each test has its test case written at the begin of its .ref file. After a test is finished undo action is called (except find usages tests). Test sources are in the CVS. Do you want some more detail informations?
Fixed in trunk. Checking in java/javacore/src/org/netbeans/modules/javacore/internalapi/UndoManager.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/internalapi/UndoManager.java,v <-- UndoManager.java new revision: 1.10; previous revision: 1.9 done Processing log script arguments... More commits to come... Checking in java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/SemiPersistentElement.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/SemiPersistentElement.java,v <-- SemiPersistentElement.java new revision: 1.59; previous revision: 1.58 done Processing log script arguments... More commits to come... Checking in refactoring/test/cfg-unit.xml; /cvs/refactoring/test/cfg-unit.xml,v <-- cfg-unit.xml new revision: 1.4; previous revision: 1.3 done
I reviewed the fix - it is OK.
Fix merged to release40 branch. Checking in javacore/src/org/netbeans/modules/javacore/internalapi/UndoManager.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/internalapi/UndoManager.java,v <-- UndoManager.java new revision: 1.9.8.1; previous revision: 1.9 done Processing log script arguments... More commits to come... Checking in javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/FieldImpl.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/FieldImpl.java,v <-- FieldImpl.java new revision: 1.16.8.2; previous revision: 1.16.8.1 done Checking in javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/JavaClassImpl.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/JavaClassImpl.java,v <-- JavaClassImpl.java new revision: 1.37.2.3; previous revision: 1.37.2.2 done Checking in javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/MethodImpl.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/MethodImpl.java,v <-- MethodImpl.java new revision: 1.14.8.2; previous revision: 1.14.8.1 done Checking in javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/ParameterImpl.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/ParameterImpl.java,v <-- ParameterImpl.java new revision: 1.8.8.2; previous revision: 1.8.8.1 done Checking in javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/SemiPersistentElement.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/SemiPersistentElement.java,v <-- SemiPersistentElement.java new revision: 1.55.2.3; previous revision: 1.55.2.2 done Processing log script arguments...
verified