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.
Default lookup is initialized by first call to Lookup.getDefault() using Thread.currentThread().getContextClassLoader(). This works fine if the module system is ready before other threads call Lookup.getDefault(). Using RMI within (our) RCP-App, we had to inject the netbeans system class loader into the JRE RMI subsystem by implementing RMIClassLoaderSpi. In our implementation we use Lookup.getDefault().lookup(ClassLoader.class) to find the netbeans system class loader. In some cases (e.g JMX) RMI threads are created by the JRE before the module system is ready. In this case default lookup is initialized using the default RMI Classloader (sun.misc.Launcher$AppClass) instead of the netbeans system class loader (org.netbeans.MainImpl$BootClassLoader). If this occurs an assert in org.netbeans.core.startup.Main line 307 failed and the RCP did not start. assert Repository.getDefault() instanceof NbRepository : "Has to be NbRepository: " + Repository.getDefault(); // NOI18N getModuleSystem (); I fixed our implementation using reflection to check if default lookup is initialized (hopefully by the ModuleSystem) and avoid calling Lookup.getDefault() before that. After a timeout and some retries the RMI default classloader is used as fall back. This is just a dirty workaround (using reflection to hack an API) for more fundamental problem. Please ensure that default lookup is allways initialized correctly if used with the netbeans module system.
Good idea! Now tell me, how can I do it? You mess up the classloaders and then you want me to fix it? That is insane.
Hi, I filled in this issue, because the race condition of default lookup initialization, if a thread which is running in parallel to module system startup calls Lookup.getDefault() before the module system. This may be unlikely, but can occur. (In my case it does). I just described this case. This had nothing to do with messing up classloaders! Due to race conditions are hard reproducible and that there is the assert in the code, I assumed this problem has already happened. After your comment I see my assumption was wrong. Eliminating this race condition might be to critical and/or to expensive for such an unlikely problem. A way to check if default lookup is already initialized could help to avoid illegal calls to Lookup.getDefault(). At the moment I check this by reflection. It's not nice, but it works for me. Anyways. If you still think this is insane. Feel free to close this issue as invalid/won't fix. Regards Florian
Just call Lookup.getDefault() soon enough from thread with correct classloader. Possibly use System.setProperty("org.openide.util.Lookup") as described at http://bits.netbeans.org/6.9/javadoc/org-openide-util-lookup/architecture-summary.html#systemproperty-org.openide.util.Lookup more robust initialization sequence on your side can solve the problem more easily than thinking how to isolate classloaders inside Lookup.getDefault() method. I can obviously try it, but it is not easy (we have tried once already) and the problem does not occur inside normal NetBeans based applications, so the priority is not high.
OK, when thinking about the problem, I cannot move forward without a test to reproduce it. I don't know your code, and I indeed cannot write sample RMI applications by myself to simulate the issue. For the lack of easily reproducible test case, I believe the issue is won'tfix. If you do not want to spend time writing a test case, consider using org.openide.util.Lookup system property and registering Lookup.Provider on application classpath.