Re: [Jython-dev] [Bug #122610] SecEx in MS applerviewer

[<bc...@wo...>]

[Samuele Pedroni]

>I have partially tracked it down.
>Writing the patch I made the assumption (without checking the code: very =
>bad ;) ) that sys.path is set to []
>in the frozen code case. This is false in general.=20
>But there are also other related/similar potential bug in the =
>preexistent code.
>There is also a bug in jythonc which passes a null frozenPackage param.

A null frozenPackage parameter seems to occur when a module was compiled
without the --deep option. My interpretation of the meaning of "frozen"
and "--deep" goes like this:

1) Using --deep (which results in Py.frozen == true) we can assume 
   a completely closed environment. Every external module and package
   have been found by the compiler so there should be no need to search
   the filesystem for anything.

2) Module that have been compile without the --deep option should be
   importable and runnable as if they were compiled by CodeCompiler.
   Such modules are compiled but they are not frozen. F.ex when running
   such a module directly it should attempt to build the cache/packages
   and should search the file system for modules and classes.

The 2) type of compilation is not supported very well at the moment. The
cache/packages dir is created, but no .jars are cached because jythonc
passes these properties to runMain():

    python.packages.paths = ""
    python.packages.directories = ""

which creates a strange enviroment where java classes can't be found in
submodules.

Perhaps we should have an additional options to jythonc, say "--depend"
which will track dependencies and compile all submodules but which does
not set the Py.frozen flag.

regards,
finn