tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Brittain" <>
Subject Re: Tomcat-Lite - part 1
Date Thu, 04 Sep 2008 07:47:22 GMT
On Tue, Sep 2, 2008 at 8:20 AM, Costin Manolache <> wrote:
> On Tue, Sep 2, 2008 at 3:57 AM, Tim Funk <> wrote:
>> Costin Manolache wrote:
>> Cool. In a nutshell - I like all the ideas.
>> But while I like the idea of ditching Valves/LifecycleListeners - how does
>> this work when the component needs to work across multiple ServletContext's?
>> The only reason I see that Valves/LifecycleListeners need to yet exist is to
>> handle those kind of issues.  Examples: AccessLogValve or any Valve which
>> needs to act on an the entire Container or a single virtual host.
> Using Filter interface doesn't mean we need to restrict it to a single
> ServletContext or not have access to internal objects,
> it should be possible to set them at container level. In tomcat-lite I tried
> either using the ROOT context, or using a super-context
> that comes before root - the filter chain in this context will replace the
> existing catalina valve chain.
> There is also a package - java/o.a.tomcat.servlets.addon ( like everything
> else in tomcat-lite, name and interfaces are subject to review and
> change ) with an attempt to abstract common interfaces that a filter could
> use to get extra-access to the container internals.
> The interfaces can be implemented by catalina, the new tomcat-lite - and
> maybe other containers if the choose so.
> Ideally, an extension will check if the container supports the extra
> interfaces and if not degrade to single-context mode if not.
> Costin

I also like seeing discussion around new ideas for improving Tomcat,
and I agree that a minimalistic Tomcat jar distribution could strike a
chord with many developers who otherwise use a different servlet
container since Tomcat doesn't offer that.  Thanks for your work on
it!  I think one important feature would be the availability of a
Tomcat jar, and docs that show how to embed it in a standalone Java
application.  Even if that was available and the size of the jar was
still rather large, people would still use it, I think.  Hard disk
capacities are getting quite large, machines are getting faster at
moving bits around, and having all of Tomcat's regular features and
compatibility packaged as a jar file would be worth it.  If it could
be possible to make the jar file smaller (by offering build-time
subsetting maybe?  with popular subset jars up for download?), while
still maintaining a high degree of compatibility with the full Tomcat
distribution, that would be even better.

About Valves versus Filters..  I don't see the advantages of using
Filters in the container instead of Valves.  Here are some reasons
I've heard for either completely removing Valves, or for using
something else instead of Valves, and my thoughts on each:

Reason 1: Valves complicate the container, and are a layer that can be removed.
I don't agree that it can just be removed and nothing added right back
to replace it.  You're talking about replacing Valves with Filters, so
no layer would be removed in that case.  The feature like Valves is
useful, which is why you're suggesting Filters as a replacement.  If
Tomcat lite's embedding code had a runtime configuration feature for
turning off Valves, that would allow a developer to choose to have it
as part of the request processing or not (though doing that wouldn't
make the Tomcat jar any smaller).  Still, if you want Filters where
Valves currently are, then you probably wouldn't the binary
significantly smaller doing that.

Reason 2: Valves are Tomcat-specific and are not cross-container like
Filters, so if we used Filters then developers on other servlet
containers could also develop and use the Filters.
Web container-space code is intentionally not specified in the Servlet
Specification, maybe to promote creativity and flexibility in the
implementation of web containers.  This is a zone where servlet
container teams compete with one another, and try to offer value in
the form of better capabilities or better performance.  They can't
offer a better servlet API.  That part has to work like it does in all
of the other servlet containers.  So non-standardized features like
Valves and different packaging/embedding models, additional useful
configuration options, and better overall performance make people
decide to use one servlet container over another.  We could try to
standardize more features that the Servlet spec does not attempt to
standardize, but I think most people won't want to, partially for
competitive reasons.  We could attempt to adapt Filters to this job,
which are already standardized, but their behavior is specified only
for webapp-space use, and using Filters for container-space would
confuse a lot of people.  We would have to have two different kinds of
filter mappings, one in web.xml and another in server.xml (right?).  I
also do favor the strong type differences between Valve and Filter.
Right now, it's perfectly clear which is which, and what they're each
used for (IMO).

Reason 3: Valves are old, and Filters were made to replace them, so we
don't need Valves anymore.
Before most servlet containers had the feature of Filters, Tomcat
already had Valves, and certainly more Valves were written back then
because (at least with Tomcat) that was about the only way you could
do it.  Then, when Filters worked, many developers converted their
Valves to Filters so that the code could be cross-container.  Most
Valves could just instead be made into Filters, so most Valve
implementations became Filters.  But, that's all webapp-space, single
context.  There are (admittedly more rare) cases where developers need
to write multi-context Valves, and not modify the webapps in any way,
or where developers need to write something that runs as part of the
container system regardless of the number of contexts it's
encapsulating.  So, Valves do a job that Filters cannot, and
webapp-space filters can't entirely replace Valves.. without running
in the container space where they're not specified/standardized to
run.  If they're nonstandard that way, then how would that be
different than Valves?  The Filter interface is not Tomcat specific?
Maybe the Valve interface should be changed so that it's not Tomcat
specific.  Or, maybe not, since changing the interface causes some

Reason 4: Valves don't need to be Tomcat specific to filter requests,
so they shouldn't be, and so we should use Filters instead because
they're not Tomcat specific.
This reason is about whether Valves should have dependencies on Tomcat
internal classes, based on separation of concerns alone.  It might be
true that Valves wouldn't have to have any dependencies on Tomcat
internal classes in order to perform request filtering, but this code
is running in the container space anyway, and is actually more
powerful if Valve code has full access to Tomcat internals, and runs
as a first class container object.  More features are available, even
if they are Tomcat specific.  Features that are not meant to be
available to Filters.

I think Filters and Valves are two different things (even if there are
similarities), and should be two different types, and I think both of
these features should be available in Tomcat, including Tomcat lite.


Jason Brittain

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message