Spring Framework
  1. Spring Framework
  2. SPR-6524

Doc: <mvc:annotation-driven> incompatible to override strategy of handler mappings

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0 RC2, 3.0 RC3
    • Fix Version/s: 3.0 GA
    • Component/s: [Documentation], Web
    • Labels:
      None

      Description

      the <mvc:annotation-driven> feature breaks or at least does not conform to the implemented strategy in MVC that there is an implicit DefaultAnnotationHandlerMapping (D1) which can be replaced with custom parameterized versions (D2) of handler mappings.

      As soon as someone wants to use the above short-cut "<mvc:annotation-driven>" there will be a DefaultAnnotationHandlerMapping (D3) which a) cannot be replaced with a custom version (D2) anymore and b) replaces the implicit one (D1). Even worse - developers declaring (D3) assuming they would override the implicit one (D1) will end up with two instances of DefaultAnnotationHandlerMapping (D2 and D3) resulting in duplicate registration of annotated controllers (component scan) and custom parameterization which will be without any effect as D2 seems to win over D3.

      I think at least a dedicated property for the above declaration should be defined which allows passing in a custom DefaultAnnotationHandlerMapping along with the declaration (+ some clarifying documentation about this wouldn't be too bad).

      Steps to reproduce:

      1) declare in a web application context (e.g. using Spring's DispatcherServlet):

      <mvc:annotation-driven/>

      <bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping" />

      <context:component-scan base-package="org.retroduction" use-default-filters="false">
      <context:include-filter expression="org.springframework.stereotype.Controller" type="annotation"/>
      </context:component-scan>

      2) declare a java controller using @Controller
      3) start container with logging enabled and check logs for duplicate registration of the controller

        Issue Links

          Activity

          Hide
          Juergen Hoeller added a comment -

          This is an intended effect to some degree: <mvc:annotation-driven> is simply not supposed to be combined with manual DefaultAnnotationHandlerMapping instances; this is designed as an either-or choice at present, quite similar to <context:annotation-config> and <tx:annotation-driven>.

          I'll quickly revisit this for GA, even if we might eventually stick with the current behavior as-is.

          Juergen

          Show
          Juergen Hoeller added a comment - This is an intended effect to some degree: <mvc:annotation-driven> is simply not supposed to be combined with manual DefaultAnnotationHandlerMapping instances; this is designed as an either-or choice at present, quite similar to <context:annotation-config> and <tx:annotation-driven>. I'll quickly revisit this for GA, even if we might eventually stick with the current behavior as-is. Juergen
          Hide
          Keith Donald added a comment -

          What do you need to customize that requires a custom DefaultAnnotationHandlerMapping instance?

          Show
          Keith Donald added a comment - What do you need to customize that requires a custom DefaultAnnotationHandlerMapping instance?
          Hide
          Keith Donald added a comment -

          Will address for GA as a Documentation issue. Users have an either-or choice here: either use the mvc namespace and its simplified configuration, or "unroll" to use bean-style config. We don't want to introduce complexity into the namespace options where we can help it--adding support for a custom handler mapping instance exposes complexity.

          Agreed though docs need to be better so this ticket will address that.

          Show
          Keith Donald added a comment - Will address for GA as a Documentation issue. Users have an either-or choice here: either use the mvc namespace and its simplified configuration, or "unroll" to use bean-style config. We don't want to introduce complexity into the namespace options where we can help it--adding support for a custom handler mapping instance exposes complexity. Agreed though docs need to be better so this ticket will address that.
          Hide
          Alex Rau added a comment -

          My instance needs 2 properties to be set:

          <bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping">
          <property name="alwaysUseFullPath" value="false"/>
          <property name="interceptors">
          <list>
          <ref local="localeChangeInterceptor"/>
          </list>
          </property>
          </bean>

          I see Juergen's point and I'm ok with the current state/behaviour. However I think it's a little bit a pitfall without additional/clear documentation what <mvc:annotation-driven> does under the hood (like in my case the hidden definition of a DefaultAnnotationHandlerMapping which magically kills an explicitly declared one). And my investigation stopped with reading the XSD...

          I'm not yet used to these kind of short-cut declarations (but in general I like them to be honest). My workaround right now is just unrolling the short-cut manually.

          Beside the documentation aspect perhaps a nice idea would be adding an optional parameter to the declaration for the handler mapping ?

          Show
          Alex Rau added a comment - My instance needs 2 properties to be set: <bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping"> <property name="alwaysUseFullPath" value="false"/> <property name="interceptors"> <list> <ref local="localeChangeInterceptor"/> </list> </property> </bean> I see Juergen's point and I'm ok with the current state/behaviour. However I think it's a little bit a pitfall without additional/clear documentation what <mvc:annotation-driven> does under the hood (like in my case the hidden definition of a DefaultAnnotationHandlerMapping which magically kills an explicitly declared one). And my investigation stopped with reading the XSD... I'm not yet used to these kind of short-cut declarations (but in general I like them to be honest). My workaround right now is just unrolling the short-cut manually. Beside the documentation aspect perhaps a nice idea would be adding an optional parameter to the declaration for the handler mapping ?
          Hide
          Aleksander Adamowski added a comment -

          Keith, 3.0.GA is due today, and this and SPR-6404 are the last two issues planned for the release.

          Half of the world is holding their breath, waiting for you to address these...

          Show
          Aleksander Adamowski added a comment - Keith, 3.0.GA is due today, and this and SPR-6404 are the last two issues planned for the release. Half of the world is holding their breath, waiting for you to address these...
          Hide
          Mahesh Yamsani added a comment -

          DM Server is waiting for Spring 3 release https://issuetracker.springsource.com/browse/DMS-2252

          Show
          Mahesh Yamsani added a comment - DM Server is waiting for Spring 3 release https://issuetracker.springsource.com/browse/DMS-2252
          Hide
          Marc Logemann added a comment -

          What was the solution for this issue since its marked as fixed?

          I also spent 3 hours debugging spring code just to see that there is some kind of conflict between custom DefaultAnnotationHandlerMapping and annotation-driven.

          I personally need the alwaysUseFullPath = true and i still want to use annotations for defining controllers.

          Show
          Marc Logemann added a comment - What was the solution for this issue since its marked as fixed? I also spent 3 hours debugging spring code just to see that there is some kind of conflict between custom DefaultAnnotationHandlerMapping and annotation-driven. I personally need the alwaysUseFullPath = true and i still want to use annotations for defining controllers.
          Hide
          Rossen Stoyanchev added a comment -

          Hi Marc, I believe the solution was to clarify the documentation. Just one quick note on the code-based configuration for Spring MVC available in Spring 3.1. It provides the equivalent of <mvc:annotation-driven> as well as an option to modify the resulting beans. See this post. If you wanted to give it a try you will need to use 3.1.0.BUILD-SNAPSHOT rather than the M2 release.

          Show
          Rossen Stoyanchev added a comment - Hi Marc, I believe the solution was to clarify the documentation. Just one quick note on the code-based configuration for Spring MVC available in Spring 3.1. It provides the equivalent of <mvc:annotation-driven> as well as an option to modify the resulting beans. See this post . If you wanted to give it a try you will need to use 3.1.0.BUILD-SNAPSHOT rather than the M2 release.

            People

            • Assignee:
              Keith Donald
              Reporter:
              Alex Rau
              Last updater:
              Trevor Marshall
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                2 years, 44 weeks, 2 days ago