As appealing an idea as this sounds (packaging plug-in modules as webapps), it doesn't solve the underlying issue -- different containers have radically different internal architectures, and packaging the plug-in as webapp doesn't avoid having to deal with that. You still have to bridge the architectural differences for "installing" the plug-in functionality in the container, using container-specific APIs.
To be successful at bridging this gap, you've really only got a couple of choices: * Create an external common API for things that are not architecture dependent (like web connectors) that a container can choose to support or not support, and don't bother trying to standardize things that are radically different between architectures (for example, RequestInterceptor vs. Valve, or the very different concepts of how the core components of the container are organized). * Create a meta-architecture (via a set of common APIs) that all containers must support -- never mind that it might mandate doing things in a totally different way than any existing container. IMHO, the latter option is not practical. Packaging plug-in functionality as a web app does nothing to help resolve the basic issue that containers are different on the inside. And, if you went to the effort to do this, you'd spend your time more efficiently by just creating a container conforming to those APIs and be done with it. Oh wait ... we've already done that ... twice :-). That seems entirely sufficient to me. Craig On Fri, 21 Dec 2001 [EMAIL PROTECTED] wrote: > Date: Fri, 21 Dec 2001 11:34:57 -0800 (PST) > From: [EMAIL PROTECTED] > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]> > To: Tomcat Developers List <[EMAIL PROTECTED]> > Subject: RE: Connector compatibility between TC 4.0 and 4.1 > > 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: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
