On Sat, Aug 30, 2008 at 12:13 AM, Costin Manolache <[EMAIL PROTECTED]> wrote: > and easier to embed variant. I think it's time to see what can be > contributed back to tomcat main branch, what can be > released, and what needs to be retired or moved out.
Overall, a huge +1. I think this is the best news and effort on Tomcat development in a while. It's like a breath of fresh air, and I'm not joking ;) Personally, not only am I happy to see this in the abstract, I would love to use it in several concrete use-cases that exist today for me. +1 to graduating these components and merging them into the trunk, and making them Tomcat 7.0. Yoav > > The code is organized in several relatively independent components, some of > them low-risk, some controversial - > I will start a separate thread with a proposal to merge back the first > component, then decide what to do with the > others based on the feedback I get here. > > > 1. General tomcat-util and coyote improvements. > > This should be the easy part I hope - sandbox/tomcat-lite/tomcat-coyote > contains the code, just small additions to make it easier to code with > coyote. The only 'major' and backward-incompatible change is in RequestInfo, > replacing ObjectName with Object, it requires 2 casts in nio/apr ( JMX is > not available on some embedded platforms ). > There are few additions - Appendable, CharSequence in CharChunk/ByteChunk, > few small fixes, etc. There is also a new ObjectManager > that can be used to abstract JMX and/or better integrate with frameworks ( > osgi, guice, other dep-injection ). > > 2. Examples and extensions for coyote for 'standalone' use. > > As we know, coyote implements the HTTP protocol, catalina implements the > servlet spec. There are cases where you may > just want a small http server embedded in your app ( but not full servlets), > or maybe you want to load-test/optimize coyote itself. > There are several Adapters - including a conversion of the dav servlet > (default servlet) from tomcat, mapping, startup code, examples. > > I don't know if we want to support 'standalone coyote' - but having the > adapters in the main branch ( marked as > example/unsupported ) shouldn't hurt anyone, and may help people working on > coyote. It works quite well as a server on > very small devices ( like a storage server or phone, with jamvm or on the > android emulator ) > > > 3. A new connector and http client > > This will probably be controversial :-), but there are no deps between the > rest of tomcat-lite and the new connector - all works > just fine with the apr/nio connectors. It is not intended as a replacement, > but as a low-end ( or high-end) alternative. > > The reasons I wrote it: > - wanted to see if the apr/nio code could be merged ( lots is duplicated ). > I think SelectorThread is a good abstraction and can hide the > details of apr/nio. > - was quite unhappy with http client - wanted a non-blocking http client, > and simpler. > - nio/apr connectors were a bit too big for embedded > - I wanted to write a fast proxy servlet - but comet didn't support enough > non-blocking behavior (detached operation, both > input and output blocking). And of course - the http client for proxy needed > to be non-blocking. See the ProxyAdapter as example. > > Again, I don't think adding it to the main branch would hurt ( not enabling > it by default, marking it as 'in progress', etc) - but > I can move it to sourceforge or leave it in sandbox until it's more > appealing. It is missing SSL ( I'm working on it ) and many > of the config flags ( easy to add back ). > > The code is actually based on the existing connectors - I started with the > code in apr connector, then abstracting all that was > apr or nio specific in SelectorThread ( SelectorThreadApr is not submitted, > but at some point worked and shouldn't be hard to fix), > then refactored http parsing code to be fully non-blocking ( nio has this I > think ), and added support for client-mode as well. > > The client should be faster and simpler than apache http-client, and > currently uses coyote APIs ( Request, etc ) - it is > quite convenient if you want to just proxy a request to a different server. > Of course, it is quite tomcat-specific, but if there is > interest it should be used without a server. > > 4. Few filters and servlet code that can be used with any server - and some > tomcat-independent interfaces to better integrate them > > Refactored from Catalina Valves - the idea was that Filters can be used > instead of Valves and be more generic ( > Valves were developed before or at same time with Filter standardization ). > The benefit is that code could be reused > in other engines - like next point, tomcat-lite :-) > The filters provide same services as the original valves - but with no deps > on catalina. > > This can be used if for example you want to have the same auth code on > different servlet engines. I'll send more > explanations when I get to this - IMO it would be great for the servlet > world if tomcat moves away from Valves for > some extensions, when they can be done with filters ( and very light > additional container > interfaces that could be ported easily to other engines ) > > 5. Tomcat-lite - the servlet engine impl > > Again, this started with catalina code, I replaced Valves with Filters, > removed most of the layers ( listeners, etc ) and > kept only the core code. Another major change is removal of all 'sandbox' > support - 10 years ago sandbox was important, > today we have virtualization and improvements in multi-process java. > Removing the sandbox - and the facade objects that > were needed to support proper isolation in sandbox - greatly reduces the > size and simplifies the code ( and reduces memory > footprint ). Full tomcat-lite ( including coyote, servlet.jar - no jsp ) is > about 700K, coyote-standalone is ~400K, core code is in a single package and > uses the plain filters/servlets for most features ( auth, etc ). > > The watchdog is passing - I didn't try the official TCK. BTW - there is also > a port of watchdog to junit ( and testNG ) to make it > easier to run in an IDE. There is some JSP support - but not passing > watchdog. > > If you read this far - I don't want to start a flame war, but I appreciate > all feedback :-). My current goal is to > 'graduate' the first 2 components, the others can stay longer in sandbox or > be moved out - but since they rely on > the first 2 I would have to clone a lot of tomcat code. I think 4 would also > be nice for tomcat, allowing people > to extend tomcat by using easier interfaces ( and have the extensions easily > ported ). I don't mind too much if 3 and 5 > are not accepted at this point, I'll move them out or try again later :-) > > 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: > - Valves/LifecycleListeners versus plain Filters and listeners > - configuration and better integration with frameworks ( > JMX/dep-injection/etc) > - sanbox support > - layers and complexity > > > Costin > -- Thanks, Yoav --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
