servlet-spec
  1. servlet-spec
  2. SERVLET_SPEC-28

@WebServlet annotation does not support the 'enabled' attribute specified by the Servlet 3.0 specification

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      See http://java.net/jira/browse/GLASSFISH-17721

      "The Servlet 3.0 specification in section 8.2.3 sub part 3 describes "If a servlet is disabled using the enabled element introduced in the web.xml then the servlet will not be available at the url-pattern specified for the servlet".

      The WebServletHandler.java deployment annotation handler does not support then enabled element and it should since it is part of the web.xml specification for the <servlet> element."

        Issue Links

          Activity

          Hide
          rojkov added a comment -

          I think since this requires recompilation, one can simply comment out the annotation to the same effect.

          Show
          rojkov added a comment - I think since this requires recompilation, one can simply comment out the annotation to the same effect.
          Hide
          emailnbw added a comment -

          @rojkov -

          I don't understand your comment. Are you suggesting a 'work around' or a way to test proposed changes?

          Show
          emailnbw added a comment - @rojkov - I don't understand your comment. Are you suggesting a 'work around' or a way to test proposed changes?
          Hide
          rojkov added a comment -

          @emailnbw enable in web.xml makes sense because you might want to disable a servlet without recompiling, repackaging and redeploying. Adding it to the annotation means that recompilation, repackaging and redeployment is required for the setting to take effect. If the servlet isn't needed it should be either removed from the source or have @WebServlet commented out. The only value the change provides is consistency.

          Show
          rojkov added a comment - @emailnbw enable in web.xml makes sense because you might want to disable a servlet without recompiling, repackaging and redeploying. Adding it to the annotation means that recompilation, repackaging and redeployment is required for the setting to take effect. If the servlet isn't needed it should be either removed from the source or have @WebServlet commented out. The only value the change provides is consistency.
          Hide
          emailnbw added a comment -

          @rojkov -

          Thanks for the clarification, I understand what you were saying now. So the use case I had in mind which is what got me to investigate this in the first place is that our web application does not have a web.xml deployment descriptor. We would like to use the annotation to affect a disabled servlet on deployment which will then be programmatically enabled at a time subsequent to deployment.

          Show
          emailnbw added a comment - @rojkov - Thanks for the clarification, I understand what you were saying now. So the use case I had in mind which is what got me to investigate this in the first place is that our web application does not have a web.xml deployment descriptor. We would like to use the annotation to affect a disabled servlet on deployment which will then be programmatically enabled at a time subsequent to deployment.
          Hide
          rojkov added a comment -

          I see. This seems to add another requirement for a container to monitor changing annotations. The way I interpret the spec is that examining of annotations takes place at starting of the context.

          Show
          rojkov added a comment - I see. This seems to add another requirement for a container to monitor changing annotations. The way I interpret the spec is that examining of annotations takes place at starting of the context.
          Hide
          emailnbw added a comment -

          The container will scan for the annotations during the deployment context, it will find the annotated web servlet, which it does in the current scheme, but it would also possibly find an 'enable' attribute on that WebServlet annotation, e.g.:

          @WebServlet(asyncSupported = false, name = "HelloServlet", urlPatterns =

          {"/hello"}

          , enabled = false)

          It would deploy the servlet in a disabled state the same way the container would have done had this been specified in the web.xml.

          Then some time later external code would enable the web servlet (perhaps via a ReST endpoint the web app provides or a MXBean). The value of the enabled annotation would remain the same through out this process so there is no need to monitor for changing annotations. However, it does mean the container would need to support programmatically enabling/disabling a servlet after deployment. I haven't looked at the existing code path that takes care of enable/disable of a servlet on deployment to know what is involved there.

          Show
          emailnbw added a comment - The container will scan for the annotations during the deployment context, it will find the annotated web servlet, which it does in the current scheme, but it would also possibly find an 'enable' attribute on that WebServlet annotation, e.g.: @WebServlet(asyncSupported = false, name = "HelloServlet", urlPatterns = {"/hello"} , enabled = false) It would deploy the servlet in a disabled state the same way the container would have done had this been specified in the web.xml. Then some time later external code would enable the web servlet (perhaps via a ReST endpoint the web app provides or a MXBean). The value of the enabled annotation would remain the same through out this process so there is no need to monitor for changing annotations. However, it does mean the container would need to support programmatically enabling/disabling a servlet after deployment. I haven't looked at the existing code path that takes care of enable/disable of a servlet on deployment to know what is involved there.
          Hide
          Shing Wai Chan added a comment -

          So having the annotation attribute does not solve your issue, you need a way to enable/disable a given servlet in the runtime. In Servlet 3.0, one can only modify the servlet registration before or on context initialization.

          Show
          Shing Wai Chan added a comment - So having the annotation attribute does not solve your issue, you need a way to enable/disable a given servlet in the runtime. In Servlet 3.0, one can only modify the servlet registration before or on context initialization.
          Hide
          Shing Wai Chan added a comment -

          Adding an 'enabled' attribute to @WebServlet does not solve the issue described above.
          According to Servlet 3.0, one cannot enable a servlet after the context initialization.

          Show
          Shing Wai Chan added a comment - Adding an 'enabled' attribute to @WebServlet does not solve the issue described above. According to Servlet 3.0, one cannot enable a servlet after the context initialization.

            People

            • Assignee:
              Shing Wai Chan
              Reporter:
              Amy Roh
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: