Servlet-spec: <context-param> vs <env-entry> in web.xml?

Question

Why does the Servlet specification define two distinct ways (context parameters and environment entries) to provide a web application with configuration parameters?

What are the respective advantages of these approaches (when should which be preferred)?

Stroman

Answer 1

Environment entries are available via JNDI which may be useful when you don't have a ServletContext directly at hands, such as in EJBs. The one in the web.xml is actually the last in precedence chain as to overridding environment entires. They are usually definied in server's own configuration. So if one intends to override a server-specified environment entry from the webapp on, then that could be done via web.xml.

Context parameters are really specific to the webapp itself. They are only available when you have a ServletContext directly at hands, usually only inside filters, servlets (and inherently also JSPs via ${initParam.someName} in EL) and listeners. They are supposed to be used to provide configuration parameters for filters, servlets and/or listeners running in the webapplication. It wouldn't make much sense to provide them by JNDI which is an overcomplicated process for the simple purpose.

Nahshunn

I am still confused. Suppose I want to store my database connection details, for example? What should I use out of these 2? I do intend on installing my app more than once on the same Tomcat. – Matz

@Matz Environment entries have a wider scope, available to all web applications running on that Tomcat. A “context” is a single web app, mapping to a single WAR file. So if your database serves only a single web app, do it at the Context level. One way to do that is writing a <Context> <Resource>… tag in the context.xml file in your web app’s META-INF folder. As for your mention of “ installing my app more than once on the same Tomcat”, I do not understand, does not make sense. – Expositor

@Nahshunn Your first paragraph is not quite clear. If you mean to say that Environment Entries have a wider scope than Context Parameters, than say so more explicitly. Perhaps quote the Tomcat doc: “visible to all web applications” – Expositor

@Basil: OP was asking about <env-entry> in webapp-specific web.xml (which is not visible to other web applications). – Nahshunn

@Nahshunn Thanks, I did not understand that fact of scoping. This section of Tomcat doc led me to think the app deployment descriptor is global to all apps, but you made me realize I was mis-interpreting. Java EE 7 spec section EE.5.2.4 “Sharing of Environment Entries” does indeed say app-defined Environment Entry values are scoped to that app. Now I understand your first paragraph is saying a ServletContext requires a servlet (of course) but servlets are not the only fish in the wider ocean of Java EE. – Expositor

@Matz it sounds like you want to share configuration data across contexts without duplication. That suggests <resource-env-ref>s. Any number of contexts can refer to the same environment object in this way. How you define the actual environment entries is dependent on your choice of container, because they will be defined in the server configuration. – Scorbutic