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.
After core separation it happens that property editors for Compiler, Debugger, Executor and so on are not found (message <no property editor> in property sheet - see screen shot) when IDE is run by XTest harness on JDK1.4.1. It works well on JDK1.3.1. It breaks testability of IDE.
Created attachment 7870 [details] Screen shot
[nb_dev](20021106) Jesse: Do you know something about it ?
Additional info: Me and Jirka has been looking at it. The modules core/compiler core/execution are installed correctly. They have added their seach path's to the PropertyEditorManager. Also when tried the code (via script): System.err.println(java.beans.PropertyEditor.findEditor(org.openide.execution.Executor.class)); it has printed the instance. So it seems the problem has to be somewhere else. Please investigate the sheets, why the property editors weren't propagated there successfuly.
Sorry, there should be: System.err.println(java.beans.PropertyEditorManager.findEditor(org.openide.execution.Executor.class));
Raising the priority because it blocks some automated tests and it seems nobody is going to resolve it.
There is a problem with the current thread. The context class loaders differs between: 1) the ide run from xtest with jdk1.3 (test passes), 2) the ide run from xtest with jdk1.4 (test fails), 3) the ide run commonly from command line with jdk1.4 (the property editors are set correctly.) So, the ide run from xtest with jdk1.4 don't fully simulate standard the run ide. Look at the attached contents of Thread.currentThread ().getContextClassLoader () from each type of ide. There is no defect in openide/propertyeditors of this sort of issue I reassigning to xtest framework. If I'm wrong then assign to classloaders.
Created attachment 7989 [details] content of class loader
Created attachment 7990 [details] content of class loader
Created attachment 7991 [details] content of class loader
Please try a Thread.dumpStack at every place in the NB code where Thread.setContextClassLoader is called, printing also the new loader, and see if the timing differs acc. with JDK 1.4.
I can try to investigate this...
There is a bug in AWT: #4786277 I have a workaround, though, which seems to work: property editors are shown in XTest.
committed Up-To-Date 1.153 core/src/org/netbeans/core/Main.java
Verified in build 200212020100.
Hi, I am reopenning the issue. Setting the context classloader of the AWT thread should be done on the very start of the method Main.initializeMainWindow(). Use case: main window constructing the main menu uses the content of the system file system for this. From there there could be (and in my case is) a callback to my module (be it constructor or method value). So there is a sequence calling my code there form AWT thread without the context classloader being set on it. And that in turn fail to load classes using JNDI (but that in fact just references some instance using InstanceDataObject). To be more accurate that screws the very usage of the core/naming module because the javax.naming.InitialContext relies on the core naming module being accessible via context classloader which in this case is not true.
Created attachment 11348 [details] Patch for branch release35
Patch attached (for release35 branch). Took me the whole day to figure out ;-((((
dstrupl: 1. Don't forget to add yourself as a CC when adding comments. 2. I still consider this bug fixed. For your case, which is somewhat different and AFAIK does not occur in normal XTest usage, please file a separate bug, blocking this one. I think this patch should go into the trunk, but it is not P1 for most r35 users. 3. Use the -u switch to cvs diff; contextless diffs are very hard to read/evaluate and apply to slightly changed sources.
x
Jesse, what is "normal" xtest usage? I just have module depending on core/naming (not endorsed by Sun as stable I must admit) and the module uses JNDI to create contents of main menu. Nothing abnormal IMHO. Ok, I will create a separate issue if you wish. But just moving your patch couple of lines above helps to solve my problem.
Fine, just in a separate issue # please... the modification is apparently needed only for core/naming, which is not used by any stable modules in 3.5.
The new issue is 35470. Thanks.
It is fixed, isn't it? So, verifying.
Created attachment 11967 [details] Diagnostic patch JAR (for boot classpath)