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.
I have: - built a simple bean with a single String property, - added BeanInfo for the bean, - setup a property editor for the single property, - setup a custom property editor consisting of a JPanel that contains a TextField and a JButton - the JTextField allows an end-user to type in the value of the property string - clicking the JButton opens a JFileChooser so that end-user can point to a file and click after which the JTextField is populated with the file pathname, and - created a jar that has these components together with a manifest that identifies the bean I can then create a sample JFrame application wherein I: - add the above sample bean into the component palette using Tools/NewJavaBean - drag-n-drop the bean into the JFrame - select the bean in the form, - select the single property in the Properties dialog - select the property customizer This opens a dialog containing my custom property editor, and looks correct! What I then should be able to do is: - either enter text into the JTextField, and/or - click the JButton to open the JFileChooser The JTextField works fine. But when I click the JButton, I immediately get the following exception: java.security.AccessControlException: access denied (java.io.FilePermission {my home directory} write) (where "{my home directory}" is the path to my system home directory. I have tried messing with the JDK security options to try to work around this issue without success. In any case, I think this message is bogus, because I have found a really ugly workaround that does not involve security at all. Here is the workaround: - after receiving the above message, I close the error message dialog box, - I enter text into the JTextField and press OK in the property editor dialog (this ensures that code is written into the sample application) - I then save all files in the project - I then select Project/ProjectManager and open the Default project - after the Default project opens, I once again select Project/ProjectManager and re-open the sample application project - I then select the bean, and choose to customize the property - the property editor dialog opens once more - this time, when I click the button, it opens the JFileChooser no problem But, if I drag the bean into the application form once more - add another instance of the bean, I experience exactly the same problem with the JButton for the new instance, even though the first instance has no problem. Really weird!
Created attachment 4118 [details] a JAR containing source code for the sample bean
Created attachment 4119 [details] a JAR containing the bean's compiled classes, icon and the manifest
Hello, I have tried your example and found this: The problem occurs only in case you have the classes compiled in the IDE before you install your JavaBean. So the problem go away if you just install the resulting jar and you don't have the sources mounted in the IDE. There is probably a problem in the classloader somewhere. but it needs further investigation. Making it P3 since there is a workaround that is not that complicated. Side note: I have just grabbed your .jar file and tried to install the bean - there were no problems. I played with it in form editor - still no problems. After a while I tried to also look at the sources and compiled them - and voila the problem started to occur. So no sources no problem ;-0
I tried your workaround, but I still see the problem. I'm not totally sure that I was able to "unmount the sources" exactly. I basically have two projects - SampleBean defines the bean and jar stuff, and, TestSampleBean holds the end-user application that uses the SampleBean. I didn't want to delete SampleBean, so all I did was go into the project, select FileSystems within the Explorer, and unmount the local directory whre the code resides. Was that sufficient? I also stopped then re-started NetBeans. Neither of these made any difference. I still get the SecurityAccessException first up.
Ok, just to be a bit more specific, here's what I did to check out your workaround. Btw, my develop system is Linux, just to help with the following: 1) I quit NetBeans 2) I removed $HOME/nbuser33 completely 3) I removed {installDir}/netbeans completely 4) I restored NetBeans by un-taring the distro 5) I restarted NetBeans - completely fresh version 6) I created a new JFrame app 7) I remembered I'd kept the jar file inside nbuser33 (oops) 8) I downloaded the sample.jar from this web page (yay!) 9) I used Tools/InstallNewJavaBeans to add my bean to the Palette 10) I added an instance of the sample bean to my JFrame app 11) I selected the bean, went into properties, 12) I opened the custom proeprty editor, clicked the JButton - SecurityAccessException still :-(
I did exactly the 12 steps you put here and it did not occur. But it did occur if I have the sources mounted and compiled them. The unmounting procedure (Filesystems tab, right click the local file system, unmount) was correct. The only problem is that after unmounting the sources you have to restart the IDE (this at least worked for me). Anyway are you saying that you can see the exception even in case in which your filesystem tab does not contain the sources and you have just started the IDE? I also assume you don't have the sources for the editor in the same directory as your fresh JFrame app. Simply put are you saying that the IDE can see only the jar from "Install new JavaBean" and not the original sources/classes? If you still have problems please zip and attach your nbuser33/system directory to this bug (i hope it does not contain any secret information you cannot share with us). Also please attach your policy files - $JAVA_HOME/jre/lib/security/java.policy, $NETBEANS_HOME/bin/ide.policy. Those files should not differ but I might have modified my copies and would like to be sure we use the same. Thanks for your time (and patience with me).
Now I probably know how this happens... There are basically two problems: - a ClassLoader problem with instance support, - a strange behaviour in EditorSupport stuff in org.openide.text 1) The class loader problem - classes loaded by InstanceSupport (for InstanceDataObjects) are loaded by a custom class loader (NbClassLoader) granting only read only access permissions. So classes added from palette to form don't have write permission. However the same classes loaded by form editor during form opening using TopManager.currentClassLoader have write permission - that's why the mentioned "workaround" works. 2) The second part of the problem is the question why the custom user class would need the write permission. It is needed due to the behaviour of EditorSupport I don't understand. Briefly - when doing some change in custom property editor, the change is propagated to form editor which regenerates the code - so replaces the guarded section in the java document. But this leads in the end to asking wheteher the java file is read only, which requires the write permission. I don't know why this read-only check on file is done with each change to the document. This did not happen in 3.2.1 (even for the first change). I'm attaching the stack trace: java.security.AccessControlException: access denied (java.io.FilePermission C:\BuildDev_Work\settings\sampledir\Fr1.java write) 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:243) at java.lang.SecurityManager.checkWrite(SecurityManager.java:978) at org.netbeans.core.execution.TopSecurityManager.checkWrite (TopSecurityManager.java:186) at java.io.File.canWrite(File.java:527) at org.openide.filesystems.LocalFileSystem.readOnly (LocalFileSystem.java:401) at org.openide.filesystems.LocalFileSystem$Impl.readOnly (LocalFileSystem.java:691) at org.openide.filesystems.AbstractFileObject.isReadOnly (AbstractFileObject.java:134) at org.openide.text.DataEditorSupport.messageName (DataEditorSupport.java:152) at org.openide.text.EditorSupport$Del.superMessageName (EditorSupport.java:673) at org.openide.text.EditorSupport.messageName(EditorSupport.java:147) at org.openide.text.EditorSupport$Del.messageName (EditorSupport.java:648) at org.openide.text.CloneableEditor.updateName (CloneableEditor.java:496) at org.openide.text.CloneableEditorSupport.updateTitles (CloneableEditorSupport.java:1210) at org.openide.text.EditorSupport$Del.superUpdateTitles (EditorSupport.java:689) at org.openide.text.EditorSupport.updateTitles(EditorSupport.java:162) at org.openide.text.EditorSupport$Del.updateTitles (EditorSupport.java:664) at org.openide.text.CloneableEditorSupport.notifyModified (CloneableEditorSupport.java:930) at org.openide.text.EditorSupport$Del.superNotifyModified (EditorSupport.java:628) at org.openide.text.EditorSupport.notifyModified (EditorSupport.java:443) at org.netbeans.modules.java.JavaEditor.notifyModified (JavaEditor.java:535) at org.openide.text.EditorSupport$Del.notifyModified (EditorSupport.java:616) at org.openide.text.CloneableEditorSupport$Listener.removeUpdate (CloneableEditorSupport.java:1348) at javax.swing.text.AbstractDocument.fireRemoveUpdate (AbstractDocument.java:228) at org.netbeans.editor.BaseDocument.fireRemoveUpdate (BaseDocument.java:895) at org.netbeans.editor.BaseDocumentEvent.undo (BaseDocumentEvent.java:198) at org.netbeans.editor.GuardedDocumentEvent.undo (GuardedDocumentEvent.java:41) at javax.swing.undo.CompoundEdit.undo(CompoundEdit.java:48) at org.netbeans.editor.BaseDocument$AtomicCompoundEdit.undo (BaseDocument.java:1269) at org.netbeans.editor.BaseDocument.breakAtomicLock (BaseDocument.java:959) at org.netbeans.editor.BaseDocument.runAtomicAsUser (BaseDocument.java:780) at org.netbeans.editor.GuardedDocument.runAtomic (GuardedDocument.java:217) at org.openide.text.NbDocument.runAtomic(NbDocument.java:295) at org.openide.text.PositionBounds.setText(PositionBounds.java:108) at org.netbeans.modules.java.JavaEditor$GuardedSection.setText (JavaEditor.java:1448) at org.netbeans.modules.java.JavaEditor$SimpleSection.setText (JavaEditor.java:1536) ... < snip > ... at zkx.ZkBeanX1BeanInfo$ZkCustomizer.access$001 (ZkBeanX1BeanInfo.java:374) at zkx.ZkBeanX1BeanInfo$1.actionPerformed(ZkBeanX1BeanInfo.java:390) at javax.swing.AbstractButton.fireActionPerformed (AbstractButton.java:1450) ... You see the custom user class with read permission on the call stack leading into AccessControlException because write permission is required. I have already workarounded both problems, so it should work in 3.3.1, however I would like if somebody looked at 1) and 2) whether the described behaviour is really intended and correct.
I have good news for Russel: the bug seems fixed both in [dev] and [release33]. So the fixed version should appear next week as NetBeans 3.3.1 RC1. Please check this version and report back if the problem persist. According to Tomas' suggestion I am reassigning to a person who migth know more about InstanceSupport and about the classloader it uses for laoding the instances. For Petr: if everything is Ok I recommend to mark this issue as fixed. It at least works for me for [dev] and [release33] build.
Sounds good, I'll look for the soluton next week. Is it likely that all restrictions on custom property editors will be dropped, or will the soluton be simply to add read/write file access? Seems to me that a custom editor should be trusted implicitly, since the end-user has already chosen to install the 3rd party components.
*** [FFJ CUSTBUG] bug was entered by external partner ***
Fixed in form editor.
verified
This issue had *2 votes* before move to platform component