Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of costin@gmail.com designates
 209.85.198.245 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version
         :content-type:references:x-google-sender-auth;
        b=gd+0mPKTbEasNvJjEmb+tm6WWvMFpNjz8APnMXJ5wuZqgY0va3yr6heA2HRICEahfx
         v8JIfBB20lCCWOl4u8LlbSjDQ3QZl0Z4udhF0m0JKnhq00pGfqcNNQOAdoyKNEO153RN
         CHqncMv/Ep2L77bfJf1wuUHxmy9N1haR7EPHA=
Message-ID: <96e4b5230809041024v1ef07246o3039f6e7b53a8222@mail.gmail.com>
Date: Thu, 4 Sep 2008 10:24:53 -0700
From: "Costin Manolache" <costin@apache.org>
Sender: costin@gmail.com
To: "Jason Brittain" <jason.brittain@gmail.com>
Subject: Re: Tomcat-Lite - part 1
Cc: "Tomcat Developers List" <dev@tomcat.apache.org>
In-Reply-To: <d137e5d10809040047s627c5543j96ce9b7b590a76c3@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_43511_13473223.1220549093143"
References: <96e4b5230808292113t1c71c11fmb7ccb89aac42dba7@mail.gmail.com>
	 <48BD1C16.60509@joedog.org>
	 <96e4b5230809020820u65c2909bvacc5e44ae3fcc1d6@mail.gmail.com>
	 <d137e5d10809040047s627c5543j96ce9b7b590a76c3@mail.gmail.com>

------=_Part_43511_13473223.1220549093143
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Thu, Sep 4, 2008 at 12:47 AM, Jason Brittain <jason.brittain@gmail.com>wrote:

> On Tue, Sep 2, 2008 at 8:20 AM, Costin Manolache <costin@gmail.com> wrote:
> > On Tue, Sep 2, 2008 at 3:57 AM, Tim Funk <funkman@joedog.org> wrote:
> >
> >> Costin Manolache wrote:
> >>
> >>> <A LOT OF STUFF WHICH CAN BE FOUND IN THE ARCHIVES>
> >>
> >> 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.


The 'lite' is more about complexity and layer reduction, size is just an
extra
benefit. I care more about the source size than the jar size - while disk
is cheap, the time required to understand and maintain a large code is not.


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


You can see the code in sandbox/tomcat-lite - the code is currently not
using
Vavles, Listeners, server.xml, and many other things from catalina, just
coyote and
filters ( which are mostly refactored from original catalina valves ).

That doesn't mean that Valves will dissapear - the plan is to add
tomcat-lite engine as an alternative ( module ), but catalina will still be
there and
I don't plan to remove anything from it.

Sure - replacing a Valve with a Filter in lite doesn't change the execution
path. However
it eliminates all the duplicated code for managing the valve pipeline,
configuring
valves, etc - we have to do it for Filter ( and in a certain way ), why have
2 times that ?

I think the container code is also simpler and cleaner - again, you only
have to understand
and maintain Filters and filter chains ( very well documented and specified
).


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


That's probably the biggest reason I'm proposing Filters instead of Valves
:-)

The interaction between the Filters and container in tomcat-lite is
specified
in java/org/apache/tomcat/servlets/addon/, and the goal is to implement the
same interfaces in catalina, and to be easy to implement them on top of
other
containers.

If catalina auth, session management, logging Valves are refactored to
Filters - they will
be indeed usable in other containers and in tomcat-lite. Which is _great_
for everyone.


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


Competing with other containers is not one of tomcat goals AFAIK.

Cooperating with other containers should be a goal for any open source
container, because it helps our users.

What's wrong if someone could take the session management or auth from
tomcat and use it in
another container ( or reverse ) ?


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


Actually - server.xml will not be used in tomcat-lite ( but will remain in
catalina, of course ).

Yes, system filters ( that apply to the entire container ) will be in a
separate config file, but will
use the same syntax as web.xml ( another simplification for the user - why
learn 2 config formats,
reuse the tools, etc ).

For some filters - it should be possible to use the same filter without any
support from
container, and configure it in the app web.xml. There are plenty of
custom-auth filters already,
logging filters, etc.


>
>
> Reason 3: Valves are old, and Filters were made to replace them, so we
> don't need Valves anymore.
>  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
> incompatibility.
>

Yes, the Filters will ( or can ) be used in a non-standard way - cross
context,
access to internal objects, etc.

The only thing that will change in tomcat-lite is that all the code to deal
with Valves will
no longer be there. If other containers choose to support the 'addon'
interfaces and
similar model - the Filters could be reused, but it is not a goal to confine
the
new Filters to single context and user-space-only.


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


Same features will be available to (container-space) Filters, or if we
choose
so even to user-space filters ( i.e. configured in the app web.xml ).

Unless you use the sandbox - user space code can access internal objects via
reflection/introspection, if they want to. In tomcat-lite the sandbox is
removed,
and the 'addon' interfaces are available to all servlets and filters.

Of course - any filter/servlet that uses the addon package will no longer be
portable,
will only work in tomcat-lite ( and catalina or other containers if addon
support is added ).


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

Valves will obviously continue to be available to catalina. My proposal was
just
to add support for 'container-space filters' in catalina. A minimal set of
'container' Filters ( refactored from Valves ) already exists in
tomcat-lite, it will
be a choice for tomcat developers if they want to develop or refactor
extensions
as Valves ( specific to catalina ) or Filters ( work in both catalina and
tomcat-lite,
maybe other containers ).

Tomcat-lite doesn't support Valves - again, the goal was to remove
redundancy and
complexity, if it has Valve - what's the point, we already have catalina.


Costin


>
> Thanks.
>
> --
> Jason Brittain
>

------=_Part_43511_13473223.1220549093143--