From: <bc...@wo...> - 2000-12-01 17:18:02
|
[Boudewijn Rempt] >Well, thanks to all the help I've succeeded in getting the >Console.py compiled in to a jarfile, and I can call the code from my >application. However, the app uses the java.security features, and it >appears that the Jython BytecodeLoader classloader is wreaking havoc in >the subtle scheme of security. >... >Class: class org.python.proxies.Action$Action$0 > ClassLoader: org.python.core.BytecodeLoader@61dadb > CodeSource: (null <no certificates>) > Permissions: java.security.Permissions@24c414 ( >Which appears not to come from any jarfile, which means that it can't >be signed - which means that the secureClassLoader chokes on it. We couldn't >find the origin of proxies.Action, anyway. The org.python.proxies.Action$Action$0 class is a dynamicly generated class, created because the static jythonc compiler failed to detect that the Action class in Action.py is subclassing a java class. Try changing the Action.py file like this: --- Action.py.org Wed Feb 24 15:45:27 1999 +++ Action.py Fri Dec 01 17:53:37 2000 @@ -1,5 +1,5 @@ # I don't really like the design of this one... -from pawt import swing +from javax import swing class Action(swing.AbstractAction): The "pawt" module is a clever and dynamic way to detect the name of the swing package, much to clever for jythonc. When jythonc failes to create a proxy for swing.AbstractAction at compile time, jython will instead create it at runtime. regards, finn |