Announcement Announcement Module
No announcement yet.
roo, @RequestMapping, and urlrewrite Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • roo, @RequestMapping, and urlrewrite

    roo configures the webmvc-config.xml to scan for Controller annotations,
    So that encourages us to declare our controllers and request mapping with annotations.
    roo also installs urlrewrite.xml, which leaves us confused about what to put in the annotations.

    Do we list the "from" side or the rewritten "to" version?
    Are we expected to add new rewrite rules for /myController/... ?
    or map all URLs through /app/... ? or /static/...?
    (basically: what is the "theory" and best practice behind roo's use of urlrewrite?)

    Can someone supply (or point to) a simple "best practice" example
    of what to put in the urlrewrite.xml and what to put in the @RequestMapping ?
    [and the actual URLs that will then be mapped to the controller]

    Bonus points if it includes @RequestMapping on individual Methods, including @PathVariable

    We could probably hack around to make this work, but guidance from the masters,
    especially about what would be "forward compatible" with the spirit of roo, would be appreciated.

  • #2
    The sole purpose of Roo using urlrewrite is to clean up your URLs to make them more REST compliant. That said, the URL rewriting done in Roo generated applications should not interfere with your controller URL mappings at all.

    Let me explain:

    Spring MVC needs to know when the dispatcher servlet should be used so your request gets routed to the correct controller (as defined in the @RequestMapping annotation). In order to trigger the dispatcher servlet you would usually define a mapping like so: *.jsp, *.html. This is however, not very useful in a RESTful world where URLs define resources. Another option is to have a mapping like so /myapp/*. Again, since URLs describe resources this option is not very useful because myapp is not a resource as such. But you still need to trigger the dispatcher servlet somehow without 'messing' up the REST pattern.

    The solution taken by Roo is to use url rewriting. So a URL like so:


    would be rewritten to:


    before it reaches Spring MVC. The dispatcher servlet is mapped to /app/* (see your web.xml) and therefore the dispatcher servlet is triggered and takes care of routing the request to the topping controller.

    Once the topping controller is finished processing the request it returns the result like /topping which would result in a URL like


    Again, the URL rewriting kicks in at this stage to 'clean up' the URL presented in your browser so it looks better:


    So there is no need to define /app anywhere in your controller mappings at all.

    The special case is /static and /resource which are used to point to resources which are not supposed to be triggering the dispatcher servlet. These resources are images, CSS, JS, etc. If you look at the jspx files you will see that in order to use these resources you need to add /static to your URL so the dispatcher servlet is not triggered.

    Hope this helps.



    • #3
      Ok, thanks; I think I understand how the urlrewrite process is intended to work.

      Ah-Ha! (he says, after moving @Controller from the enclosing interface to the implementing class 8)

      Using @RequestMapping("/foo/**") on the class and @RequestMapping("/bar") on the method,
      I can invoke using: http://server/mainapp/foo/bar [[as originally expected! ]]

      Now, if I can get the @PathVariable to work...


      • #4
        Glad I could make it clear enough .

        About the @PathVariable, just take a look at the current scaffolded controllers and you will see it working in action. There is of course also documentation available for it in Spring framework.



        • #5
          Yes, I was making it too hard.

          I have a sub-DispatcherServlet running my flex-blazeDS messagebroker, and I needed to insert a rule for that;
          to explicitly map the /messagebroker/** URL so it does not get translated by the final /**->/app/$1

          Because I had been through that, I thought urlrewrite was causing my RequestMapping problem. But no... it was much simpler.