Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Date: Wed, 14 Mar 2001 17:42:10 -0800 (PST)
From: cmanolache@yahoo.com
To: tomcat-dev@jakarta.apache.org
Subject: Re: [PROPOSAL] The Commons - web connector
In-Reply-To: <3AB006D1.D9733004@shore.net>
Message-ID: <Pine.LNX.4.21.0103141719250.7386-100000@simona.wyn.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 14 Mar 2001, Dan Milstein wrote:

> I don't see the advantages to having a separate project for the connectors. 
> Can someone explain that to me?

I don't think the proposal meant a separate top level project, with
separate list, etc.

It meant to decouple mod_jk and the connector from tomcat 3.3

As you can see in previous mails, there are people who "will not touch any
line of tomcat 3.x". 

I think mod_jk and the connector part of tomcat3.3 is a great piece of
work, with a lot of great ideas - and it doesn't depend in any way of
tomcat3.3 - the same as mod_webapp is not specific to tomcat4.0

I think it will help to have a "common" and "neutral" repository, with
the goal of creating a connector based on the best ideas from mod_jk and
mod_webapp - or ( as mod_jk is designed ) multiple protocols that are used
in by both tomcat3.3, tomcat4.0 and maybe other containers. 

As I said, the connector is in charge with implementing a protocol of
communication between the server and container - it doesn't depend on
having "Interceptors" or "Valves", it doesn't depend on having 6 core
classes or 20 interfaces, it doesn't depend on having a Loader interface
or using the standard ClassLoader.

Of course, there are parts that are specific to a container - but the idea
is to share what's common.

In the same way, it would be great to develop a single set of
general-purpose utilities - like ThreadPools, MessageBytes, etc - that
will combine the best out of both codebases and may be used by others as
well. And it would be great to have common code for jasper, with
specialized classes implementing what's different - 90% of the code in
jasper3.3 and jasper4.0 is common ( but is diverging every day ). 

Right now the biggest problem is the fact that some people refuse to
accept there are other ideas and solutions. This leads to duplications all
across jakarta, not only in tomcat3.3/4.0. 

And the only solution I know out of this is to concentrate in what's
common, and respect the differences. 


> The main disadvantage that I see is that the connectors and Tomcat are very
> tightly linked -- I think having one developer list for TC and the

The protocol and most of the connector is not linked in any way to the
underlying architecture of tomcat ( i.e. the Interceptor is just a
wrapper, a way to plug in the connector ). 

The list, bug system, etc will stay the same, of course, it's just that
it'll be less "coupled" with tomcat3.3, and may have a more independent
evolution.

> would be a nightmare to sync up with a "separate" project).  But if there's
> Java code in there, there's going to have to be different code for each
> different engine which the connector talks to (e.g. TC 3, TC 4).  Pulling
> that code out of the main projects makes no sense to me.  It is totally
> dependent on the rest of the project code.

Tomcat 3.3 should work with mod_webapp, tomcat4.0 should work with mod_jk.
There are differences - but most of the code should be common.  The C code
should be the same, and on the Java side the only thing that is different
is the interface on the upper side.
  

> I'm not sure if I'd want to be a committer on a different project -- once

I don't think it should be a different project - but the hope is that more
commiters will contribute on a 3.3-4.0 common connector.

> 3.3 is released, I'm planning on working on the 4.x branch.  The first thing

After 3.3 is released I guess most of us will be working on something else
- for me it'll  the "next" generation of container, combining the best of
3.x and 4.x.

Having a connector that combines the best of mod_jk and mod_webapp will
be a great step in that direction.


> I'd like to do (which I threatened to do a long time ago!), would be to
> write an ajp13 connector and/or merge mod_webapp with mod_jk.  That is
> "connector" work, but I, personally, am more interested in the servlet
> engine as a whole than on "just" the connectors.

Same for me. I would be happy to help in anything that is a "merge" that
combines the best  of both. 


Costin

( BTW, I already have a prototype and a name for the combined thing :-)


> 
> GOMEZ Henri wrote:
> > 
> > Still no response for this sub-project proposal.
> > 
> > The upcoming PMC could be an occasion to speak about it.
> > 
> > I saw at least 4 potentials commiters working on it :
> > 
> > - Dan Milstein, our resident hacker/expert of mod_jk.
> > - Keith Wannamaker, webdav specialist
> > - Pier P. Fumagalli, mod_jserv and mod_webapp father
> > - I, Henri Gomez, mod_jk and adaptation to Apache 2.0
> > 
> > We start speaking of an updated mod_jk with ajp13++ (ajp14)
> > which must fix current known problem like :
> > 
> > - lack of security between Apache / Tomcat
> >   Tomcat accept connection from anybody to it's ajp12/ajp13
> >   connector. We may add so trivial authentification scheme
> >   at least at connect time.
> >   Nothing too expensive but last days on Tomcat list there is
> >   an interesting Thread on 'Encrypting password' ('challenge-response')
> > 
> > - problem with large upload between client -> apache -> tomcat.
> >   If tomcat is broken between the upload we just couldn't do anything
> >   with remaining data and load-balancing/fault-tolerant will be no help
> >   there. We must have a persitant storage used in these upload case (flat
> > file ?)
> > 
> > - context loading/unloading information could be sent from
> >   Tomcat to Apache to let him choose a working Tomcat for
> >   the requested context. Indispensable in production site with
> >   many virutal where admin will want to update specific context.
> > 
> > - mod_jk handle load-balancing but many will just want a simple
> >   fault-tolerant configuration. I Tomcat1 fail just go to Tomcat2,
> >   and just in that case.
> > 
> > Thanks to comment.....
> > 
> > >Hi to all,
> > >
> > >What about a new sub-project, web connector, where all
> > >the developpement on mod_jserv and mod_jk
> > >(and why not mod_webapp) could live.
> > >
> > >Apache 1.3 and 2.0 are allready supported by mod_jk but also
> > >IIS, AOL, and NES (iPlanet) even JNI.
> > >
> > >Tomcat's 3.x and 4.x provide interfaces (modules,
> > >interceptor or whatever) that these connectors will implement :)
> > >
> > >A project which could be in The Commons even if there is
> > >still C code inside but also many java part (TC mod/interceptor).
> > >
> > >We could (must) see Tomcat 4.x use mod_jk or Tomcat 3.x use
> > >mod_webapp from Apache 2.0...
> > >
> > >Comments ?
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, email: tomcat-dev-help@jakarta.apache.org
> 
>