Issue1340
Created on 2009-05-06.21:39:39 by fisherja, last changed 2009-05-11.19:25:45 by zyasoft.
msg4648 (view) |
Author: Jake fisher (fisherja) |
Date: 2009-05-06.21:39:37 |
|
Problem:
There is no way to get a complete unique PySystemState object such that
we can have separate concurrent sets of modules/packages etc running at
once. The initialize methods are mostly statics that assume Base
Properties, cache directories, etc are shareable and not per SystemState
specific. For one Jython.jar then we don't have a way to run multiple
concurrent JythonInterpreters with their own SystemStates safely as the
PySystemState shares to many static fields and methods. Also from a
perspective of managing state it would be great to have more accessor
methods available for reloading and updating modules etc.
Background:
We are currently using Jython integrated in an Eclipse RCP application
where we require a individual separate System State for each project.
This is so that we can have multiple versions of modules etc and java
packages that are per Project specific. We were sort of able to
accomplish what we need using the current implementation as far as
modules go but there are is no way to override / add other properties in
particular we need a separate cache directory for each project.
|
msg4649 (view) |
Author: Jake fisher (fisherja) |
Date: 2009-05-06.22:25:52 |
|
Also it would be great to not compile classes to the same directory as
the .py file
|
msg4661 (view) |
Author: Jim Baker (zyasoft) |
Date: 2009-05-08.18:59:20 |
|
Have you tried using PySystemState#shadow? This is for the purpose of
working around the use of statics, specifically builtins, warnoptions,
and platform. (Unfortunately we won't be able to make breaking API
changes in modules like PySystemState until 3.x.)
PySystemState.modules is an instance variable, so that should also work
for you.
You can see a moderate exercise of this is in test_sys_jy.py,
specifically the test case ShadowingTest.
Note that this bug is related to #471481, #1868602, and #607391.
|
msg4670 (view) |
Author: Jim Baker (zyasoft) |
Date: 2009-05-10.20:08:49 |
|
Changing to pending, since this issue should have been resolved by
earlier fixes re shadowing and correct instantiation of PySystemState,
as explained in my last message.
However, this issue is complex enough that we definitely want to know if
that's the case for this particular usage.
|
msg4672 (view) |
Author: Jim Baker (zyasoft) |
Date: 2009-05-11.19:25:43 |
|
Closing until further notice.
|
|
Date |
User |
Action |
Args |
2009-05-11 19:25:45 | zyasoft | set | status: pending -> closed messages:
+ msg4672 |
2009-05-10 20:08:50 | zyasoft | set | status: open -> pending priority: normal resolution: works for me messages:
+ msg4670 |
2009-05-08 18:59:21 | zyasoft | set | nosy:
+ zyasoft messages:
+ msg4661 |
2009-05-06 22:25:52 | fisherja | set | messages:
+ msg4649 |
2009-05-06 21:40:46 | fisherja | set | title: PySystemState does provide constructor to pass its own local postProperties -> No way to get a complete unique PySystemState object for concurrent environments |
2009-05-06 21:39:39 | fisherja | create | |
|