Tomcat-Lite update

[Costin Manolache-2]

Hi,

Tomcat-Lite was started few years ago as an effort to produce a smaller,
cleaner version of tomcat. Unfortunately
it  didn't get lots of development time - I was very busy at work ( and at
home - 2 kids now ), and it didn't
seem to be in a state where other people would start using it and
contribute.

As I should have known, reimplementing from scratch or major refactoring
where you break most
compatibility and lose the 'evolution' track are a bad idea.  I also
realized that I'm no longer capable of
implementing crappy spec features - certainly not in my free time.

So I'm proposing a different approach, and I hope this time I'll find people
willing to use and help.

Instead of attempting to have another implementation of the servlet spec -
and a potential alternative to
tomcat for specific use cases - I think tomcat-lite should become a
user-space library with cleaned up
tomcat components. Instead of using tomcat-lite as a servlet engine, you
should be able to use the code
in any servlet engine - or outside a servlet engine.

The initial list of features ( that I have partially working ):

1. HTTP client and server, based on tomcat connector. This is based on the
NIO connector ( but with an easy
way to add an APR port ), with some major refactorings:
- C2B/B2C are replaced with nio CharsetEncoder

- input/output based on a queue of buffers, to avoid copy - for example a
proxy will just move buffers from one
channel to another.

- ByteChunk/CharChunk  cleaned up as a result

- abstractions to allow easier non-socket use ( unit tests, connectors,
generating content with servlets )

- client code - as an alternative to httpclient, but using tomcat
infrastructure, i.e. non-blocking code and
hopefully cleaner/more efficient.

- enhanced the MessageBytes-centric CoyoteAPI - now the connector
request/response are almost
identical with a HttpServletRequest, so it should be much easier to use
connector directly. The client
code uses the same objects - if you are familiar with HttpServletRequest it
should be easy to
make client http requests, there are setters for each getter.

- a built-in and tightly integrated proxy  - a lot of the decisions for
refactoring were driven by proxy use case.

The hope is that at some point the http server connector will be used by
tomcat, and there is some (beginning) of
code to wrap it behind coyote interfaces. However you should be able to use
the client in tomcat (or any other
engine ) regardless of what connector you use, and you should be able to use
the server to add HTTP
server capability to any application.


2. A set of servlets and filters - derived from Tomcat Valves or new - that
implement features typically provided
by a servlet engine, but in user space. That mean a web application should
be able to use them to bypass
whatever is provided by the servlet engine and have more control over
authentication, session management, etc.
The hope is that tomcat will at some point use those components - but the
code should be independent of
tomcat.

3. A minimal implementation of a subset of the servlet API, allowing
servlets to be used or tested using the
HTTP connector code. There are few servlet testing frameworks that do the
same - tomcat-lite should have
a more complete implementation and be more 'production' oriented, i.e. you
should be able to call servlets
inside a random application.
This will NOT implement the full specification or be a servlet engine, the
goal is to allow servlets to be used
OUTSIDE of a servlet engine environment.

4. In integration layer - allowing you to use things like Spring or OSGI
with the above components, without
having a compile or run time dependency on the framework.


I know that typically tomcat has provided only 'the reference implementation
of servlet spec' - however now we're
no longer the  'reference implementation', and as a standalone apache
project I think we can release other
servlet-related components that can be used directly by users.

I also think that there is a lot of value in having a light HTTP java server
that is not a servlet engine, but has
a lighter API and is less of a heavy framework.

While we want people to use tomcat as their servlet engine - I think it's
important for tomcat project to move
beyond that, and allow some of the features to be used _outside_ of tomcat
servlet engine. We already
do this with jasper and el - our goal is to help users, not to force them to
use tomcat engine. Even if
session management or authentication may  be slower if done in user space,
and people may just
use tomcat features they like but move to a different servlet engine.

Opinions ? Let me know if you would like to see the code in sandbox first,
or rather see it in sourceforge, or
maybe if you're interested to help...

Costin

[Tim Funk-2]

I am intrigued by the idea and have similar constraints (kids+job).

My longer term interest in lite was a simpler deployment and moving
config into scripting and out of xml. (But this was more dream due to
time requirements)

As an aside, I am wondering if the long term effect to simplification
will break things like the security manager. And with the capabilities
we see in VM's today - is it better to just ignore the security manager
and just tell people to use an isolated VM if they wish to lock things
down. Is there a good reason to use a security manager today? (This
might be a survey question for the user list)

-Tim

Costin Manolache wrote:
> Hi,
>
> Tomcat-Lite was started few years ago as an effort to produce a smaller,
> cleaner version of tomcat. Unfortunately
> it  didn't get lots of development time - I was very busy at work ( and at
> home - 2 kids now ), and it didn't
> seem to be in a state where other people would start using it and
> contribute.
<SNIP>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Costin Manolache-2]

On Fri, Nov 6, 2009 at 12:19 PM, Tim Funk <funkman@...> wrote:

> I am intrigued by the idea and have similar constraints (kids+job).
>
> My longer term interest in lite was a simpler deployment and moving config
> into scripting and out of xml. (But this was more dream due to time
> requirements)
>

Yes, tomcat-lite should still be able to run servlets - but all the
'framework' from the servlet API will be out of scope.
Tomcat-lite won't create or configure servlets for you, won't have class
loaders or process annotations. That would be
the job of whatever DI framework you chose - or just plain java or
scripting.

It will also not have declarative authentication - instead should have
filters implementing auth schemes beyond what's possible
now - for example OpenID.

IMO the servlet spec - 10 years ago - was a great answer to 'how to I write
web applications in java'. Then the J2EE and framework
stuff got added and added. The whole philosophy is to take away control from
application developer and have the framework
provide it ( typically with a 'lowest common' flavor ).

There are plenty of good DI frameworks - spring, guice, various OSGI
implementations - that do a better job configuring objects or
handling class loading.

I think it's much better to focus on HTTP-related features. It is also a
tractable project for people with jobs and kids, and I think
it would be a better value for both beginners and advanced users.




>
> As an aside, I am wondering if the long term effect to simplification will
> break things like the security manager. And with the capabilities we see in
> VM's today - is it better to just ignore the security manager and just tell
> people to use an isolated VM if they wish to lock things down. Is there a
> good reason to use a security manager today? (This might be a survey
> question for the user list)
>
>
The applet-style security manager is history. I doubt anyone is using it -
or is using it correctly - on server side. It was a dead end anyways
without good isolation and resource limitting.

Isolated processes and/or isolated OS instances seems to be a much better
approach for anyone who really needs to run untrusted code.

That's one of the reasons for the proxy focus - I want at some point to have
tomcat-lite run a single context per process, and proxy/load
balance requests.


Costin

> -Tim
>
>
> Costin Manolache wrote:
>
>> Hi,
>>
>> Tomcat-Lite was started few years ago as an effort to produce a smaller,
>> cleaner version of tomcat. Unfortunately
>> it  didn't get lots of development time - I was very busy at work ( and at
>> home - 2 kids now ), and it didn't
>> seem to be in a state where other people would start using it and
>> contribute.
>>
> <SNIP>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[hgomez]

And what about some sort of OSGI glue and Maven as build tool ?

2009/11/6 Costin Manolache <costin@...>:

> On Fri, Nov 6, 2009 at 12:19 PM, Tim Funk <funkman@...> wrote:
>
>> I am intrigued by the idea and have similar constraints (kids+job).
>>
>> My longer term interest in lite was a simpler deployment and moving config
>> into scripting and out of xml. (But this was more dream due to time
>> requirements)
>>
>
> Yes, tomcat-lite should still be able to run servlets - but all the
> 'framework' from the servlet API will be out of scope.
> Tomcat-lite won't create or configure servlets for you, won't have class
> loaders or process annotations. That would be
> the job of whatever DI framework you chose - or just plain java or
> scripting.
>
> It will also not have declarative authentication - instead should have
> filters implementing auth schemes beyond what's possible
> now - for example OpenID.
>
> IMO the servlet spec - 10 years ago - was a great answer to 'how to I write
> web applications in java'. Then the J2EE and framework
> stuff got added and added. The whole philosophy is to take away control from
> application developer and have the framework
> provide it ( typically with a 'lowest common' flavor ).
>
> There are plenty of good DI frameworks - spring, guice, various OSGI
> implementations - that do a better job configuring objects or
> handling class loading.
>
> I think it's much better to focus on HTTP-related features. It is also a
> tractable project for people with jobs and kids, and I think
> it would be a better value for both beginners and advanced users.
>
>
>
>
>>
>> As an aside, I am wondering if the long term effect to simplification will
>> break things like the security manager. And with the capabilities we see in
>> VM's today - is it better to just ignore the security manager and just tell
>> people to use an isolated VM if they wish to lock things down. Is there a
>> good reason to use a security manager today? (This might be a survey
>> question for the user list)
>>
>>
> The applet-style security manager is history. I doubt anyone is using it -
> or is using it correctly - on server side. It was a dead end anyways
> without good isolation and resource limitting.
>
> Isolated processes and/or isolated OS instances seems to be a much better
> approach for anyone who really needs to run untrusted code.
>
> That's one of the reasons for the proxy focus - I want at some point to have
> tomcat-lite run a single context per process, and proxy/load
> balance requests.
>
>
> Costin
>
>
>
>> -Tim
>>
>>
>> Costin Manolache wrote:
>>
>>> Hi,
>>>
>>> Tomcat-Lite was started few years ago as an effort to produce a smaller,
>>> cleaner version of tomcat. Unfortunately
>>> it  didn't get lots of development time - I was very busy at work ( and at
>>> home - 2 kids now ), and it didn't
>>> seem to be in a state where other people would start using it and
>>> contribute.
>>>
>> <SNIP>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Costin Manolache-2]

On Sat, Nov 7, 2009 at 1:25 AM, Henri Gomez <henri.gomez@...> wrote:

> And what about some sort of OSGI glue


Thanks for volunteering :-).
Note that my goal is to _remove_ any framework feature from tomcat-lite -
leave just http and
services, no config file or class loading.
The current 'integration' interface seems to be enough for spring - feel
free to add hooks/listeners
for any other framework, but no direct dependency.


> and Maven as build tool ?
>
>
Well, you know my opinion on Maven.
However - I'm now using ant-ivy for all downloads, and use a pom.xml file to
declare the dependencies
( ant-ivy can use either its format or pom ). I also added the 'compile'
section - and it seems to
at least compile and test. I'm not planning to maintain or use it - but if
other people want to use mvn I have no problem
as long as build.xml and eclipse .classpath keep working.


Costin

> 2009/11/6 Costin Manolache <costin@...>:
> > On Fri, Nov 6, 2009 at 12:19 PM, Tim Funk <funkman@...> wrote:
> >
> >> I am intrigued by the idea and have similar constraints (kids+job).
> >>
> >> My longer term interest in lite was a simpler deployment and moving
> config
> >> into scripting and out of xml. (But this was more dream due to time
> >> requirements)
> >>
> >
> > Yes, tomcat-lite should still be able to run servlets - but all the
> > 'framework' from the servlet API will be out of scope.
> > Tomcat-lite won't create or configure servlets for you, won't have class
> > loaders or process annotations. That would be
> > the job of whatever DI framework you chose - or just plain java or
> > scripting.
> >
> > It will also not have declarative authentication - instead should have
> > filters implementing auth schemes beyond what's possible
> > now - for example OpenID.
> >
> > IMO the servlet spec - 10 years ago - was a great answer to 'how to I
> write
> > web applications in java'. Then the J2EE and framework
> > stuff got added and added. The whole philosophy is to take away control
> from
> > application developer and have the framework
> > provide it ( typically with a 'lowest common' flavor ).
> >
> > There are plenty of good DI frameworks - spring, guice, various OSGI
> > implementations - that do a better job configuring objects or
> > handling class loading.
> >
> > I think it's much better to focus on HTTP-related features. It is also a
> > tractable project for people with jobs and kids, and I think
> > it would be a better value for both beginners and advanced users.
> >
> >
> >
> >
> >>
> >> As an aside, I am wondering if the long term effect to simplification
> will
> >> break things like the security manager. And with the capabilities we see
> in
> >> VM's today - is it better to just ignore the security manager and just
> tell
> >> people to use an isolated VM if they wish to lock things down. Is there
> a
> >> good reason to use a security manager today? (This might be a survey
> >> question for the user list)
> >>
> >>
> > The applet-style security manager is history. I doubt anyone is using it
> -
> > or is using it correctly - on server side. It was a dead end anyways
> > without good isolation and resource limitting.
> >
> > Isolated processes and/or isolated OS instances seems to be a much better
> > approach for anyone who really needs to run untrusted code.
> >
> > That's one of the reasons for the proxy focus - I want at some point to
> have
> > tomcat-lite run a single context per process, and proxy/load
> > balance requests.
> >
> >
> > Costin
> >
> >
> >
> >> -Tim
> >>
> >>
> >> Costin Manolache wrote:
> >>
> >>> Hi,
> >>>
> >>> Tomcat-Lite was started few years ago as an effort to produce a
> smaller,
> >>> cleaner version of tomcat. Unfortunately
> >>> it  didn't get lots of development time - I was very busy at work ( and
> at
> >>> home - 2 kids now ), and it didn't
> >>> seem to be in a state where other people would start using it and
> >>> contribute.
> >>>
> >> <SNIP>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@...
> >> For additional commands, e-mail: dev-help@...
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>