On Sat, 2008-08-30 at 20:44 -0700, Costin Manolache wrote: > > > - 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 > lower > 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.
No problem with that. > > 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 I did not look at it at all yet. Personally, I am interested in the simple proxy scenario (where for some reason you want to send a request to another HTTP server somewhere). Not doing POST means not doing the hard part ;) Bad Costin ;) > 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 > performance > 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. I just wanted to point out that "regular" Tomcat would not change much in size, but I am obviously fine with you refactoring Tomcat. Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
