Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 32692 invoked from network); 20 Dec 2001 16:46:15 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 20 Dec 2001 16:46:15 -0000 Received: (qmail 20867 invoked by uid 97); 20 Dec 2001 16:43:51 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 20835 invoked by uid 97); 20 Dec 2001 16:43:51 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 20801 invoked from network); 20 Dec 2001 16:43:50 -0000 Date: Thu, 20 Dec 2001 08:45:11 -0800 (PST) From: X-X-Sender: To: Tomcat Developers List Subject: RE: Connector compatibility between TC 4.0 and 4.1 In-Reply-To: <5C565A580330D411835300B0D0215F990493E019@mail2.motive.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Thu, 20 Dec 2001, Kevin Seguin wrote: > perhaps now is the time to do some rethinking of where the connectors for > each serlvet container live. > > today, in j-t-c, there is the framework (for lack of a better word) for > connectors plus the individual connectors or adapters for tomcat 3 and > tomcat 4. > > personally, i think it would be better to have the individual > connectors/adapters live with the servlet container itself. i.e. put the > ajp13 connector for tomcat 4 in the jakarta-tomcat-4.0 source tree. this > way, j-t-c can build without having dependencies on any servlet containers, > and servlet containers that want to provide connectors that make use of > j-t-c can (optionally) depend on j-t-c. My thinking ( for 4.1/3.3 ) was to have j-t-c built as a 'standalone module', a trusted/priviledged webapp that can be deployed and is self-contained. Keeping all container adapters in j-t-c has the extra benefit that we can share more code among them. And the build changes I'm trying to make should simplify building for all or just individual containers. For the current release - I don't think we should move the code. For jk2 - I also think we should wait until it's in a more concrete shape. Costin -- To unsubscribe, e-mail: For additional commands, e-mail: