ServletConfig is one per servlet ServletContext is one per web app

There’s only one ServletContext for an entire web app, and all the parts of the web app share it. But each servlet in the app has its own ServletConfig. The Container makes a ServletContext when a web app is deployed, and makes the context available to each Servlet and JSP (which becomes a servlet) in the web app.

Web app initialization:

  • Container reads the DD and creates a name/value String pair for each <context-param>.

  • Container creates a new instance of ServletContext.

  • Container gives the ServletContext a reference to each name/value pair of the context init parameters.

  • Every servlet and JSP deployed as part of a single web app has access to that same ServletContext.

image with no caption

Watch it!

Don’t confuse ServletConfig parameters with ServletContext parameters!

You really have to keep these straight on the exam, and it’s tricky. You MUST know that both ServletConfig and ServletContext have init parameters, and both have the same getter method—getInitParameter(). BUT... you also have to know that context init parameters are set with <context-param> (not inside a <servlet> element) while servlet init parameters use <init-param> inside the individual <servlet> declarations in the DD.

Watch it!

If the app is distributed, there’s one ServletContext per JVM!

If 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.

There are no Dumb Questions

Q:

Q: What’s with the inconsistent naming scheme? How come the DD elements are <context-param> and <init-param> but in the servlet code, BOTH use the getInitParameter() method?

A:

A: They didn’t ask us to help them come up with the names. If they had, of course, we’d have said it should be getInitParameter() and getContextParameter(), to match the XML elements in the DD. Or, they could have used different XML elements—perhaps <servlet-init-param> and <context-init-param>. But no, that would have sucked all the fun out of trying to keep them straight.

Q:

Q: Why would I ever use <init-param> anyway? Wouldn’t I always want to use <context-param> so that other parts of my app could reuse the values and I won’t have to duplicate XML code for every servlet declaration?

A:

A: It all depends on which part of your app is supposed to see the value. Your application logic might require you to use a value that you want to restrict to only an individual servlet. But typically, developers find app-wide context init parameters a lot more helpful than servlet-specific servlet init parameters. Perhaps the most common use of a context parameter is storing database lookup names. You’d want all parts of your app to have access to the correct name, and when it changes, you want to change it in only one place.

Q:

Q: What happens if I give a context init parameter the same name as a servlet init parameter in the same web app?

A:

A: The molecular-sized black hole miraculously created in a research facility in New Jersey will slip from its containment field, plummet to the earth’s core, and destroy the planet.

Or maybe nothing, because there’s no name space conflict since you get the parameters through two different objects (ServletContext or ServletConfig).

Q:

Q: If you modify the XML to change the value of an init parameter (either servlet or context), when does the servlet or the rest of the web app see the change?

A:

A: ONLY when the web app is redeployed. Remember—we talked about this before—the servlet is initialized only once, at the beginning of its life, and that’s when it’s given its ServletConfig and ServletContext. The Container reads the values from the DD when it creates those two objects, and sets the values.

Q:

Q: Can’t I get around this by setting the values at runtime? Surely there’s an API that’ll let me change those values dynamically...

A:

A: No, there’s not. Look in ServletContext or ServletConfig and you’ll find a getter (getInitParameter()), but you won’t find a setter. There’s no setInitParameter().

Q:

Q: That’s lame.

A:

A: These are init parameters. Init from the Latin word initialization. If you think of them purely as deploy-time constants, you’ll have the right perspective. In fact, that’s so important we’re going to say it again in a bolder way:

Think of init parameters as deploy-time constants!

You can get them at runtime, but you can’t set them. There’s no setInitParameter().

Code Magnets

image with no caption

Exercise

Rearrange the magnets to form a DD that declares a parameter that matches the servlet code:

getServletContext().getInitParameter("foo");

You won’t use all of the magnets!

(Note: when you see <web-app ... >, remember that this is our short-cut to save space on the page. You can’t deploy a web.xml file unless the <web-app> tag has all the attributes it needs.)

image with no caption

Note

If you see “init parameter” without knowing if it means servlet or context init parameter, assume servlet.

Some people use the phrase “init parameter” to mean “servlet init parameter”, and they use “context parameter” or even “application parameter” to mean “context init parameter”. So, even though BOTH are initialization parameters, and both come from the getInitParameter() method, remember that only SERVLET init parameters are listed in the DD as init parameters, so the phrase “init parameter” means “servlet init parameter” by default. We know that as a developer, you’ll be kinder to others and always say explicitly whether an init parameter is a servlet init parameter or a context init parameter.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset