Ed,
I noticed that HttpFilter.service(ServletRequest..) throws a
ServletException if the request/response are not
HttpServletRe[quest|sponse].
Should HttpFilter.doFilter do the same?
I don't know if / when this will ever happen. But I guess consistency never
hurts.
Eirik.
On Thu, Sep 24, 2015 at 10:02 AM, Eirik Bjørsnøs <eirbjo_at_gmail.com> wrote:
>
> Ed,
>
> This is great! Some feedback:
>
> * Should HttpFilter::filter be abstract nor not? I kind of like the idea
> of having a no-op filter, but it also has benefits to get the compiler to
> let you know you forgot something in a very obvious way. A benefit of
> having it non-abstract is that when you override it in the IDE you
> typically get a super call generated and then you can decorate that before
> / after. And you don't have to call anything on FilterChain, which I've
> seen confuses beginners. A drawback with non-abstract is the subclass
> author now needs to choose between two filter methods (one of which they
> never want), which may confuse people. (Could be solved by making the
> filter(ServletRequest ..) method final.) I'm not really sure what to
> prefer. Perhaps leaning on your non-abstract version with a final
> ServletRequest method. (If we don't make this final, at least document in
> Javadoc that "There's almost no reason to override the
> filter(ServletRequest method.."), like HttpServlet documents for the
> service method.)
>
> * GenericFilter::getFilterInfo: I guess you added this to reflect
> Servlet::getServletInfo. But Filter has no getFilterInfo, so how much sense
> does it make to add it in GenericFilter? I suggest we skip it unless there
> are compelling reasons to include it. (I've been programming servlets for
> 15 years and I have never seen getServletInfo in the wild. I was only
> vaguely aware this method even existed. I think I might have called that a
> couple of times when what I really wanted was
> getServletConfig/getServletContext. What was the purpose of this methods?
> Showing it in some container UI?
>
> Otherwise, thank you for your quick turnaround on this!
>
> Eirik.
>
>
> On Wed, Sep 23, 2015 at 11:45 PM, Edward Burns <edward.burns_at_oracle.com>
> wrote:
>
>> >>>>> On Wed, 23 Sep 2015 14:10:14 +0200, Eirik Bjørsnøs <
>> eirbjo_at_gmail.com> said:
>>
>> Eirik> Then perhaps also consider empty default methods for Filter.init
>> and
>> Eirik> Filter.destroy?
>>
>> That's a good idea.
>>
>> Eirik> A year ago I proposed adding an abstract HttpFilter class for
>> symmetry with
>> Eirik> HttpServlet. I'm kind of tired of casting ServletRequest/Response
>> to their
>> Eirik> Http subtypes _every_ time I write a filter.
>>
>> Eirik> Here's my proposal from October last year:
>>
>> Eirik>
>> https://java.net/projects/servlet-spec/lists/users/archive/2014-10/message/1
>>
>> Eirik> I did not get any kind of feedback on that proposal. I guess
>> experts don't
>> Eirik> write filters ;-)
>>
>> Sorry for missing that last year. Those are good ideas.
>>
>> I've prototyped these in branch SERVLET_SPEC-141 and attached the
>> snapshot to the JIRA. You can also see the maven artifact at [1].
>>
>> Please take a look at it and if it looks good I'll bring it to the EG.
>>
>> My apologies again for missing this last time.
>>
>> Ed
>>
>>
>> --
>> | edward.burns_at_oracle.com | office: +1 407 458 0017
>> | 31 Business days til JavaOne 2015
>> | 46 Business days til DOAG 2015
>>
>> [1]
>> https://maven.java.net/service/local/repositories/snapshots/archive/javax/servlet/javax.servlet-api/4.0.0-b01-SERVLET_SPEC-141-SNAPSHOT/javax.servlet-api-4.0.0-b01-SERVLET_SPEC-141-20150923.212939-1-javadoc.jar/!/index.html
>>
>>
>