Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <457D7825.8060807@nada.kth.se>
Date: Mon, 11 Dec 2006 16:24:21 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Accessing environment information in 2.2
References: <457D6743.3060509@apache.org>
In-Reply-To: <457D6743.3060509@apache.org>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Carsten Ziegeler skrev:
> During development you sometimes face the problem that you need access
> to specific information, like the current request object (or its
> parameters), the Spring application context, the servlet context etc.
>
> In an ideal world where everything is a component, this is no issue as
> the container provides a way for this. But as we all know, the world is
> not ideal and this means, you sometimes need access to those objects
> when you don't have anything else to use.
>   
Can you give some specific examples where you need this?

> So, I think we need a way to provide those information. The best choice
> seems to be to use thread local variables.
>   
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.

I realize that thread locals might be necessary in a few specific cases. 
But as they make the code really hard to understand and unit test I 
don't feel happy at all about providing some general mechanism for it.

Of course the users of Cocoon should be free to do any mistakes they 
feel like, but we don't need to provide them tools for doing it.

> I think we need a way to access the servlet context, the original http
> request/response object and the current application context. (If you
> have access to the current request object, you can get the application
> context from the request).
>   
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?

> The provide access to those things from everywhere the best way is to
> have a general servlet filter putting the information into thread local
> variables and cleaning them after the request is finished.
>
> This approach has the drawback that users have to put this filter into
> their web.xml. So I think we should make this a little bit more user
> friendly and add the logic/code of this filter to all servlets we
> provide by default (which means the servlet performs the code). So as
> long as users are using our servlets, they get the information "for
> free". In addition, we provide the servlet filter for users who might
> want to use different servlets but need the same information.
>   
I don't see any need for such extra "magic". For users who don't want to 
care about web.xml, we provide a default one that will be enough for 
most needs. For users who care, it shouldn't be any problem to manage 
some filters.

> WDYT?
>   
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.

/Daniel