tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <>
Subject Re: Tomcat-Lite - part 1
Date Sun, 31 Aug 2008 03:44:59 GMT
Thanks for all the answers so far - I'll start a new thread for the first
part of the process,
with more details on the coyote changes. The help I need most is review and
from people who spent most time with coyote. The goal of tomcat-lite is to
be small and simple -
hopefully it wont have a lot of new code, quite the opposite, most changes
remove code and features ( from the coyote-standalone and tomcat-lite target

On Sat, Aug 30, 2008 at 2:11 PM, Remy Maucherat <> wrote:

> On Fri, 2008-08-29 at 21:13 -0700, Costin Manolache wrote:
> > I think moving forward, for tomcat-7 and beyond - it would be worth
> > reconsidering some of the 10-year-old decisions, and
> > tomcat-lite can be a good example on how things can be done
> differently:
> I still don't intend to participate in future Tomcat development, but I
> have the feeling I am expected to answer this ;) So +0 for adding it the
> repository (since I won't help).

Well, after so many years of participating in tomcat - your answers are a
great form
of help.

> > - Valves/LifecycleListeners versus plain Filters and listeners
> Personally, I think the strong type barrier between userland and the
> container is nice.

Access to low-level container objects ( which is the 'barrier' you mention )
has many
benefits, there is no doubt that the new model won't fit all cases and can
be slower.

But I think it's good to explore the 'lazy' choice as well - people can and
do write all
kind of filters for auth, custom session management, etc - and for many the
barrier does matter. Making it easier to integrate those plain filters into
the container
has tons of benefits - some may be converted to Valves ( in 'regular'
tomcat) if needed.

> - configuration and better integration with frameworks (
> > JMX/dep-injection/etc)
> > - sanbox support
> > - layers and complexity
> I am interested to look at the code like the proxy, and see if what it
> can do.

Unfortunately SelectorThreadApr is not up-to-date, it shouldn't be hard but
it's lower priority for me. You can get an idea from SelectorThreadNio.
I didn't implement the POST side of the proxy yet

> OTOH, I'm really not buying the size argument. I mean, once you add all
> the "useless" components like the realms, session managers, utility
> "valves", JSP and JDT. That recurrent criticism is just lame: since its
> introduction in Tomcat 4.0, the current architecture only became faster
> and more efficient (running on the same hardware). Given its age, this
> means its requirements today are really small, and I think it's enough
> to address the embedded market ;)

Sorry - the actual argument I'm planning to use is complexity and number of
layers. Size is just an extra benefit of reducing the complexity, I think
and maintainability will be other ( but I didn't benchmark yet, nor do I
think this is the
main issue ).

It also depends on the target hardware, but I agree - if you want JSP and
lots of feature it's better to
use the regular tomcat. What I'm using in most of my experiments (on arm
200..300 Mhz / jamvm / ~64M RAM )
is plain coyote.

PS: Ok, I have no idea how you did it, but you managed to workaround the
> list's replyto.

Sorry, just sent to from gmail. I have the @apache
address as  secondary
to workaround the subscription address. Sorry, not sure how to workaround
the workaround.


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