tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Tomcat-Lite update
Date Fri, 06 Nov 2009 19:51:39 GMT

Tomcat-Lite was started few years ago as an effort to produce a smaller,
cleaner version of tomcat. Unfortunately
it  didn't get lots of development time - I was very busy at work ( and at
home - 2 kids now ), and it didn't
seem to be in a state where other people would start using it and

As I should have known, reimplementing from scratch or major refactoring
where you break most
compatibility and lose the 'evolution' track are a bad idea.  I also
realized that I'm no longer capable of
implementing crappy spec features - certainly not in my free time.

So I'm proposing a different approach, and I hope this time I'll find people
willing to use and help.

Instead of attempting to have another implementation of the servlet spec -
and a potential alternative to
tomcat for specific use cases - I think tomcat-lite should become a
user-space library with cleaned up
tomcat components. Instead of using tomcat-lite as a servlet engine, you
should be able to use the code
in any servlet engine - or outside a servlet engine.

The initial list of features ( that I have partially working ):

1. HTTP client and server, based on tomcat connector. This is based on the
NIO connector ( but with an easy
way to add an APR port ), with some major refactorings:
- C2B/B2C are replaced with nio CharsetEncoder

- input/output based on a queue of buffers, to avoid copy - for example a
proxy will just move buffers from one
channel to another.

- ByteChunk/CharChunk  cleaned up as a result

- abstractions to allow easier non-socket use ( unit tests, connectors,
generating content with servlets )

- client code - as an alternative to httpclient, but using tomcat
infrastructure, i.e. non-blocking code and
hopefully cleaner/more efficient.

- enhanced the MessageBytes-centric CoyoteAPI - now the connector
request/response are almost
identical with a HttpServletRequest, so it should be much easier to use
connector directly. The client
code uses the same objects - if you are familiar with HttpServletRequest it
should be easy to
make client http requests, there are setters for each getter.

- a built-in and tightly integrated proxy  - a lot of the decisions for
refactoring were driven by proxy use case.

The hope is that at some point the http server connector will be used by
tomcat, and there is some (beginning) of
code to wrap it behind coyote interfaces. However you should be able to use
the client in tomcat (or any other
engine ) regardless of what connector you use, and you should be able to use
the server to add HTTP
server capability to any application.

2. A set of servlets and filters - derived from Tomcat Valves or new - that
implement features typically provided
by a servlet engine, but in user space. That mean a web application should
be able to use them to bypass
whatever is provided by the servlet engine and have more control over
authentication, session management, etc.
The hope is that tomcat will at some point use those components - but the
code should be independent of

3. A minimal implementation of a subset of the servlet API, allowing
servlets to be used or tested using the
HTTP connector code. There are few servlet testing frameworks that do the
same - tomcat-lite should have
a more complete implementation and be more 'production' oriented, i.e. you
should be able to call servlets
inside a random application.
This will NOT implement the full specification or be a servlet engine, the
goal is to allow servlets to be used
OUTSIDE of a servlet engine environment.

4. In integration layer - allowing you to use things like Spring or OSGI
with the above components, without
having a compile or run time dependency on the framework.

I know that typically tomcat has provided only 'the reference implementation
of servlet spec' - however now we're
no longer the  'reference implementation', and as a standalone apache
project I think we can release other
servlet-related components that can be used directly by users.

I also think that there is a lot of value in having a light HTTP java server
that is not a servlet engine, but has
a lighter API and is less of a heavy framework.

While we want people to use tomcat as their servlet engine - I think it's
important for tomcat project to move
beyond that, and allow some of the features to be used _outside_ of tomcat
servlet engine. We already
do this with jasper and el - our goal is to help users, not to force them to
use tomcat engine. Even if
session management or authentication may  be slower if done in user space,
and people may just
use tomcat features they like but move to a different servlet engine.

Opinions ? Let me know if you would like to see the code in sandbox first,
or rather see it in sourceforge, or
maybe if you're interested to help...


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message