On Thu, 23 Aug 2001, Keith wrote:
> Date: Thu, 23 Aug 2001 16:28:22 -0400
> From: Keith <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: How to deploy a multi-layered web contexts?
>
> Hello,
>
> The website we are devloping is being developed by several different
> development groups where each group is developing a separate
> sub-context.
>
> So the URLs might be /MainContext/SubContext1 and
> /MainContext/SubContext2 with group1 responsible for the content in
> SubContext1 and group 2 responsible for the content in SubContext2.
>
> I understand the .WAR file specification when everthing is at the top
> level context but I am not sure how to organize the content to create
> sub-contexts.
>
> Is it required that everything be packaged into a single .war file with
> just a single WEB-INF directory and a single web.xml file? Having
> just a single WEB-INF directory and a single web.xml results in a
> coordination issue between the development groups.
>
> Thanks,
> Keith
>
>
>
>
>
The short answer is "yes".
However, having a single webapp is not the only architectural choice you
have. For example, you could create a webapp for context path
"/MainContext", and separate webapps for context path
"/MainContext/SubContext1" and so on ... each running from separate WARs
(or directories).
If you look at this approach, there are some important considerations to
keep in mind:
* Each application would be deployed as it's
own WAR (or directory). There is no requirement
that the directory structure match the URL paths
at the top level -- each context path prefix is
mapped to a separate document base in the server
configuration file.
* Separate web applications have separate class loaders
for their application classes. If you have classes
that need to be shared, you can put them into the top
level "lib" directory.
* Separate web applications have their own separate
sessions. If you really need a single session object
to contain attributes for multiple webapps, this
architecture is probably not for you. However, in
many scenarios this is not a troubling restriction.
* Separate web applications do their own authentication
if you are using container-managed security. HOWEVER,
you can make this appear seamless to the user if you
use something like the "Single Sign On" feature in
Tomcat 4, where you only get authenticated the first
time you access a protected resource, and your identity
propogates acrosss all of them.
* Individual web applications can be individually unloaded
and reloaded when revisions occur, without taking the
overall suite of applications out of service for an
upgrade.
Craig McClanahan
