From: Finn Bock <bckfnn@...>
> [George York]
> > Inside an EJB you are not allowed to do the following (among other things):
Btw that's section 25.1.2 of EJB 2.1 spec (downloadable from Sun). It's a bit
vague, because is about donts and not security permissions not granted .
Concretely some of the restrictions are/can be enforced by the container in
terms of not granting or granting java security permissions, for that see
section 25.2.1. Also the rationales in 25.1.2 can help to make things clearer.
> > write to static members
you cannot assume e.g. that all the instances of a Session Bean will run in the
same JVM, so they cannot "communicate" through static members. This does not
extend directly to the Jython runtime (there would be one for each JVM),
although if/how persist (part of) Jython runtime state, depending on how Jython
is used, is a design issue.
> I'm not sure what that restriction mean.
> > use thread synchronization
you cannot coordinate beans instances just through java synchronization for the
same reason as above. E.g. you cannot just use it to serialize access to some
external resource ...
> Does that mean that we can't start new treads?
yes, thread manipulation is also prohibited
> That is ok, we don't
> (except for weakrefs but let us ignore that).
> > use java.io.* to access the file system
> That isn't too hard to fixed.
> > create a classloader
it's the typical security related restriction.
You cannot also ask for the classloaders that are not yours or a descendant.
> Jython needs a classloader when:
> 1) calling eval, exec and compile.
which means also PythonInterpreter usage in general.
> 2) When importing a module and the $py.class file is out-of-date.
> 3) For proxies whenever we subclass java class and/or interface.
> 4) For adapters whenever we get or set a bean-event-property
> (like actionPerformed in swing)
> Saying that 1) doen't work in EJB is fine I think.
Are you sure ?<.5 wink> I would think that exec-like functionality could be the
strong reason to want to use some kind of scripting enviroment.
For sure to make that work, we would need a pure (non-to-bytecode-compiling)
interpreter. Then one cannot subclass Java classes, up eventually using
java.reflect.Proxy (there since Java 1.3 and it's unclear if EJB restrictions
apply to it)
which btw allows only to implement interfaces and not subclassing classes.
> Saying that the
> $py.class must be precompiled and added to a jar that is available for
> classloading is also ok.
> To solve 3) and 4) the proxies and adapters must also be precompiled and
> stored in the .jar file and that is a bit harder. The proxies are
> compiled when the 'class' statement is executed and the adapters are
> created when the bean property event is refrenced (_doget/_doset). In
> both cases, this is only done at runtime when the program is executed.
> It should be noted that methods defined in the proxies classes depends
> on which methods that are overridden in python. The adapters depends
> only on the java class.
> Analysing the class statements and creating proxies and adapters
> *without* running the application is what jythonc does.
yes, once 1 is not a target, jythonc should do more/or less all is needed.
Other approaches, as you have described, are conceivable too.