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.
The following code result in a AccesControlExcetion # DynamicJava file - http://www.inria.fr/koala/djava/ System.out.println("Example script"); // Place the script in the package p. package p; public class C { public C() { System.out.println("C created"); } } // Place the script in the anonymous package. package; import p.*; // Create an instance of p.C new C();
Created attachment 4005 [details] This is the ide.log file
This seems to be a classloader issue. When setting the netbeans option -J-Dnetbeans.security.nocheck=true in the ide.cfg, then the exception changes (see below). Maybe someone better in debugging netbeans can use this info, to get it fixed or check if this is a classloader issue in the current ClassLoader of DynamicJava. Also tested with removing the setting of the fs classpaths, but the result is the same. ue Jan 08 16:07:06 CET 2002: java.lang.NoClassDefFoundError: koala/dynamicjava/interpreter/TreeInterpreter java.lang.NoClassDefFoundError: koala/dynamicjava/interpreter/TreeInterpreter at p.C.<init>(Unknown Source) at java.lang.reflect.Constructor.newInstance(Native Method) at koala.dynamicjava.interpreter.context.GlobalContext.invokeConstructor (GlobalContext.java:533) at koala.dynamicjava.interpreter.EvaluationVisitor.visit (EvaluationVisitor.java:649) at koala.dynamicjava.tree.SimpleAllocation.acceptVisitor (SimpleAllocation.java:71) at koala.dynamicjava.interpreter.TreeInterpreter.interpret (TreeInterpreter.java:105) at org.netbeans.modules.scripting.DynamicJavaScriptType.eval (DynamicJavaScriptType.java:138) at org.netbeans.modules.scripting.AbstractScriptType.eval (AbstractScriptType.java:93) at org.netbeans.modules.scripting.AbstractScriptType.exec (AbstractScriptType.java:148) at org.netbeans.modules.scripting.AbstractScriptType.exec (AbstractScriptType.java:161) at org.openide.execution.ScriptType.exec(ScriptType.java:95) at org.netbeans.modules.scripting.ScriptUtils$3.run (ScriptUtils.java:143) [catch] at org.netbeans.core.execution.RunClassThread.run (RunClassThread.java:118)
I wonder how do we check that if the problem is on Netbeans' or Dynamic java's side? have you tried to run your simple example without the IDE?
The example specified in this message also has been tried with the dynamicjava gui provided in the jar file. It executes fin in there. The difference of course is that the base classloader of the gui app is the System classloader and the base classloader of netbeans is a netbeans core one.
lowering priority, since no data gets lost/corrupted.
Please approve this bug as 3.3.1 waiver, for the following reasons. 1. The bug was reported last week, even though it must have been in the module since the beginning. 2. There's not apparent solution to the problem and even the investigation of the causes of the bug can take a fair amount of time. I think I can't come up with a solution before the 3.3.1 release.
approved waiver
Waiver approved by QA.
approved
Waiver approved.
here is my analysis of the problem (big thanks goes to P. Nejedly here) there's the Netbeans systemclassloader, one of it's children is the Scripting's module classloader which loads the dynamic java classes as well. dynamic java itself however uses another, it's own classloader for execution. It's parent is not set in the dynamic java directly but rather in the default java.lang.ClassLoader() constructor where the parent is assigned the systemclassloader. (because djava doesn't provide a parent itself). Thus the scripting module's loader is skipped and not taken into account.. that's why we get the CNFE on koala/dynamicjava/interpreter/TreeInterpreter..
reassigning
the problem cannot be fixed from the Netbeans side. At least I didn't find a way, however it's quite straight forward to fix in the dynamic java sources (that's where the bug actually is IMHO) just add this line to the constructor of the koala.dynamicjava.interpreter.TreeClassLoader.java class: super(i.getClass().getClassLoader()); that will set the right parent for the dynamic java classloader. Then it'll work for Netbeans ok. I've tried with latest sources of dynamic java, please note that I had to rename the dynamicjava.jar to djava.jar and move it to netbeans's modules/ext directory in order to run with netbeans. The condition with starting netbeans with the command-line switch -J-Dnetbeans.security.nocheck=true still applies. I'll try to contact the author of dynamic java and will send him my patch.
*** Issue 24395 has been marked as a duplicate of this issue. ***
I append a patch to DynamicJava which allows to circumvent the exception reported by Nicolai Marck in his first posting to this issue without changing the Netbeans policy. The exception is thrown because a class loader shall be created from code, in the call chain of which appears a class generated by DynamicJava (the class `C' in Nicolai's example). The standard Netbeans ide.policy grant class loader creation permissions only to code in the Netbeans and JDK directories. Adding grant { permissions java.lang.RuntimePermission "createClassLoader"; }; would solve the problem, but for the cost of security problems. The best solution is to create the class loader in privileged code. This is done in the patch appended. When applying the patch it is not necessary to make any changes to the standard Netbeans security settings. The first exception won't be thrown any more. Note: The line numbers in the patch do not correspond to the line numbers of the djava sources, because I additionally made other changes not included in the patch. But this shouldn't be a problem.
Created attachment 6083 [details] Patch of djava TreeClassLoader class.
Hello, Holger. Thanks for the patch. The sources to dynamic java are out of scope of the Netbeans.org project. Please submit the patch to the author of dynamic java. Thanks a lot.
I know that the sources of djava are outside of Netbeans. Nevertheless I (maybe erroneously) feel that the djava author does not react to patches, hence I use this place to store them for later reuse by whoever wants to use them. So please excuse me filing one (last) patch to djava. The previous patch was restricted insofar as it allows to create classes but not to access their members. The patch which follows solves all problems and is really an enhancement worth to apply. (I will send it to the djava author, too.) It assigns to all classes defined in djava scripts a code base "http://koala.ilog.fr/djava/javadoc/koala/dynamicjava/interpreter/TreeClassLoader.html". This value can be overriden by setting the System property "koala.dynamicjava.interpreter.TreeClassLoader.codesource.url". One needs only to add the following entry to the policy file to solve all problems: grant codeBase "http:/koala.ilog.fr/djava/javadoc/koala/dynamicjava/interpreter/TreeClassLoader.html" { permission java.security.AllPermission; };
Created attachment 6099 [details] final patch to TreeClassLoader.java
[Without knowing all the details of this bug, just off-the-cuff comments:] I'm not sure whether setting a special code source is strictly necessary. When I have had problems that sound like this one in the past, all that is needed is to grant AllPermission (e.g.) to the loaded classes. See for example Module.OneModuleClassLoader.getPermissions(CodeSource) in core/src/org/netbeans/core/modules/Module.java in the NB source code. DJava itself is presumably trusted because it is loaded as a module extension. Therefore it is permitted to grant any permissions to classes loaded from classloaders it creates. It might grant AllPermission. Or it might (as here) just set a code source and permit the application developer to configure permissions for that code source as they like - more appropriate when you are not sure to what use the loaded code might be put. At any rate, thank you for taking the time to write up a patch, but we can't really do anything with it here. I see that you have already filed a patch request on SourceForge (see URL). I would suggest you actually attach your last diff to the S.F. patch report. Let's hope it (or something like it) gets accepted on that project and incorporated into a release, which we can then pick up.
Hi Jesse, The patches are applied to the djava sources. Is that what is needed for their integration into Netbeans or shall I ask Stephane to roll a new jar ? >From: "Stephane Hillion" <shillion@ilog.fr> >To: "Holger Krug" <hkrug@rationalizer.com> >Subject: RE: djava patch solving security problems > >I applied the two patches you sent to me to the DynamicJava sources >at sourceforge.org. >Thanks. I reopened the issue, because the new djava jar (either self-made or official) should replace the old one and either: -Dkoala.dynamicjava.interpreter.TreeClassLoader.codesource.url=SOME-OF-NETBEANS'-TRUSTED-CODEBASES added to `runide.sh' or: # permissions for generated djava classes, necessary for users of # the djava scripting engine grant codeBase "http:/koala.ilog.fr/djava/javadoc/koala/dynamicjava/interpreter/TreeClassLoader.html" { permission java.security.AllPermission; }; added to `ide.policy'. I would prefer the latter.
I'd rather have a new official version. I've check the webpages od djavaand the last version is 1.1.4 that came out on 19/03/2001. With new version out that includes your patch we have a more transparent process and can give users an idea what we are using. (saying "we use 1.1.5" is better then "well, we got a patched 1.1.4 that comes from CVS sources from 15/jul/2002") Once it gets out it's no problem to have it included in the external binaries.
I sent an email to Stephane Hillion, the djava developer.
djava 1.1.5 is now officially available. See http://koala.ilog.fr/djava/ and especially http://koala.ilog.fr/djava/DynamicJava.zip. Please add it to the external binaries and make the aforementioned changes either in `runide.sh' or (preferably) in `ide.policy'. That's all. Many thanks for your cooperation !
ok, I've initiated the process to have the new jar in the external binaries. (There's paperwork involved.. :( ) Once i get the approval I'll commit the change.
the dynamic java 1.1.5 is now part of the trunk external binaries. the patch to ide.cfg commited. Thanks a lot, Holger.