Re: [Jython-dev] Re: Using Jython with Java Web Start

[Samuele P. <ped...@bl...>]

> > It isn't general enough and it doesn't work.
> >
> > It can only import top-level modules. Modules in packages can't be
> > imported. That can be fixed by enabling the snippet in PyModule that is
> > commented out.
> >
> 
> Uncomment? :)

:) I commented out that code and at that time the feature
 support was already disabled (no cal loadFromClassLoader).
 And this is a sensible
thing as you have seen, more thoughts and code are needed
to support this properly. 
 
> > Other issues with the patch are:
> >
> > - Only support for .py files. That is too slow for a general solution.
> 
> Okay. Would it be hard to get it to load from .class files as well? Or
> is that not the issue?

The problem here is that there are two choices:
1) loading the $py.class through loadClass
2) load it as a resource (work only with Java 2 unless
 the .class extension is changed to something else)

With 1)  there is no need to create a classloader
and to have the corresponding permissions. OTOH
only 2) allows for class unloading.

For the scenarios I imagine 1) should be just fine.
Then there could be a performance problem
doing trial-and-error through loadClass when
we are loading module classes remotely. 
At least for jythonc produced code there
is a mechanism in place that  deals
with that possible problem, so maybe we need
to replicate that mechanism (which means
you have to explicitly list the py modules in
your jar) in this new context,
although is probably just a Java 1.1
issue (pre jar caching).

All solutions are OK for me, but 
the combinations we want to support should
be chosen.

> > - Setting __path__ to None to signal classloader is probably OK for a
> >   specialized solution, but we have to come up with something more
> >   general.
> > - The classloader is hardcoded. Eventually a user want to put the python
> >   modules into a .jar loaded by another classloader.
> >
> 
> Agreed. My main motivation is to be able to create a jython jar with
> the python modules in it and carry that around as a complete unit.
> I just want to be able to go java -jar jython.jar and in this case 
> everything is in the system classloader.
> 
> The problem I wanted to solve is now solved with -Dpython.path 
> /path/to/jar/python/subpath command-line option.  Perhaps that
> option was always there, but it's not obvious (better now that
> the ! was replaced with a /). Anyway, it unfortunately does not
> solve Duane's problem.
> 
> > All in all, more though have to go into this. We also want to
> > restructure the "imp" code a bit. At the moment a lot of logic is
> > duplicated in loadFromZipFile and loadFromPath. The loadFromClassLoader
> > method will eventually contain the same logic one more time.
> >
> > I understand the desire for this feature, I just don't think we are able
> > to add it the Right Way in version 2.1.
> >
> 
> I'm glad to hear that you understand the desire for the feature!
> 
> >
> > Instead we could maybe make the loadFromClassLoader() method public and
> > suggest that embedding user temporarily use the hack below to load
> > python modules from their classloader. The hack must be explicit enabled
> > with a call like this:
> >
> >     org.python.util.ClassLoaderImport.install()
> >
> > Comments?
> >
> 
> First, if I understand the code correctly, the classloader would take
> precedence over the python.path. Since the python.path is specific
> to python, IMO python.path should take precedence over the 
> classloader for loading python modules. I.e. you 
> should try to delegate to the importer before trying the classloader.
> [There should probably be a registry setting for this!]
> 

IMHO it is a sensible thing for the classloader to take over
sys.path in this case. Sys path in some occasion should even
be ignored. It makes also sense wrt to Java behavior:
java -jar  ignores the classpath!.

> As to which classloader to use, I agree with you that it is bad
> to have the classlader hardcoded to imp's classloader. In 
> java 2 environments maybe some combination like, try
> the context classloader, then the system classloader, then
> imp's classloader, would work. I haven't thought through the
> proper order. Probably it should be configurable. 
> 
> I'd like to be able to enable the hack from the registry. Then, if I 
> read the documentation on the registry correctly, you could
> add a registry to jython.jar with the appropriate property enabled
> and you're away. The property name could be 'allowImportFromClassloader'
> and there could be related properties like 
> 'classloaderImportPrecedence=context,system,class'.
> 
> I realize I'm suggesting a lot of registry settings and I have no
> idea how much work this would be. But I would say that
> if adding these settings is too much for 2.1, then 
> just leave classloading until until there is time to do it right. 

Given the input from other people it seem that we should
be able to deal with defaults and also arbitrary new classloaders,
 at least
for java classes (unrelated) but then also for py modules
to have a coherent picture.

[Also the role of sys.classLoader should be considered,
and when sys.path defaults to empty or is ignored.]

> Thanks, finn, for taking an interest in this issue! 

We have always been interested in this issue,
although I admit quite silently <wink>.

regards, Samuele Pedroni.