From: Ian Clarke <ian@lo...> - 2004-01-28 15:54:44
> I'm sure this is doable, if you use a ClassLoader with BeanShell that
> enforces your logic.
Yes, I have investigated this and it seems doable - however I am
concerned that it may not quite meet my needs.
Consider if, for example, I wanted to deny the shell user direct access
to System.println(). I could have my ClassLoader prevent the direct
loading of the System class quite easily.
Consider now that I provide the user with a utility class -
Sandbox.printNumber() which they are to use to print a number, it would
use System.println() internally.
The problem is that, if I understand it correctly, the ClassLoader would
also limit what calls can be made within the Sandbox.printNumber()
method since ClassLoaders appear to be "inherited" by methods of the
classes they load.
Is my interpretation correct and if so can anyone think of a way around it?
As an aside, is there any easy way to suppress or replace the "BeanShell
2.0b1.1 - by Pat Niemeyer (pat@...)" text printed to the console in
interactive mode? It isn't my intention to deny Pat the credit that is
due to him, but I would prefer to have some control over the manner in
which I give it without mangling his code :-)
From: Shankar Unni <shankar@co...> - 2004-01-28 19:10:05
> Consider if, for example, I wanted to deny the shell user
> direct access to System.println(). I could have my
> ClassLoader prevent the direct loading of the System class
> quite easily.
> Consider now that I provide the user with a utility class -
> Sandbox.printNumber() which they are to use to print a
> number, it would use System.println() internally.
Ooh, yuck. You'd have to have your special beanshell classloader delegate to
a more normal one. That way, once your classloader (which acts as a
gatekeeper) approves "Sandbox", the actual load request is sent to a more
normal parent classloader, which loads it. Now when Sandbox refers to
System, it's the parent classloader that resolves it.
(If I understand the structure correctly, interpreter.setClassLoader() sets
the classloader used to resolve references directly in *user* code; once a
class is actually loaded, any references from within it are resolved by
I think. I'm starting to wave my hands wildly here :-) - I think some
experimentation may be needed here..