Menu
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)?
364
<env-entry> This tag provides environment variables (properties) which can be accessed by your web application using JNDI. See advantages of specifying parameter values in web. xml for reasons you would want to use this tag.
The optional context-param element declares a Web Application's servlet context initialization parameters. You set each context-param within a single context-param element, using <param-name> and <param-value> elements. You can access these parameters in your code using the javax. servlet.
In a spring web application, contextConfigLocation context param gives the location of the root context. Your config is strange, for a spring-mvc application, because by default, servletname-servlet. xml (where servletname is the name of a DispatcherServlet servlet) is the child application context for the servlet.
The context-param element, subelement of web-app, is used to define the initialization parameter in the application scope. The param-name and param-value are the sub-elements of the context-param. The param-name element defines parameter name and and param-value defines its value.
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.
134
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
