On a scale of one to "Dear God, what is that *thing*!?", how bad is
it to add parameters to an HttpServletRequest in a Filter?
I'm not entirely sure why there isn't an addParameter method in
the request class, so it's hard for me to judge. Is it an optimization,
or part of the contract?
Also, does anybody have a good name for such
a class? :)
> I'm not entirely sure why there isn't an addParameter
> method in
> the request class, so it's hard for me to judge. Is
> it an optimization,
> or part of the contract?
There are two types of values that can exist in HttpServletRequest: parameters and attributes. The parameters are the values that are sent from the client side (in submit) and these values can't be modified. Also no other parameters can be added on server side in the request object. Their scope is request.
The attributes are the values that can be added to the HttpServletRequest on the server side. They can be removed. They exist in the request only during the first forward (Attributes are reset between requests).
So, it sound like a contract.
If you need in the request an attribute (that behave as previously described), it is not uncommon to set it in a filter class.
>
> Also, does anybody have a good name for such
> a class? :)
The name of the class generally depends on the functionality the class encapsulates. Fiters names generally ends with 'Filter': "SessionFilter".
