[ http://issues.apache.org/jira/brows...236
9974 ]

Graham Dumpleton commented on MODPYTHON-144:
--------------------------------------------

Third time lucky. Understand this all a bit better now and have found a bug 
of sorts in mod_python as a result.

req.connection.base_server.get_config()
req.connection.base_server.get_options()

These return config/options outside of all configuration containers.

req.server.get_config()
req.server.get_options()

These return config/options for the virtual host overlayed on top of that in
 req.connection.base_server. If there is no virtual host container would be 
same as req.connection.base_server.

req.get_config()
req.get_options()

These return config/options from containers specific to the URL for a reques
t. That is, Location, Directory and Files containers. These overlay those fr
om req.server and req.connection.base_server.

Now, the server object being exposed in the "apache" module should be the sa
me as available to a request handler through req.connection.base_server.

Unfortunately, the server object currently stored as "apache._server" is not
 necessarily the same as req.connection.base_server. This is because it is s
et to the server object available at the time the interpreter was initialise
d. Depending on the situati
on, this might be either req.connection.base_server or req.server.

The problem arises because in src/mod_python.c, the get_interpreter() functi
on needs to be passed both the interpreter name and a server_rec object.

interpreterdata *get_interpreter(const char *name, server_rec *srv)

Originally the server_rec was used only for ensuring error messages were log
ged in the correct context, thus whether it equated to the base server or vi
rtual host wasn't too important. When MODPYTHON-37 was implemented however, 
the server object was cache
d in the "apache" module. Again, for what it was being used, it didn't actua
lly matter that which server object was being cached varied.

In coming to make the server object available as a public attribute it does 
now matter. The server object must be that which equates to req.connection.b
ase_server.

First off therefore, it should be called "apache.base_server" to make the co
nnection obvious.

Secondly, src/mod_python.c should be modified so that the python_init() func
tion caches a pointer to the base server server_rec structure in a global va
riable. Whenever get_interpreter() is called, this cached server_rec object 
should be supplied as the a
rgument. Alternatively, the get_interpreter() function shouldn't even take t
he server_rec object as a second argument and instead should just get it fro
m the global variable populated by the python_init() function.

A bit of a review should also possibly be done about how about server_rec ob
jects are used to direct where logging goes in the mod_python internals. It 
possibly should be consistent and all go through the base server, rather tha
n randomly through either b
ase server or virtual host server contexts.

> Make apache._server/apace._interpreter part of public API.
> ----------------------------------------------------------
>
>          Key: MODPYTHON-144
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-144
>      Project: mod_python
>         Type: Improvement
>   Components: core
>     Reporter: Graham Dumpleton
>     Assignee: Graham Dumpleton

>
> Within the mod_python.apache module there exists two private variables called "_se
rver" and "_interpreter". These are initialised when an interpreter is first created
. The variables are set to be an instance of the mod_python "serverobject" and the n
ame
of the interpreter. In effect, these would be the same as are available to a request handler
 as "req.server" and "req.interpreter".
> The problem with those in the "req" object is that they are only available to the 
request handler. If these variables in the "mod_python.apache" module are made part 
of the public API, they would then be accessible by any code. Since "server.get_opti
ons
()" now exists and "server.get_config()" works properly, making these public would allow cod
e running at global scope when a module is being imported to consult the server level config
 and/or options to customise their runtime behavour.
> Thus, proposed that these variables be renamed to "apache.server" and "apache.inte
rpreter".

[ Post a follow-up to this message ]