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
