[Paperclips-discuss] Tricky filter issue

[Nic Ferrier]

Paperclips design has thrown up an issue with 2.3 filters.

Paperclips has an HTTPRequest and HTTPResponse which do the hard work
of handling the HTTP implementation for the HTTP connection.

These 2 classes implement the servlet http request/response methods,
largely so that we can pass them directly to a constructor for a
request/response wrapper.

The implementation is constructed in a self dependant way, for
example: the sendErrror() implementation calls the class's own
setStatus() method.


The problem is that when you come to apply filters this breaks down.
The implementation is calling it's own method, not the method provided
by the wrapping filter.

So if you override setStatus() in a filter you might expect that a
servlet will cause that to be called whatever the response is. But
that won't happen, if the servlet calls sendError() then the call will
go down through the wrappers till it reaches
HTTPResponse.sendErrror(). That method will then call
HTTPResponse.setStatus().

Because the overriding is through wrapping rather than extension the
filters setStatus() does not get called.


Still with me? here's my question: should I solve that problem for
the user?

I can do it, there are 2 alternatives:

- make the HTTP implementation classes call the wrapper heirarchy
- provide most of the non-core functionality in the Dispatcher
wrappers

Either would work bu might affect performance. And would this be the
behaviour that users would expect?

If a user overrides setStatus() might they expect that sendError()
will call setStatus()? Or might they expect to have to override
sendError() as well?

This is an important question, if the user overrides both to perform
some action then a Paperclips behaviour described above would cause
the action to occur twice.


Any views?


Nic