How to deploy a multi-layered web contexts?

[Keith <kp...@avaya.com>]

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

Re: How to deploy a multi-layered web contexts?

["Craig R. McClanahan" <cr...@apache.org>]

On Thu, 23 Aug 2001, Keith wrote:

> Date: Thu, 23 Aug 2001 16:28:22 -0400
> From: Keith <kp...@avaya.com>
> Reply-To: tomcat-user@jakarta.apache.org
> To: tomcat-user@jakarta.apache.org
> 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