From: Josselin P. <jos...@sc...> - 2001-12-07 14:21:25
|
Hello S=E9bastien, I have been running into the same kind of problems, they seem to come fr= om the separation of the jython classloader and the app classloader. The jython classloader is -logically- defined at PythonIntrepreter class= (and not instance) loading: the classloader that loads jython.jar... if your app uses another classloader you get this kind of bugs ! (MY problems come from the weird tomcat 4 classloader hierarchy...) Passing the Class objects to jython works if you really need to keep separate classloaders myPythonInterpreter.set("classNameAlias",fullyQualifiedJavaClassName); myPythonInterpreter.exec("newObject=3DclassNameAlias()"); I just tested it, it works... this may be enough for a few classes where you may not need to really "import" the class... I will look at the jython sources and see if it would be hard to have PythonInterpreters with separate classloaders but to share the jython classes... maybe multiple package caches... I fear it would be quite com= plex and that I will fallback to multiple instances of jython, but I will try= :-) Hope that helps, Josselin -I am the master of tortured and distorted English- |
From: Samuele P. <ped...@bl...> - 2001-12-07 16:45:15
|
> > I will look at the jython sources and see if it would be hard to have > PythonInterpreters with separate classloaders but to share the jython > classes... maybe multiple package caches... I fear it would be quite complex > and that I will fallback to multiple instances of jython, but I will try :-) > > Hope that helps, > There is already a per PySystemState classloader, so - you should extend its usage in the codebase to cover cases different from applets/single jar deployment (it is its main usage now). This is a long-standing but low-prio todo of mine. - allow per PySystemState packageManagers and deal with multiple/single package caching issues => this would probably mean refactoring code RESULT: then you can construct PythonInterps with PySystemStates using your favourite classloaders. QA: check that the design is sound and you are not breaking something. This seems (at least now) a reasonable but involved plan, but only implementation can tell the final word. regards, Samuele Pedroni. |
From: Josselin P. <jos...@sc...> - 2001-12-08 13:07:38
|
Hello, Le vendredi 7 d=E9cembre 2001, =E0 05:41 , Samuele Pedroni a =E9crit : > >> >> I will look at the jython sources and see if it would be hard to have >> PythonInterpreters with separate classloaders but to share the jython >> classes... maybe multiple package caches... I fear it would be quite=20= >> complex >> and that I will fallback to multiple instances of jython, but I will=20= >> try :-) >> >> Hope that helps, >> > > There is already a per PySystemState classloader, so > Yes, I found out about that, it solves a big part of my problem... > - you should extend its usage in the codebase to cover > cases different from applets/single jar deployment > (it is its main usage now). The jython "registry" system seems to fulfill this role in the=20 single-python-path-context. (Python compatibility mode ???) > This is a long-standing but low-prio todo of mine. > - allow per PySystemState packageManagers > and deal with multiple/single package caching issues > =3D> this would probably mean refactoring code > Yes, from what I have seen, it would mean refactoring a whole lot of=20 code ! I can really see how it can be low priority ;-) Moreover, I think that the python module system could not cope in a=20 general way with convoluted ClassLoading systems (encrypted or network=20= classloaders, other JVM languages ...) My (temporary) conclusion is that for multi-classloader apps, it should=20= be the responsability of the app developper (in this case me !) to=20 register his packages into jython, automatic discovery by the jython=20 system seems to attain limits here. > RESULT: then you can construct PythonInterps > with PySystemStates using your favourite > classloaders. > Works pretty well, for single-app system, add_extdir() and=20 add_classdir() cover most problems in my app... Except package=20 information leakage between classloaders. > QA: check that the design is sound and > you are not breaking something. > This seems (at least now) a reasonable but > involved plan, > but only implementation can tell the final word. > See above, I do not believe a general implementation possible with JVM=20= Reflection (but it would be hackable to manage already loaded classes... is it=20 useful ?). A complex-embedding-howto will come out of this, I promise... but in my=20= bad english :-( > > regards, Samuele Pedroni. > > Thanks a lot for your support, Josselin Pujo - Master of tortured English - > _______________________________________________ > Jython-users mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-users |
From: Samuele P. <ped...@bl...> - 2001-12-08 14:20:47
|
[Josselin PUJO] > > > There is already a per PySystemState classloader, so > > > > Yes, I found out about that, it solves a big part of my problem... > > > - you should extend its usage in the codebase to cover > > cases different from applets/single jar deployment > > (it is its main usage now). > > The jython "registry" system seems to fulfill this role in the > single-python-path-context. > (Python compatibility mode ???) I don't see the relation, the "its" meant "of the per PySystemState classloader" > > This is a long-standing but low-prio todo of mine. This was about "you should extend ..." > > - allow per PySystemState packageManagers > > and deal with multiple/single package caching issues > > => this would probably mean refactoring code > > > Yes, from what I have seen, it would mean refactoring a whole lot of > code ! Yup, it is really low-priority, even more than the point above :) > I can really see how it can be low priority ;-) > Moreover, I think that the python module system could not cope in a > general way with convoluted ClassLoading systems (encrypted or network > classloaders, other JVM languages ...) > My (temporary) conclusion is that for multi-classloader apps, it should > be the responsability of the app developper (in this case me !) to > register his packages into jython, automatic discovery by the jython > system seems to attain limits here. This is of course true, the Java API does not allow to ask a classloader its set of candidate packages for loading :( but the problem here is about telling jython to search a set of classloaders when importing. A different one. Further in this context jreload package that comes with Jython and some natural extensions to it could play a role too. > > RESULT: then you can construct PythonInterps > > with PySystemStates using your favourite > > classloaders. > > > Works pretty well, for single-app system, add_extdir() and > add_classdir() cover most problems in my app... Except package > information leakage between classloaders. That's why the clean way would be multiple package managers. > > > QA: check that the design is sound and > > you are not breaking something. > > > This seems (at least now) a reasonable but > > involved plan, > > but only implementation can tell the final word. > > > > See above, I do not believe a general implementation possible with JVM > Reflection yup/nope. Things could get better but it's a matter of *time* > (but it would be hackable to manage already loaded classes... is it > useful ?). > A complex-embedding-howto will come out of this, I promise... but in my > bad english :-( > Let us know. We could put it somewhere and check it (not so much for english ;) ) regards, Samuele Pedroni. |