ServletContexts encapsulate applications. Applications are generalized
virtual hosts; a URL prefix defines a distinct application.
So /myapp and /yourapp could define different applications. As a
degenerate case, each virtual host has its own ServletContext.
Each application is entirely distinct. Each has its own:
- Class loader -- each application gets its own beans and servlets.
- ServletContext attributes
- Servlets and servlet mappings (e.g. *.jsp could map to different
servlets in different applications.)
- File root
- Mime mapping
- Real-path mapping (aliases)
URIs are relative to the application root (e.g. /myapp) for
most ServletContext methods. So you can define user workspaces with
identical JSP files and servlets in different applications.
Including and forwarding
Forwarding and including files, the Servlet equivalent of SSI are
handled by the RequestDispatcher methods.
Global initialization
There is no direct equivalent of a global.jsa. To initialize
and cleanup shared classes on start and stop, use a load-on-startup
servlet. The init() method will be called when the application starts
and the destroy() method will be called when the application finishes.
<servlet servlet-name='global'
servlet-class='test.InitServlet'
load-on-startup/>
Basic configuration
In the resin.conf, to define the /myapp application with a document
root in /www/myweb, add the following to the resin.conf.
<web-app id='/myapp' app-dir='/www/myweb'/>
Servlet and Bean locations (class loaders)
Each application has its own directories to load application servlets
and beans. By default these are WEB-APP/classes and WEB-APP/lib.
To add a servlet test.MyServlet, create the java file:
/www/myweb/WEB-APP/classes/test/MyServlet.java
Load balancing
When using load balancing with a web server, each JVM will have its own
application object. The attributes are not shared. In contrast,
sessions are always sent to the same JVM.
So the application object is best used as a cache rather than
as a way for servlets to communicate.
|