This is mainly to be compatibe with other classes API.
In a lot of classes, we define methods like this:
```Eiffel
method (req: WSF_REQUEST; res: WSF_RESPONSE)
do
...
end
```
With the context, the signature becomes:
```Eiffel
method (ctx: C; req: WSF_REQUEST; res: WSF_RESPONSE)
do
...
end
```
So, I can't build a filter chain where one filter is with context
and one is without context (I can't call
WSF_FILTER.set_next (a_next: WSF_FILTER) with a filter that is a
descendant of WSF_CONTEXT_HANDLER).
Moreover, having to play with generic types just to pass some
data from one filter to another is a bit overkill imho.
Because this is really what I use contexts for:
to pass data from one filter to the next one.
Regarding execution_variable and strong typing, if we want to achieve these,
I realize we could write a class with one getter and one setter like this:
```Eiffel
class
TYPED_DATA
feature -- Access
user (req: WSF_REQUEST): detachable USER
do
if attached {USER} req.execution_variable ("user") as l_user then
Result := l_user
end
end
feature -- Element change
set_user (req: WSF_REQUEST; a_user: USER)
do
req.set_execution_variable ("user", a_user)
end
```
Now, I realize this is a major change since the last time we talked about this,
but at the end, after having played with both, I prefer the one with
execution_variable.
The logging filter is now part of EWF core (before it was only available in
the filter example) and can therefore be reused by others needing it.
Note that this is a first implementation. It can certainly be improved in
the future to support more fine grained logging.
(note: this commit is a merged of pull request from Olivier Ligot, and changes from Jocelyn Fiat)
Signed-off-by: Jocelyn Fiat <jfiat@eiffel.com>
Signed-off-by: Olivier Ligot <oligot@gmail.com>
Filters are part of a filter chain, thus following the chain of responsability
design pattern.
More information are available in library/server/wsf/src/filter/README.md
