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
>
>