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]>
