From dev-return-90966-apmail-tomcat-dev-archive=tomcat.apache.org@tomcat.apache.org Sat Aug 30 05:19:27 2008 Return-Path: Delivered-To: apmail-tomcat-dev-archive@www.apache.org Received: (qmail 54683 invoked from network); 30 Aug 2008 05:19:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 Aug 2008 05:19:27 -0000 Received: (qmail 38735 invoked by uid 500); 30 Aug 2008 05:19:21 -0000 Delivered-To: apmail-tomcat-dev-archive@tomcat.apache.org Received: (qmail 38690 invoked by uid 500); 30 Aug 2008 05:19:21 -0000 Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Developers List" Delivered-To: mailing list dev@tomcat.apache.org Received: (qmail 38679 invoked by uid 99); 30 Aug 2008 05:19:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 29 Aug 2008 22:19:21 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of henri.gomez@gmail.com designates 209.85.200.172 as permitted sender) Received: from [209.85.200.172] (HELO wf-out-1314.google.com) (209.85.200.172) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 30 Aug 2008 05:18:24 +0000 Received: by wf-out-1314.google.com with SMTP id 25so1075643wfc.12 for ; Fri, 29 Aug 2008 22:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=gGg0lPtzlDk93wrxz/MfjGvOkmUaA9gs1WIS2jvd7q8=; b=JzwdxmxRbIOS4/5a9aKSBOeszfFezFpN+8M1jq5ejdvx1rhcJbJwsr9tLXb5VCKQ9o 56AVvq5GYvtuOEsJXWthdkUycTbWz+tKUvXXgHIRkQtNCJ6/AX2TgcbZFmyI68rNsuLF 6URHc8DWu3XWFZ3UansjlF83k+RHJsm0LYLOQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=p4PrFEuOVpCI4VNRXVuAOXxD6Q3ZdNMOfCRY7qGRBGNP6lHdiQyT5GbGuCkH/esDj1 DhYg6qCgr2vWGI3i388R0juD0pcYW9QauwIIZIy1dBbT5ajn98NW4u6RDX6MX8MtYvGQ npoYzcgSup4G4THbTVbw2xuzWFbq7WZKcrCaA= Received: by 10.142.163.13 with SMTP id l13mr1253557wfe.34.1220073525685; Fri, 29 Aug 2008 22:18:45 -0700 (PDT) Received: by 10.142.199.5 with HTTP; Fri, 29 Aug 2008 22:18:45 -0700 (PDT) Message-ID: <6291fc850808292218g14c718b9oab94fbf1b45fa02a@mail.gmail.com> Date: Sat, 30 Aug 2008 07:18:45 +0200 From: "Henri Gomez" To: "Tomcat Developers List" , costin@apache.org Subject: Re: Tomcat-Lite - part 1 In-Reply-To: <96e4b5230808292113t1c71c11fmb7ccb89aac42dba7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <96e4b5230808292113t1c71c11fmb7ccb89aac42dba7@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org > Hi, > > About 2 years ago (closer to 3) I started a sandbox experiment with the goal > of refactoring tomcat to a smaller > 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. > > 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 > Congratulations ! --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org For additional commands, e-mail: dev-help@tomcat.apache.org