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 comments 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 will remove code and features ( from the coyote-standalone and tomcat-lite target ).
On Sat, Aug 30, 2008 at 2:11 PM, Remy Maucherat <[EMAIL PROTECTED]> 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 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. > - 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 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. PS: Ok, I have no idea how you did it, but you managed to workaround the > list's replyto. > Sorry, just sent to dev@tomcat.apache.org from gmail. I have the @apache address as secondary to workaround the subscription address. Sorry, not sure how to workaround the workaround. Costin
