cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [RT] Accessing environment information in 2.2
Date Mon, 11 Dec 2006 15:45:47 GMT
Daniel Fagerstrom wrote:
> Can you give some specific examples where you need this?
We often have the problem to get the current service manager. The whole
code base contains various calls to the EnvironmentHelper class to get
this service manager. One main reason for this are utility methods like
we have in the SourceUtil class. A caller of these utility classes
should not need to get the container just in order to call the utility
stuff. Another problem in this area is that components might be able to
get the container they were declared in, but not the current container.
This is for example important when you're running in a sub sitemap.

Then we have various occasions were someone needs some information from
the request object, like the current uri or some request parameter or to
use this to create an http servlet request wrapper to call some other
stuff. Now, one solution is of course to pass the request object down to
the place where you need it, but this of course would mean that your
implementation might have an impact on your interfaces which is not
really nice.

> This is a dangerous path to follow. Thread locals make it very hard to 
> reuse objects or unit test them. I spent a far to large part of the 
> weekend getting rid of the use of the environment stack in the 
> AbstractProcessingPipeline (not checked in yet, I'm waiting until after 
> the milestone release). This to make the pipeline reusable. It was 
> really hard work to understand what was going on in the code.
Yes, I agree - and 2.2 contains a cleanup version if this stuff... :)

> Spring has some kind of request scope for beans together with a servlet 
> filter for setting up the scope it has also mechanisms for keeping 
> dependencies on request scoped beans up to date. This is a fairly 
> structured and controlled way to handle request scoped information. And 
> it keeps DI and testability. Would it be enough for your needs?
Hmm, not sure - I have not really looked into this stuff. But from my
understanding Spring is using ThreadLocals for this as well :)

> Sorry to be negative, but global variables is really an anti pattern. So 
> I'd like to discuss the specific problem and see if we can find a 
> cleaner solution first.
To be honest, I'm happy to discuss this stuff with someone. Ok,
rethinking a little bit, what about making the current request object
available? This contains the current container as an attribute and it's
possible to get everything else from the container.

Carsten Ziegeler - Chief Architect

View raw message