[jira] Commented: (MODPYTHON-162) Add means of optionally merging handlers from parent context into a child context.

["Graham Dumpleton (JIRA)" <ji...@apache.org>]

    [ http://issues.apache.org/jira/browse/MODPYTHON-162?page=comments#action_12374919 ] 

Graham Dumpleton commented on MODPYTHON-162:
--------------------------------------------

Note that the hardest part of implementing this is working out what interpreter handlers should be executed within when they are merged.

If PythonInterpreter is set, then whatever that value for the directory the request is made against would be used.

If PythonInterpPerDirectory is used, then interpreter named is based on req.filename. If req.filename is changed by one of the handler in the list, then its new value doesn't apply for the remainder of the handlers and only applies when next phase is moved to. This is how it works now for stacked handlers in a single phase.

If PythonInterpPerDirective is used however it gets harder as the directory corresponding to the first handler in the list would be used. This however is probably not what you want as the interpreter corresponding to parent would be used and not the lowest level child.

What may be more appropriate is that mod_python keep notionally distinct the list of merged handlers and execute each group within its appropriate interpreter based on its own context. This effectively means that for a particular phase it is going to have to call into apache.CallBack().HandlerDispatch() multiple times, acquiring and releasing the interpreters in turn for each call.

Could be done, but expected behaviour would need to be well defined first.

> Add means of optionally merging handlers from parent context into a child context.
> ----------------------------------------------------------------------------------
>
>          Key: MODPYTHON-162
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-162
>      Project: mod_python
>         Type: New Feature

>   Components: core
>     Reporter: Graham Dumpleton

>
> Blantently stealing documentation from mod_perl, would be nice to have an equivalent to the following feature.
> MergeHandlers
> Turn on merging of Perl*Handler arrays. For example with a setting:
>   PerlFixupHandler Apache2::FixupA
>   
>   <Location /inside>
>       PerlFixupHandler Apache2::FixupB
>   </Location>
> a request for /inside only runs Apache2::FixupB (mod_perl 1.0 behavior). But with this configuration:
>   PerlFixupHandler Apache2::FixupA
>   
>   <Location /inside>
>       PerlOptions +MergeHandlers
>       PerlFixupHandler Apache2::FixupB
>   </Location>
> a request for /inside will run both Apache2::FixupA and Apache2::FixupB handlers.
> Currently mod_python behaves like mod_perl 1.0 in that specifing a handler in a child context will cause any handler for the same phase in a parent context to be totally ignored. In mod_perl 2.0, you can use the MergeHandlers option to say that list of handlers for a parent can be merged with those a of a parent context.
> In mod_perl 2.0 it is an all or nothing affair. Ie., you cant say that you only want handlers for specific phases merged. It might be worth investigating whether it could be more flexible. For example:
>   PythonFixupHandler FixupA
>   
>   <Location /inside>
>       PythonMergeHandlers +PythonFixupHandler
>       PythonFixupHandler FixupB
>   </Location>
>   <Location /inside/inside>
>       PythonMergeHandlers -PythonFixupHandler
>       PythonFixupHandler FixupC
>   </Location>
> Thus, if /, runs FixupA, if /inside, runs FixupA and FixupB. If /inside/inside, runs FixupC. Ie., '-' resets back to default of not merging with parent.

-- 
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