Search code examples
jakarta-eeservletsannotations

Replace a context-param element with a Servlet 3.0 annotation

Given: a Java EE 5 web app that has a web.xml that has a snippet like

<context-param>
    <description>c</description>
    <param-name>a</param-name>
    <param-value>b</param-value>
</context-param>

What would I need to do to move that context-param specification into an annotation based strategy.

Solution

  • You can find all javax.servlet annotations in the javax.servlet.annotation package summary:

    • @HandlesTypes This annotation is used to declare the class types that a ServletContainerInitializer can handle.
    • @HttpConstraint This annotation is used within the ServletSecurity annotation to represent the security constraints to be applied to all HTTP protocol methods for which a corresponding HttpMethodConstraint element does NOT occur within the ServletSecurity annotation.
    • @HttpMethodConstraint This annotation is used within the ServletSecurity annotation to represent security constraints on specific HTTP protocol messages.
    • @MultipartConfig Annotation that may be specified on a Servlet class, indicating that instances of the Servlet expect requests that conform to the multipart/form-data MIME type.
    • @ServletSecurity This annotation is used on a Servlet implementation class to specify security constraints to be enforced by a Servlet container on HTTP protocol messages.
    • @WebFilter Annotation used to declare a servlet Filter.
    • @WebInitParam This annotation is used on a Servlet or Filter implementation class to specify an initialization parameter.
    • @WebListener This annotation is used to declare a WebListener.
    • @WebServlet Annotation used to declare a servlet.

    You see, there's nothing like a @WebContextParam. Which makes also less or more sense; on what kind of class would/could you set it?

    Some Servlet based frameworks which rely on context parameters, such as JSF, also allows for setting some of them by JNDI. You might want to look into that instead. Or if it concerns homegrown code, then I'd look if @WebInitParam isn't a more feasible option for you.