Struts 2
  1. Struts 2
  2. WW-3753

The AnnotationActionValidatorManager does not adhere to the ActionValidatorManager interface's contract

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.3.3
    • Component/s: None
    • Labels:
      None

      Description

      An ActionValidatorManager accepts a java.util.String "context" parameter for identifying the appropriate configurations. In the AnnotationActionValidatorManager's buildValidatorKey() method, however, "config.getName()" is used instead of the passed-in context. This violates the contract of the interface and tightly couples the AnnotationActionValidatorManager to the ValidationInterceptor.

      I have a situation whereby I have created my own validation interceptor for a special case that passes in a context not derived from "proxy.getActionName()" (equivalent to config.getName() except for in the case of wildcards), only to find that this context isn't used properly by the manager. I then created my own manager, changing only the buildValidatorKey() to use the given context, and it works well.

      1. ww3753_patch
        5 kB
        Rees Byars

        Issue Links

          Activity

          Lukasz Lenart made changes -
          Fix Version/s 2.3.3 [ 12320642 ]
          Fix Version/s 2.3.2 [ 12319199 ]
          Lukasz Lenart made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Assignee Lukasz Lenart [ lukaszlenart ]
          Fix Version/s 2.3.2 [ 12319199 ]
          Resolution Fixed [ 1 ]
          Rees Byars made changes -
          Description An ActionValidatorManager accepts a java.util.String "context" parameter for identifying the appropriate configurations. In the AnnotationActionValidatorManager's buildValidatorKey() method, however, "config.getName()" is used instead of the passed-in context. This violates the contract of the interface and tightly couples the AnnotationActionValidatorManager to the ValidationInterceptor.

          I have a situation whereby I have created my own validation interceptor for a special case that passes in a context not derived from "proxy.getActionName()" (equivalent to config.getName() except for in the case of wildcards), only to find that this context isn't used properly by the manager. I then created my own manager, changing only the buildValidatorKey() to use the given context, and it works well.

          Either the ActionValidatorManager should be changed to no longer accept a context parameter and handle the context itself in every case (which seems to not be the best solution), or the AnnotationActionValidatorManager should be changed to use the given context in every case. The ValidationInterceptor will need a small change as well in this case to maintain the functionality of WW-3194 without reintroducing the memory leaks from WW-2996.
          An ActionValidatorManager accepts a java.util.String "context" parameter for identifying the appropriate configurations. In the AnnotationActionValidatorManager's buildValidatorKey() method, however, "config.getName()" is used instead of the passed-in context. This violates the contract of the interface and tightly couples the AnnotationActionValidatorManager to the ValidationInterceptor.

          I have a situation whereby I have created my own validation interceptor for a special case that passes in a context not derived from "proxy.getActionName()" (equivalent to config.getName() except for in the case of wildcards), only to find that this context isn't used properly by the manager. I then created my own manager, changing only the buildValidatorKey() to use the given context, and it works well.
          Rees Byars made changes -
          Attachment ww3753_patch [ 12514188 ]
          Rees Byars made changes -
          Description An ActionValidatorManager accepts a java.util.String "context" parameter for identifying the appropriate configurations. In the AnnotationActionValidatorManager's buildValidatorKey() method, however, "config.getName()" is used instead of the passed-in context. This violates the contract of the interface and tightly couples the AnnotationActionValidatorManager to the ValidationInterceptor.

          I have a situation whereby I have created my own validation interceptor for a special case that passes in a context not derived from "proxy.getActionName()" (equivalent to config.getName() except for in the case of wildcards), only to find that this context isn't used properly by the manager. I then created my own manager, changing only the buildValidatorKey() to use the given context, and it works well.

          Either the ActionValidatorManager should be changed to no longer accept a context parameter and handle the context itself in every case (which seems to not be the best solution), or the AnnotationActionValidatorManager should be changed to use the given context in every case. The ValidationInterceptor will need a small change as well in this case to maintain the functionality of WW-3194.
          An ActionValidatorManager accepts a java.util.String "context" parameter for identifying the appropriate configurations. In the AnnotationActionValidatorManager's buildValidatorKey() method, however, "config.getName()" is used instead of the passed-in context. This violates the contract of the interface and tightly couples the AnnotationActionValidatorManager to the ValidationInterceptor.

          I have a situation whereby I have created my own validation interceptor for a special case that passes in a context not derived from "proxy.getActionName()" (equivalent to config.getName() except for in the case of wildcards), only to find that this context isn't used properly by the manager. I then created my own manager, changing only the buildValidatorKey() to use the given context, and it works well.

          Either the ActionValidatorManager should be changed to no longer accept a context parameter and handle the context itself in every case (which seems to not be the best solution), or the AnnotationActionValidatorManager should be changed to use the given context in every case. The ValidationInterceptor will need a small change as well in this case to maintain the functionality of WW-3194 without reintroducing the memory leaks from WW-2996.
          Rees Byars made changes -
          Link This issue is related to WW-2996 [ WW-2996 ]
          Rees Byars made changes -
          Link This issue is related to WW-3194 [ WW-3194 ]
          Rees Byars made changes -
          Field Original Value New Value
          Description An ActionValidatorManager accepts a java.util.String "context" parameter for identifying the appropriate configurations. In the AnnotationActionValidatorManager's buildValidatorKey() method, however, "proxy.getMethod()" is used instead of the passed-in context. This violates the contract of the interface and tightly couples the AnnotationActionValidatorManager to the AnnotationValidationInterceptor.

          I have a situation whereby I have created my own validation interceptor for a special case that passes in a context not derived from proxy.getMethod(), only to find that this context isn't used properly by the manager. I then created my own manager, changing only the buildValidatorKey() to use the given context, and it works well.

          Either the ActionValidatorManager should be changed to no longer accept a context parameter and handle the context itself in every case (which seems to not be the best solution), or the AnnotationActionValidatorManager should be changed to use the given context in every case.
          An ActionValidatorManager accepts a java.util.String "context" parameter for identifying the appropriate configurations. In the AnnotationActionValidatorManager's buildValidatorKey() method, however, "config.getName()" is used instead of the passed-in context. This violates the contract of the interface and tightly couples the AnnotationActionValidatorManager to the ValidationInterceptor.

          I have a situation whereby I have created my own validation interceptor for a special case that passes in a context not derived from "proxy.getActionName()" (equivalent to config.getName() except for in the case of wildcards), only to find that this context isn't used properly by the manager. I then created my own manager, changing only the buildValidatorKey() to use the given context, and it works well.

          Either the ActionValidatorManager should be changed to no longer accept a context parameter and handle the context itself in every case (which seems to not be the best solution), or the AnnotationActionValidatorManager should be changed to use the given context in every case. The ValidationInterceptor will need a small change as well in this case to maintain the functionality of WW-3194.
          Rees Byars created issue -

            People

            • Assignee:
              Lukasz Lenart
              Reporter:
              Rees Byars
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development