ServletConfig and ServletContext
ServletConfig
One ServletConfig per Serlet
Use it to pass deploy-time information to the servlet (a database or enterprise bean lookup name, for example) that you don’t want to hard-code into the servlet (servlet init parameters).
Use it to access the ServletContext.
Parameters are confi gured in the Deployment Descriptor.
ServletContext
One ServletContext per web app. (They should have named it AppContext.)
Use it to access web app parameters (also confi gured in the Deployment Descriptor).
Use it as a kind of application bulletin-board, where you can put up messages (called attributes) that other parts of the application can access (way more on this in the next chapter).
Use it to get server info, including the name and version of the
Container, and the version of the API that’s supported.
Note
f your application is distributed across multiple servers (probably in a clustered
environment), your web app really COULD have more than one ServletContext. A
ServletContext is one per app, but only if the app is in a single JVM!
In a distributed environment, you’ll have one ServletContext per JVM. Now, chances are
this won’t create problems, but if you have a distributed web app, you better consider the
consequences of having different contexts for each JVM
One ServletConfig per Serlet
Use it to pass deploy-time information to the servlet (a database or enterprise bean lookup name, for example) that you don’t want to hard-code into the servlet (servlet init parameters).
Use it to access the ServletContext.
Parameters are confi gured in the Deployment Descriptor.
ServletContext
One ServletContext per web app. (They should have named it AppContext.)
Use it to access web app parameters (also confi gured in the Deployment Descriptor).
Use it as a kind of application bulletin-board, where you can put up messages (called attributes) that other parts of the application can access (way more on this in the next chapter).
Use it to get server info, including the name and version of the
Container, and the version of the API that’s supported.
Note
f your application is distributed across multiple servers (probably in a clustered
environment), your web app really COULD have more than one ServletContext. A
ServletContext is one per app, but only if the app is in a single JVM!
In a distributed environment, you’ll have one ServletContext per JVM. Now, chances are
this won’t create problems, but if you have a distributed web app, you better consider the
consequences of having different contexts for each JVM