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.
To reproduce: Add a new JFrame to the project. Add a new JPanel to the project. Mount a filesystem to the project which contains a small .gif file to be used as an icon. Anything will do. Using the form editor, add a label to the JPanel. Change the label's icon property via the IconEditor (hit the "..." button in the property value). In the icon editor, select Classpath, and browse to the .gif file you placed in the filesystem. Hit the OK button when you're done, and the panel will have a label with the icon to its left. Save and compile. In the Explorer, right-click on the panel class, select Tools > Add to Component Palette..., and add it to the Beans category. Using the form editor, open the JFrame. Select the new panel from the Beans component and attempt to add it to the JFrame. What is expected: The component should be added to the JFrame. What happens: A NullPointerException is thrown. Note that if we now go back to the JPanel, remove the icon, save, recompile, delete the bean from the palette, and add it again, and then we try to add the new panel to the JFrame, the panel is added successfully. Therefore, the presence of the icon causes the NullPointerException to be thrown.
It's serious bug. dialog : "The Component cannot be instantiated java.lang.NulllPointerException" NPE(attachment)
Created attachment 1659 [details] NullPointerException
Created attachment 3283 [details] sample form - java
Created attachment 3284 [details] sample form - form file
This issue is not related to form editor, it's some ClassLoader problem - reassigning to core. I have no idea what could be wrong... Look at the form sample in attachment (place it in the sampledir directory). There's the following code: jLabel1.setIcon(new javax.swing.ImageIcon( getClass().getResource("/examples/colorpicker/ColorPreview.gif"))); The form can be executed externaly or internally and the icon resource is found. However, trying to invoke "Customize Bean" on the form in the IDE (from Explorer) fails - because the resource is not found (this causes the NPE reported above). Note that the class and the icon are in the same filesystem... This problem occurs also in 3.2.1 and current dev builds (20011102).
Davide, can you look at this one? Thanks.
Jesse can you please check this one? Or if you know who would know please reassign accordingly. Thanks.
It's a security exception. java.security.AccessControlException: access denied (java.net.NetPermission specifyStreamHandler) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:272) at java.security.AccessController.checkPermission(AccessController.java:399) at java.lang.SecurityManager.checkPermission(SecurityManager.java:545) at org.netbeans.core.execution.TopSecurityManager.checkPermission(TopSecurityManager.java:255) at java.net.URL.checkSpecifyHandler(URL.java:527) at java.net.URL.<init>(URL.java:289) at org.openide.filesystems.FileURL.encodeFileObject(FileURL.java:82) at org.openide.filesystems.FileURL.encodeFileObject(FileURL.java:69) at org.openide.filesystems.FileObject.getURL(FileObject.java:568) at org.openide.execution.NbfsURLConnection.connect(NbfsURLConnection.java:103) at org.openide.execution.NbfsURLConnection.getHeaderField(NbfsURLConnection.java:146) at java.net.URLConnection.getContentType(URLConnection.java:377) at Fr2.<init>(Fr2.java:23) at java.lang.Class.newInstance0(Native Method) at java.lang.Class.newInstance(Class.java:237) at org.openide.loaders.InstanceSupport.instanceCreate(InstanceSupport.java:203) [catch] at org.openide.actions.CustomizeBeanAction.customize(CustomizeBeanAction.java:131) Now I need to figure out what FileURL is trying to do and why it needs to set an explicit stream handler when nbfs: is normally registered anyway.
OK, I have a patch, will commit tomorrow. Robert, I don't see any great workaround for 3.2.1 (will be fixed for 3.3). However there is a workaround which ought to be enough: start the IDE with the option: -J-Dnetbeans.security.nocheck=true If you do this, be *careful* as the IDE will turn off all internal Java security checks. In practice this means that if you are using the internal ICE browser, don't view any applets you didn't write and trust. Nor should you "Customize Bean" on any class you didn't write.
committed Up-To-Date 1.6 openide/src/org/openide/filesystems/FileURL.java
I still see the same problem in 20011116... It works using -J-Dnetbeans.security.nocheck=true.
This is very odd. I tried the original test case when fixing the bug and it worked fine. Now all my test cases used when fixing it no longer work. No security exception appears, and the raw nbfs: URLs work fine, but ClassLoader.getResource for some reason still returns null. (Note that it tries to connect to URLs and quietly swallows any exceptions it encounters, making debugging lots of fun.) Tomas your test case is not useful--you cannot customize a JFrame, as the pack() call in the constructor involves protected calls which will not work from a user-mode class (see attachment). Robert's test case with a JPanel is useful.
Created attachment 3447 [details] Stack trace showing why customizing a frame is not necessarily possible
I see. Sorry for providing bad example (JPanel should be used instead)... > (Note that it tries to connect to URLs and quietly swallows any > exceptions it encounters, making debugging lots of fun.) Yes, I also tried to debug it first but gave up...
I am still not exactly sure what enabled my earlier test case to succeed, but anyway more needed to be done. Actually getting a URL from Class.getResource() requires URLClassPath to like your URLConnection.permission, which the nbfs: connection did not specifically provide, thus it was the default AllPermission, which the user-mode class definitely cannot get. File read permissions are all that are really needed for making an nbfs: connection; in principle user-mode classes would have difficulty with that too, however in fact TopSecurityManager gives unconditional file read permission anyway (for performance reasons), so this succeeds. committed * Up-To-Date 1.17 openide/src/org/openide/execution/NbfsURLConnection.java committed * Up-To-Date 1.7 openide/src/org/openide/filesystems/FileURL.java and a test for NbClassLoader added.
*** Issue 18208 has been marked as a duplicate of this issue. ***
*** Issue 18719 has been marked as a duplicate of this issue. ***
*** Issue 19534 has been marked as a duplicate of this issue. ***
veryfied.
Resolved for 3.4.x or earlier, no new info since then -> closing.