tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <cos...@gmail.com>
Subject Re: Tomcat & JDK for PDA arm processor
Date Sun, 23 Apr 2006 17:20:02 GMT
On 4/23/06, Remy Maucherat <remm@apache.org> wrote:
> > I'm still working on a 'light' version - but it's going to take few
> > more months at least. I gave up on repackaging the current code, there
> > are too many deps - and I also gave up on 'coyote standalone', for
> > different reasons I think both are dead ends. So I'm reviving an old
> > idea - and try to create a light 'servlet facade' to coyote, based on
> > the current code but removing most deps.
>
> That's good. I'll also try to reduce a bit the size and memory usage of
> the connectors.
>
> The new Servlet 2.5 spec has more "enterprise" requirements, which makes
> JNDI and JEE dependencies even harder to avoid. Support for these is
> optional, but (as usual) regular webapps will start using them, so a
> "web only" container will have more and more trouble running off the
> shelf webapps.


Depends. I think it's good to have a container that implement only the
'required' parts of the
spec - and not the optional ones. I know quite a few webapps that stay
away from most J2EE features, and use only a tiny portion of the spec
( basic servlet&filters, etc ). Well - at least those I write fit this
description :-)

But the point of 'facades' is to reuse the basic infrastructure (
connector, etc ) but support different needs, without making the code
very complex and full of options.

I can check in some of the code to sandbox, it might better explain
what I'm trying - but it's not even 50% done, can only run basic
servlets ( no web.xml yet, no sessions or auth, etc ). The code is
cut&pasted from catalina, but I colapsed the 2 layers and removed
valves, listeners and most of the interfaces.

Now I'm trying to refactor some of the required valves as regular
Filters, which by itself would be a good thing ( could be used with
any container to get same functionality).

Really - Valves and Filters are very similar, and at this point I
don't see too much reason to code a Valve instead of a standard
filter. Before Filters were defined ( i.e. when Valves were introduced
), it made some sense. If functionality can be provided as
'independent' filter - then it can be reused a lot of other places,
and simplifies a lot the code.


Costin
Mime
View raw message