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.
Summary: | Palette bean containing label with classpath icon throws NullPointerException | ||
---|---|---|---|
Product: | platform | Reporter: | Robert Baruch <autophile> |
Component: | Filesystems | Assignee: | Jesse Glick <jglick> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | issues |
Priority: | P3 | ||
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
NullPointerException
sample form - java sample form - form file Stack trace showing why customizing a frame is not necessarily possible |
Description
Robert Baruch
2001-06-20 18:01:57 UTC
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. *** *** 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. |