Re: 3.2
MODPYTHON-34 has been fixed in the current version of the publisher, with the new importing system. As I've written before, I can roll back the part regarding the import system if you really want that, all the while maintaining the fix for MODPYTHON-34. Regards, Nicolas2005/7/29, Graham Dumpleton [EMAIL PROTECTED]: Sorry, getting a bit overwhelmed with all these rapid changes in stateof things as bit busy today. Will probably will only know what is goingon when I look at latest code in repository. Then I'll probably pipe in with some more pertinent comments about 3.2.One report I would like to get some confirmation about is:http://issues.apache.org/jira/browse/MODPYTHON-34 This was about a potential security hole. Nicolas has indicated thatchanges he had been working on which involved a different moduleloader addressed it, but if various things are getting pushed to 3.3, is then this addressed or not in what would make it to 3.2?Since it was security related, just wanted to highlight it even ifexposure risk is low.BTW, did anyone see an issue with my proposal for making the req.path_info attribute writable. Ie.,http://issues.apache.org/jira/browse/MODPYTHON-67I have been working on some code which would depend on such a change and the code is of a nature that I think would be a nicecandidate for rolling back into the mod_python core. If path_infowas writable in 3.2, would allow people to experiment with the codeI am working on, or even turn it into a common project, without needing to patch the mod_python source code.I know Jim gave a +1 for path_info to be writable.GrahamJim Gallacher wrote .. Jim Gallacher wrote: Gregory (Grisha) Trubetskoy wrote: On Thu, 28 Jul 2005, Nicolas Lehuen wrote: Note that there are 29 unscheduled issues : http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolutionIds=-1pid=10640fixfor=-1 Maybe some of them should be included in the 3.2 release ? My inclanation is to just release whatever we have, and mark it as a beta release. The last true release was 3.1.3 in Feb 2004, which makes it 18 months (if my math is correct) Grisha I've either commited fixes or have fixes ready for 6 or 8 of those issues. Also there some that don't apply to 3.2 (eg website or mailing list issues). Must run right now but will make a list this evening of issues which can be closed. Jim Here is my list. I think you can close all of these JIRA issues except MODPYTHON-52. http://issues.apache.org/jira/browse/MODPYTHON-45 Implement a file-based session manager Resolved but waiting for documentation. Working on it now - will commit in the next 12 hours. http://issues.apache.org/jira/browse/MODPYTHON-58 _apache._global_lock results in segfault when index number of mutexes Fix has been commited http://issues.apache.org/jira/browse/MODPYTHON-62 local_ip and local_host in connection object returns remote_ip and remote_host instead This issue only applies to 3.1.4. It's already been fixed in 3.2. http://issues.apache.org/jira/browse/MODPYTHON-65 3.2 working version will not install on Mac OS X ( 10.3.7) Fix has been commited. http://issues.apache.org/jira/browse/MODPYTHON-66 install_dso target also tries to install Python code files Fix has been commited. http://issues.apache.org/jira/browse/MODPYTHON-59 Add get_session() method to request object Let's defer this to 3.3. I've changed current implementation to raise a NotImplemented error. Related to get_session, I've made a small change to Session.Session(). It now checks PythonOption session for the default session type before using the hard coded default. For reasons that escape me I put this in a separate function, create_session(), but it really belongs in Session(). This is useful outside of get_session, so I've kept the change for 3.2. Regards, Jim
[jira] Updated: (MODPYTHON-59) Add get_session() method to request object
[ http://issues.apache.org/jira/browse/MODPYTHON-59?page=all ] Nicolas Lehuen updated MODPYTHON-59: Fix Version: 3.3.0 Version: 3.1.4 3.1.3 3.2.0 (was: 3.3.0) Add get_session() method to request object -- Key: MODPYTHON-59 URL: http://issues.apache.org/jira/browse/MODPYTHON-59 Project: mod_python Type: New Feature Components: core Versions: 3.1.4, 3.1.3, 3.2.0 Environment: All Reporter: Jim Gallacher Fix For: 3.3.0 Attachments: Session.py.diff.txt Users will get session instances by calling req.get_session(). If a session already exists it will be returned, otherwise a new session instance will be created. Session configuration will be handled using apache directives rather than within their code. Using this scheme means only one session instance will be created per request, which will eliminate the deadlock problems many people experience. Also, using this scheme makes it possible for sessions to be properly handled within psp pages and across req.internal_redirect() calls. Code will be commited to svn shortly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MODPYTHON-65) 3.2 working version will not install on Mac OS X (10.3.7)
[ http://issues.apache.org/jira/browse/MODPYTHON-65?page=all ] Nicolas Lehuen resolved MODPYTHON-65: - Fix Version: 3.2.0 Resolution: Fixed 3.2 working version will not install on Mac OS X (10.3.7) - Key: MODPYTHON-65 URL: http://issues.apache.org/jira/browse/MODPYTHON-65 Project: mod_python Type: Bug Components: core Versions: 3.2.0 Environment: Mac OS X (10.3.7) Reporter: Graham Dumpleton Fix For: 3.2.0 Attachments: setup.py.in.diff Something is wrong with configure or setup.py file. /usr/bin/python setup.py build running build running build_py running build_ext building 'mod_python_so' extension gcc -Wl,-F. -Wl,-F. -bundle -framework Python build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/mod_python.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/_apachemodule.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/connobject.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/filterobject.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/hlist.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/hlistobject.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/requestobject.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/serverobject.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/tableobject.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/util.o -L -lapr-0 -laprutil-0 -o build/lib.darwin-7.7.0-Power_Macintosh-2.3/mod_python_so.so ld: -L: directory name missing error: command 'gcc' failed with exit status 1 More later when I have a chance to work out what is wrong. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MODPYTHON-71) Support the HEAD method properly
Support the HEAD method properly Key: MODPYTHON-71 URL: http://issues.apache.org/jira/browse/MODPYTHON-71 Project: mod_python Type: Bug Versions: 3.1.4, 3.1.3, 2.7.10, 3.2.0 Reporter: Nicolas Lehuen Priority: Minor RFC 2616, 9.4 HEAD : 8---8---8---8---8--- The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. 8---8---8---8---8--- Could we make sure that nothing is returned to the client ? Perhaps by making sure that req.write does nothing whenever the request method is HEAD ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
mod_python package maintainers - are you out there?
Nicolas Lehuen wrote: Another remark : has anyone suscribed to redhat, debian etc. mailing list to watch for such patches ? Not me. I don't understand why those guys aren't posting their patches on the mod_python mailing list. I was wondering the same thing. What would be better for us, subscribing to a bunch of mailing lists or contacting the maintainers directly and telling them we are interested in having them forward their bug reports and patches (and then hoping they do)? Having some contact with them directly is probably a good idea anyway. Subscribing to a bunch of mailing lists could result in a lot of uninteresting mail. ;) But first let's have a show of hands. How many people monitoring either of the mod_python or python-dev mailing lists are package maintainers for a distribution? Regards, Jim
Re: mod_python package maintainers - are you out there?
On Wed, Aug 10, 2005 at 09:04:04AM -0400, Jim Gallacher wrote: Nicolas Lehuen wrote: I don't understand why those guys aren't posting their patches on the mod_python mailing list. I was wondering the same thing. What would be better for us, subscribing to a bunch of mailing lists or contacting the maintainers directly and telling them we are interested in having them forward their bug reports and patches (and then hoping they do)? With Debian it is generally understood that the Debian users should report bugs to the Debian Bug Tracking System and the package maintainer forwards them to the upstream if the issue is not Debian-specific. Since the mentioned bug is 162 days old in Debian, I should have monitored the bug and as an original submitter I should have taken the issue upstream myself bypassing the package maintainer. Propably the most common reasons why this communication does not happen is that people forget or do not have time (and plan to do it later). Having some contact with them directly is probably a good idea anyway. Subscribing to a bunch of mailing lists could result in a lot of uninteresting mail. ;) I think it would be unfair to expect that upstream developers track all the major distributions. But first let's have a show of hands. How many people monitoring either of the mod_python or python-dev mailing lists are package maintainers for a distribution? I do monitor and I do know Debian packaging but I am not an official developer nor do I maintain official Debian packages. signature.asc Description: Digital signature
Re: 3.2 (import and publisher issues)
Nicolas Lehuen wrote: MODPYTHON-34 has been fixed in the current version of the publisher, with the new importing system. As I've written before, I can roll back the part regarding the import system if you really want that, all the while maintaining the fix for MODPYTHON-34. I haven't had much to say on this topic (because I don't have a solid grasp of all the implications), but it seems like it's a real stumbling block for the release. I'd say if the current changes won't break any current code, or cause users unexpected behaviour, leave them in. Otherwise roll them back. It's better for the user to have to deal with old, documentented issues rather than discover brand new ones in their code, only to find we've changed the behaviour again in 3.3. Whichever route we take, we will obviously work on this further in 3.3 but for now let's get 3.2.0b out the door. Regards, Jim
Re: Few issues with new mod_python.publisher.
Jim Gallacher wrote: Interestingly, section 5.1.1 says that The methods GET and HEAD MUST be supported by all general-purpose servers., so it would seem that mod_python has not been compliant to the RFC. FWIW, the Debian Woody package of mod_python (libapache-mod-python 2.7.8-0.0woody5) running under apache 1.3.26 displays HEAD properly, while a compiled mod_python 3.1.4/apache 2.1.3-beta system does not. Perhaps mod_python underwent a change or Debian already includes a patch for HEAD.
Re: mod_python package maintainers - are you out there?
Juha-Matti Tapio wrote: On Wed, Aug 10, 2005 at 09:04:04AM -0400, Jim Gallacher wrote: Nicolas Lehuen wrote: Having some contact with them directly is probably a good idea anyway. Subscribing to a bunch of mailing lists could result in a lot of uninteresting mail. ;) I think it would be unfair to expect that upstream developers track all the major distributions. But it's easy enough to download their source packages and inspect them for interesting patches every once in a while. I think package maintainers will respond favorably if their work was acknowledged. Maybe they tried to submit a bug in the past, but couldn't, for some reason.
Re: Using objects to create an explicit hierarchy.
I do not have immediate comment on what you're doing, but I do have a tangential comment: Never having looked at the mod_python.util.fs_apply_data code, your email prompted me to. I noticed that the code uses object as a function argument name. While this works, shouldn't the argument name be changed to obj or something else? While object is not a python keyword it is the name of the superclass of new-style classes. I was very confused reading your sample code below until I realized the overloading. Also, and most annoying, emacs highlights object everywhere in fs_apply_data as a keyword. :-) Not exactly a bug. An obfuscation? Daniel Popowich --- http://home.comcast.net/~d.popowich/mpservlets/ Graham Dumpleton writes: Have a strange patch here for consideration. In CherryPy, one can manually construct the page hierarchy by writing: cpg.root.onepage = OnePage() cpg.root.otherpage = OtherPage() cpg.root.some = Page() cpg.root.some.page = Page() The closest equivalent to this in mod_python is the publisher handler, whereby a URL will be mapped to attributes and member functions of a class. One generally though has to create an actual class to encapsulate all the bits together. One can to a degree with publisher create a mapping without creating a proper class by using: class _Mapping: pass def _method1(): return _method1 def _method2(): return _method2 object = _Mapping() object.onepage = _method1 object.otherpage = _method2 What isn't possible though without creating a real class is have a normal function which is called when the dummy mapping object itself is the target. Ie., following does not work: object.__call__ = _method1 This is because util.apply_fs_data() assumes that __call__() is always an object method. I know this is sort of an abuse of __call__(), but it does actually work in Python itself, just not in mod_python when URLs are mapped to object. class A: ... pass ... def _method(): ... return method ... a=A() a.__call__ = _method a() 'method' Anyway, I have attached a patch which would allow this sort of thing to actually work within mod_python. I feel it could be a useful way of quickly constructing special object hierarchies from other functions, objects and attributes without having to actually create real classes. For example: def _method(): return method class _Mapping: pass _subdir1 = _Mapping() _subdir1.__call__ = _method # .../root/subdir1 _subdir1.page1 = _method # .../root/subdir1/page1 _subdir1.page2 = _method # .../root/subdir1/page2 root = _Mapping() root.__call__ = _method # .../root root.page1 = _method # .../root/page1 root.subdir1 = _subdir1 Comments? Index: lib/python/mod_python/util.py === --- lib/python/mod_python/util.py (revision 231212) +++ lib/python/mod_python/util.py (working copy) @@ -371,20 +371,6 @@ then call the object, return the result. - # add form data to args - for field in fs.list: - if field.filename: - val = field - else: - val = field.value - args.setdefault(field.name, []).append(val) - - # replace lists with single values - for arg in args: - if ((type(args[arg]) is ListType) and - (len(args[arg]) == 1)): - args[arg] = args[arg][0] - # we need to weed out unexpected keyword arguments # and for that we need to get a list of them. There # are a few options for callable objects here: @@ -409,9 +395,27 @@ expected = [] elif hasattr(object, '__call__'): # callable object - fc = object.__call__.im_func.func_code - expected = fc.co_varnames[1:fc.co_argcount] + if type(object.__call__) is MethodType: + fc = object.__call__.im_func.func_code + expected = fc.co_varnames[1:fc.co_argcount] + else: + # abuse of objects to create hierarchy + return apply_fs_data(object.__call__, fs, **args) + # add form data to args + for field in fs.list: + if field.filename: + val = field + else: + val = field.value + args.setdefault(field.name, []).append(val) + + # replace lists with single values + for arg in args: + if ((type(args[arg]) is ListType) and + (len(args[arg]) == 1)): + args[arg] = args[arg][0] + # remove unexpected args unless co_flags 0x08, # meaning function accepts **kw syntax if fc is None: Graham
[jira] Commented: (MODPYTHON-71) Support the HEAD method properly
[
http://issues.apache.org/jira/browse/MODPYTHON-71?page=comments#action_12318388
]
Jim Gallacher commented on MODPYTHON-71:
Apache may already be doing the right thing for us. Using netcat as the client
I ran the some tests using the the following as the handler:
/mp/mptest.py
from mod_python import Session
def handler(req):
req.content_type = 'text/plain'
sess = Session.Session(req)
sess.do_cleanup()
try:
sess['hits'] += 1
except:
sess['hits'] = 0
req.write('mptest.py\n')
req.write('hits: %d\n' % (sess['hits']))
req.write('Blah blah blah blah blah\n')
sess.save()
return apache.OK
Note that the host name has been obscured in these tests.
Test 1.
===
Request
---
GET /mp/mptest.py HTTP/1.1
Host: example.com
Connection: close
Response
HTTP/1.1 200 OK
Date: Wed, 10 Aug 2005 18:58:49 GMT
Server: Apache/2.0.54 (Debian GNU/Linux) mod_python/3.2.0-dev-20050809
Python/2.3.5
Cache-Control: no-cache=set-cookie
Set-Cookie: pysid=0a81c130420c736c10e196e48603cb96; path=/mp
Connection: close
Transfer-Encoding: chunked
Content-Type: text/plain
a
mptest.py
8
hits: 0
19
Blah blah blah blah blah
0
Comments
Netcat just dumps out whatever it receives. The stray a, 8, 19 and 0 are part
of the chunked transfer scheme and can be ignored.
Test 2.
===
Request
---
HEAD /mp/mptest.py HTTP/1.1
Host: example.com
Connection: close
Response
HTTP/1.1 200 OK
Date: Wed, 10 Aug 2005 18:59:04 GMT
Server: Apache/2.0.54 (Debian GNU/Linux) mod_python/3.2.0-dev-20050809
Python/2.3.5
Cache-Control: no-cache=set-cookie
Set-Cookie: pysid=2cc812f1426e5580aaf86904ee41fa3d; path=/mp
Connection: close
Content-Type: text/plain
Comments
Looks like mod_python is doing the right thing. The body of the request is not
being sent to the client.
As long as any publisher methods we create stuff HEAD into the allowed methods
we should be ok wrt the RFC. I'd say that the change Nicolas made in
publisher.py is correct, although
if req.method!='HEAD':
req.write(result)
may not be required if the apache ap_rwrite() call is taking care of it. I'll
dig into the apache code later tonight to confirm this.
Support the HEAD method properly
Key: MODPYTHON-71
URL: http://issues.apache.org/jira/browse/MODPYTHON-71
Project: mod_python
Type: Bug
Versions: 3.1.3, 2.7.10, 3.2.0, 3.1.4
Reporter: Nicolas Lehuen
Priority: Minor
RFC 2616, 9.4 HEAD :
8---8---8---8---8---
The HEAD method is identical to GET except that the server MUST NOT return
a message-body in the response. The metainformation contained in the HTTP
headers in response to a HEAD request SHOULD be identical to the
information sent in response to a GET request.
8---8---8---8---8---
Could we make sure that nothing is returned to the client ? Perhaps by making
sure that req.write does nothing whenever the request method is HEAD ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: 3.2 (import and publisher issues)
I'd like to stress the fact that a lot of issues currently in JIRA are related to the publisher. We have worked on it to solve some of these issues. I have made sure that both the old version and the new version pass a series of unit tests. I can't be sure that those unit tests reflect the whole range of usage patterns people could have of the publisher, but anyway, it's better than nothing. So, I think we should move forward on the 3.2 release. The new publisher code is meant to make it work better, not worse, while retaining the compatibility with the current code. It's not a new publisher, it's a set of bug fixes. I mean, what is the purpose of releasing a new version of mod_python if we don't fix the dozen of bugs that are related to the publisher ? Regards, Nicolas2005/8/10, Jim Gallacher [EMAIL PROTECTED]: Nicolas Lehuen wrote: MODPYTHON-34 has been fixed in the current version of the publisher, with the new importing system. As I've written before, I can roll back the part regarding the import system if you really want that, all the while maintaining the fix for MODPYTHON-34.I haven't had much to say on this topic (because I don't have a solidgrasp of all the implications), but it seems like it's a real stumblingblock for the release. I'd say if the current changes won't break any current code, or causeusers unexpected behaviour, leave them in. Otherwise roll them back.It's better for the user to have to deal with old, documentented issues rather than discover brand new ones in their code, only to find we'vechanged the behaviour again in 3.3.Whichever route we take, we will obviously work on this further in 3.3but for now let's get 3.2.0b out the door.Regards,Jim
Re: 3.2 (import and publisher issues)
Nicolas Lehuen wrote: I'd like to stress the fact that a lot of issues currently in JIRA are related to the publisher. We have worked on it to solve some of these issues. I have made sure that both the old version and the new version pass a series of unit tests. I can't be sure that those unit tests reflect the whole range of usage patterns people could have of the publisher, but anyway, it's better than nothing. So, I think we should move forward on the 3.2 release. +1 The new publisher code is meant to make it work better, not worse, while retaining the compatibility with the current code. It's not a new publisher, it's a set of bug fixes. I mean, what is the purpose of releasing a new version of mod_python if we don't fix the dozen of bugs that are related to the publisher ? Regards, Nicolas 2005/8/10, Jim Gallacher [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Nicolas Lehuen wrote: MODPYTHON-34 has been fixed in the current version of the publisher, with the new importing system. As I've written before, I can roll back the part regarding the import system if you really want that, all the while maintaining the fix for MODPYTHON-34. I haven't had much to say on this topic (because I don't have a solid grasp of all the implications), but it seems like it's a real stumbling block for the release. I'd say if the current changes won't break any current code, or cause users unexpected behaviour, leave them in. Otherwise roll them back. It's better for the user to have to deal with old, documentented issues rather than discover brand new ones in their code, only to find we've changed the behaviour again in 3.3. Whichever route we take, we will obviously work on this further in 3.3 but for now let's get 3.2.0b out the door. Regards, Jim
[jira] Updated: (MODPYTHON-12) ImportError: cannot import name publisher
[ http://issues.apache.org/jira/browse/MODPYTHON-12?page=all ] Graham Dumpleton updated MODPYTHON-12: -- Attachment: package.diff.txt An even simpler test for this problem is to use a publisher function defined as: import mod_python def index(req): from mod_python import publisher req.content_type = 'text/plain' return index %r % dir(mod_python) When from mod_python import publisher is executed it will complain it cannot find publisher. I have attached a fix for this problem, which hopefully can be added to 3.2. I think this is the last problem I know of where I keeping having to use a workaround. BTW, this is [ISSUE 6] in my article about module import problems: http://www.dscpl.com.au/articles/modpython-003.html#packages-loaded-wrongly I might go through my list and see what other things might easily be fixed for 3.2. :-) ImportError: cannot import name publisher - Key: MODPYTHON-12 URL: http://issues.apache.org/jira/browse/MODPYTHON-12 Project: mod_python Type: Bug Versions: 3.1.3 Reporter: Graham Dumpleton Attachments: package.diff.txt From mailing list. ImportError: cannot import name publisher In a directory publisher, setup for mod_python.publisher as described in previous email, and with same index.py. Ie., import os def index(): return os.getpid(),__file__ Now create a parallel directory called handler and in its .htaccess file add: SetHandler python-program PythonHandler mptest PythonDebug On The mptest.py file in that directory should read: from mod_python import apache import os from mod_python import publisher def handler(req): req.content_type = text/plain req.send_http_header() req.write(str((os.getpid(),__file__))) return apache.OK Restart Apache to clear caches and access handler and publisher directories in that order. One gets: (747, '/Users/grahamd/Sites/handler/mptest.py') (747, '/Users/grahamd/Sites/publisher/index.py') (747, '/Users/grahamd/Sites/handler/mptest.py') (747, '/Users/grahamd/Sites/publisher/index.py') Okay, everything is fine. Now restart Apache to clear caches and access publisher and then handler. Ie., in reverse order. One gets: (761, '/Users/grahamd/Sites/publisher/index.py') Mod_python error: PythonHandler mptest Traceback (most recent call last): File /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/apache.py, line 296, in HandlerDispatch log=debug) File /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/apache.py, line 421, in import_module autoreload=autoreload,log=log,path=path) File /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/apache.py, line 474, in _unsafe_import_module module = imp.load_module(mname, f, p, d) File /Users/grahamd/Sites/handler/mptest.py, line 4, in ? from mod_python import publisher ImportError: cannot import name publisher The way in which mod_python.publisher is loaded as PythonHandler, if done before being imported explicitly using import, screws up that latter import. I know some will scream that I am mixing import and import_module(), but since mod_python.publisher is installed into site-packages, one should expect it to work with import. Whether it does is order dependent. Because I use mod_python.publisher in Vampire for its user authentication stuff, this problem means that if using Vampire and elsewhere also wanting to use mod_python.publisher as PythonHandler, that the Vampire area should be setup with its own PythonInterpreter instance. Having now remembered this problem, as a workaround in Vampire I should probably go and use: publisher = apache.import_module(mod_python.publisher) instead. At least that way it will work all the time. :-) I know my wanting to use internals of mod_python.publisher is the exception, but these sort of strange things shouldn't by right happen. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
