13

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)?

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
meriton
  • 68,356
  • 14
  • 108
  • 175

1 Answers1

20

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.

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • 1
    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. – Wouter Apr 21 '14 at 09:08
  • @Wouter 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](https://en.wikipedia.org/wiki/WAR_%28Sun_file_format%29). So if your database serves only a single web app, do it at the Context level. One way to do that is writing a ` …` 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. – Basil Bourque May 24 '16 at 06:59
  • @BalusC 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](https://tomcat.apache.org/tomcat-8.0-doc/config/globalresources.html#Environment_Entries): “visible to all web applications” – Basil Bourque May 24 '16 at 07:02
  • @Basil: OP was asking about `` in webapp-specific `web.xml` (which is not visible to other web applications). – BalusC May 24 '16 at 07:06
  • 1
    @BalusC Thanks, I did not understand that fact of scoping. [This section of Tomcat doc](https://tomcat.apache.org/tomcat-5.5-doc/config/globalresources.html#Environment_Entries) 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. – Basil Bourque May 24 '16 at 07:32
  • @Wouter it sounds like you want to share configuration data across contexts without duplication. That suggests 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. – Mark Wood Sep 14 '17 at 19:56