Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 2929 invoked from network); 21 Dec 2001 19:34:55 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 21 Dec 2001 19:34:55 -0000 Received: (qmail 17388 invoked by uid 97); 21 Dec 2001 19:34:19 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 17362 invoked by uid 97); 21 Dec 2001 19:34:17 -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 17341 invoked from network); 21 Dec 2001 19:34:16 -0000 Date: Fri, 21 Dec 2001 11:34:57 -0800 (PST) From: X-X-Sender: To: Tomcat Developers List Subject: RE: Connector compatibility between TC 4.0 and 4.1 In-Reply-To: <5C565A580330D411835300B0D0215F990493E036@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 Fri, 21 Dec 2001, Kevin Seguin wrote: > > 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. > > > > can you provide some more detail? i'm quite interested in learning more. It's quite simple - the idea is to 'package' tomcat modules ( i.e. anything providing additional functionality ) as 'plain' WAR files. Why ? Many good reasons: - reuse - all the infrastructure for webapps will apply to modules as well. With a bit of work we can get dynamic module loading/reloading, deployment ( including 'hot' ) etc. Even setting module properties will benefit from the UI for web.xml admin ( i.e. most config can be done using Context attributes in web.xml ). - self-contained and well defined environment for modules. We'll know that the directory structure on deployment will be clear, we can call getRealPath(/) and know where all our files are located. That's container independent, etc. ( I assume modules will be 'expanded' - that's a requirement, as we'll use the directory structure to generate configs, etc) - a lot of the module can be implemented as plain servlet/jsp. Like 'seeing' jk status, logs, etc. Again, everything is self-contained and have a defined structure ( like in a webapp ) - the original reason for doing that ( in 3.3 ) was simplifying the code. We wanted 3.3 to be as simple as possible, with a minimal core providing the 'referenece implementation' part and nothing else, and have all the 'features' implemented as optional modules. That's what the 'modules/' directory is for. 3.3 does have all the features from 3.2.x, but we tried to not add anything else - any feature should be provided as a module. - of course, the build environment and everything else becomes more 'faimiliar' for people. It's a webapp that happens to implement and use one extra API ( or few APIs ) to interface with the container. It's no different from a webapp that is using diferent parsers or databases. The only 'special' thing is that our webapp can affect the container behavior ( exacly like /admin or /manager ). The only problem is making the 'webapp' usable on multiple containers ( that support the concept ). This is quite painfull for 4.x ( including 4.1 ), because in order to access the internals you need to implement an interface on a servlet ( and that will not load in 3.3 ). But I think there are some ( maybe ugly ) ways to get around this. Again, in a webapp that does database access or xml you want to be able to support multiple 'drivers' - a module doing authentication will also have 'drivers' for different servlet containers, same for jk. Costin -- To unsubscribe, e-mail: For additional commands, e-mail: