And then I realized that would require we made the non-http doFilter
final, which is probably not something we want.
Or could containers perhaps use reflection to see if doFilter was
overridden..
Oh, what a messy world we live in...
Eirik :-)
On Apr 27, 2017 11:42 PM, "Eirik Bjørsnøs" <eirbjo_at_gmail.com> wrote:
>
> Ed, experts
>
> This feedback comes a tad late, but...
>
> Are we really sure we want HttpFilter.doFilter(HttpSR, HttpSR) to be
> protected?
>
> Deep Java Enterprise stack traces end up at the end of quite a few jokes,
> and adding a stack frame to potentially _every_ filter invocation will not
> make the situation any better.
>
> If we made the Http* doFilter method public, that could allow containers
> to chop off the extra stack frame by calling the Http* methods directly,
> right?
>
> Having suggested this feature, I would feel bad if it made Java stack
> traces even harder to deal with than what they are today. So I'd love to
> hear the feedback from the experts on this. Or at least just make sure my
> worries are noted.
>
> Cheers,
> Eirik.
>
>
> On Sep 29, 2015 12:45 AM, "Edward Burns" <edward.burns_at_oracle.com> wrote:
>
> >>>>> On Thu, 24 Sep 2015 10:02:33 +0200, Eirik Bjørsnøs <eirbjo_at_gmail.com>
> said:
>
> Eirik> * Should HttpFilter::filter be abstract nor not? I kind of like
> Eirik> the idea of having a no-op filter, but it also has benefits to
> [...]
> Eirik> least document in Javadoc that "There's almost no reason to
> Eirik> override the filter(ServletRequest method.."), like HttpServlet
> Eirik> documents for the service method.)
>
> I've added that "there's no need to override this method. Also, I made
> doFilter(HttpServletRequest req, HttpServletResponse resp) protected, to
> match the way we do it on HttpServlet.
>
> Eirik> * GenericFilter::getFilterInfo: I guess you added this to reflect
> Eirik> Servlet::getServletInfo. But Filter has no getFilterInfo, so how
> Eirik> much sense does it make to add it in GenericFilter? I suggest we
> Eirik> skip it unless there are compelling reasons to include it.
>
> I've dropped it.
>
> Eirik> Otherwise, thank you for your quick turnaround on this!
>
> You're too charitable. I hardly think nearly a year is quick
> turnaround!
>
> >>>>> On Thu, 24 Sep 2015 11:28:45 +0200, Eirik Bjørsnøs <eirbjo_at_gmail.com>
> said:
>
> EB> Ed,
> EB> I noticed that HttpFilter.service(ServletRequest..) throws a
> EB> ServletException if the request/response are not
> EB> HttpServletRe[quest|sponse].
>
> EB> Should HttpFilter.doFilter do the same?
>
> EB> I don't know if / when this will ever happen. But I guess consistency
> never
> EB> hurts.
>
> More than that. In specs, consistency is essential. I assume you mean
> HttpServlet.service(ServletRequest...)? While it is true that the API
> implementation does that, the javadoc doesn't say it does that. I think
> that should be in the spec and I've created SERVLET_SPEC-143 for that.
>
> I've committed it to the topic branch and also uploaded a new SNAPSHOT
> [1].
>
> Let me confer with Shing-wai and see if it's ready for the EG.
>
> Thanks,
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | 28 Business days til JavaOne 2015
> | 43 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-20150928.223651-2-javadoc.jar/!/index.html
>
>
>