> 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