bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jure Zitnik <>
Subject Re: [Apache Bloodhound] #323: Add support for custom hooks configurable through trac.ini
Date Mon, 14 Jan 2013 15:51:07 GMT
On 1/11/13 9:27 PM, Olemis Lang wrote:
> On 1/11/13, Jure Zitnik <> wrote:
> [...]
>> So I was playing with an idea to introduce global.ini (or boot.ini or
>> something like that) that would be located on a well-known location in
>> the installation tree (trac.env_parent_dir for example) and would hold
>> global (=common for all environments) settings (custom hooks for
>> starters). The question is where this configuration is supposed to be
>> loaded/processed. trac/ would be one place but I'm not sure
>> that's the right one :)
> IMO there's no reason to spend some time developing something new for
> this to happen . The reason is *not* that your reasoning is not
> correct . The fact is that this (configuration inheritance) has been
> already there since a long time .

I'm aware of the configuration inheritance, the problem is that 
inheritance by itself does not solve the issue. Let me try to elaborate 
on the problem a bit more ;)

What I'm trying to achieve is to monkey patch trac.env.Environment and 
trac.db.util.IterableCursor. To enable multi-product support, both 
classes should be replaced by our implementation, namely with 
multiproduct.env.Environment and 
multiproduct.dbcursor.BloodhoundIterableCursor. As things are currently 
implemented, the code that does monkey patching (hooks) is executed 
inside trac.web.main.dispatch_request. At this point, the environment 
(based on the URL) has already been selected (but not instantiated!) so 
the hook path can be read from that specific environment's configuration 
(as the path to the .ini is known) and hooks can be executed. This 
happens just before trac.env.open_environment and thus the 
open_environment already instantiates multiproduct.env.Environment. So 
this works fine when running within a web request (through 

But, there is code that doesn't at all get executed through that 
(dispatch_request) execution path. Example would be tests. To enable 
multi-product functionality in test code (or any other code that doesn't 
get executed through dispatch_request), the hooks (monkey patching) 
should be executed rather soon, before the first trac.env.Environment 
gets instantiated. So, the question is how to achieve that. Note that 
there is no 'environment' at that point. The idea was to have a 
global.ini or something similar on a well known path (not really sure 
what that would be though). trac/ would be modified to load 
configuration from that well known path and execute configured hooks.
If this approach (configurable hooks) is not feasible, we can always 
hardcode them in trac/ ...


View raw message