jglick commented on issue #4211: URL: https://github.com/apache/netbeans/issues/4211#issuecomment-1176715702
c0313ec5f0a9f29bffd00f906ed791f7eb5187bd does not look like it would change anything. Anyway I doubt the issue is about the `synchronized` statements. `lkp.lookup(Repository.class)` is returning `null` because there are two `BootClassLoader`s in play, somehow, and thus two loaded copies of `platform/core/org-openide-filesystems.jar`. Normal behavior for the test would be for the class loader to be created like this ``` at org.netbeans.MainImpl$BootClassLoader.<init>(MainImpl.java:248) at org.netbeans.MainImpl.execute(MainImpl.java:154) at org.netbeans.MainImpl.main(MainImpl.java:60) at org.netbeans.Main.main(Main.java:58) at … at java.base/java.lang.reflect.Method.invoke(Method.java:568) at org.netbeans.junit.NbModuleSuite$S.runInRuntimeContainer(NbModuleSuite.java:905) at org.netbeans.junit.NbModuleSuite$S.access$100(NbModuleSuite.java:660) at org.netbeans.junit.NbModuleSuite$S$1.protect(NbModuleSuite.java:681) at junit.framework.TestResult.runProtected(TestResult.java:142) at org.netbeans.junit.NbModuleSuite$S.run(NbModuleSuite.java:677) at … ``` and the `NbRepository` to be created like this ``` at org.openide.filesystems.Repository.<init>(Repository.java:319) at org.netbeans.core.startup.NbRepository.<init>(NbRepository.java:54) at … at java.base/java.lang.Class.newInstance(Class.java:645) at org.openide.util.lookup.implspi.SharedClassObjectBridge.newInstance(SharedClassObjectBridge.java:41) at org.openide.util.lookup.MetaInfServicesLookup$Item.getInstance(MetaInfServicesLookup.java:489) at org.openide.util.lookup.AbstractLookup.lookup(AbstractLookup.java:397) at org.openide.util.lookup.ProxyLookup.lookup(ProxyLookup.java:281) at org.openide.filesystems.Repository$3.call(Repository.java:361) at org.openide.filesystems.Repository$3.call(Repository.java:359) at org.openide.filesystems.Repository.delayFileSystemAttachImpl(Repository.java:1009) at org.openide.filesystems.Repository.getDefault(Repository.java:359) at org.netbeans.core.startup.Main.start(Main.java:281) at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:98) at java.base/java.lang.Thread.run(Thread.java:833) ``` I suspect the problem somehow pertains to JUnit or at least `NbModuleSuite`: that the failing test run is actually the second time NetBeans has been loaded in the JVM. The first time (possibly from a different test case), the default `Lookup` got an `NbRepository` as usual and cached it. The second time, the same `Lookup` class was used; when the new `BootClassLoader` was created, a new copy of `Repository` was loaded, and `Repository.getDefault` was called, the old `NbRepository` was found but the “real McCoy” defense detected that this was not actually assignable to the `Repository` class being queried, so it bailed out. Of course this is all not supposed to be possible, because each test run is supposed to load `Lookup` and everything else from scratch: https://github.com/apache/netbeans/blob/a1b803a832cb0c1161b4c522737452ea4d8d6737/harness/nbjunit/src/org/netbeans/junit/NbModuleSuite.java#L810-L814 You can see from the build log that `Log Session` is printed twice for `ValidateLayerConsistencyTest`, implying that `TopThreadGroup` is being run twice. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
