> > > The choices seem to be:
> > >
> > > * Start skipping this filter when building the chains.
> > >
> > > * Block all requests that would normally invoke this filter.
> > >
> > > I'm inclined to be worried by the first alternative -- especially if
we
> > started
> > > skipping an authentication filter simply because it couldn't open its
user
> > > database. My personal preference would be for the second
interpretation.
> > >
> > > NOTE: Tomcat 4 currently does the second one, but it also marks the
> > servlet
> > > itself as unavailable, which is clearly not correct.
> >
> > I personally favour the second one.
>
> Boy, I'm sure not -- especially in the use case I described above. I'm
> not at all liking the thought that all that content I thought was
> protected is open to the world, simply because I mis-typed a database
> password in the configuration parameters.
aey? I agree with you - the first option (skipping) is not an option! :-)
> Are you sure TC it already does this?
> > From my (very) quick reading of the code it appeared it only disabled
the
> > underlying servlet, and left the filter in operation.
>
> Yes, you're right ... it doesn't know the UnavailableException came from
> a Filter, so it marks the servlet unavailable instead. I changed the
> second option description a couple of times before sending that
> response, and forgot to correct the description of what Tomcat 4.0
> actually does right now.
no worries. it's a spec problem anyway, it should be obvious to all how to
implement this.
> > Saying that I would have thought that it would be more useful and
flexible
> > (and probably slower and more complex to implement) if each forward()
call
> > had it's own filter chain. Or perhaps if you could configure the call to
> > work either way that may be best?
>
> The rationale that makes sense to me (in addition to the simplicity
> argument) is that the original filter chain filters a *servlet*. What
> that servlet does inside it's service() method to produce the response
> is a "black box" operation that is totally up to that servlet, which can
> perform its own filter-like activities if it needs to.
Well, I'm not sure which is the "best" way, but I'll be happy as long as the
spec is clear :-).
Cheers
Geoff