Announcement Announcement Module
Collapse
No announcement yet.
The introduction of SmartView in spring-webmvc 3.1 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • The introduction of SmartView in spring-webmvc 3.1

    In an existing application I use the ContentNegotiationViewResolver to provide both xml and html responses. For some html requests, the response should be a redirect, where for xml it should use a MarshallingView.

    Previously this worked perfectly. However, with the introduction of the SmartView interface and the adjustment to ContentNegotiatingViewResolver.getBestView(..) this is no longer working.

    What could be the workaround to get this working?

  • #2
    There was a fix in 3.1:
    https://jira.springsource.org/browse/SPR-8611

    where if the view string begins with "redirect:" the redirect was being ignored when using the ContentNegotiatingViewResolver.

    Can you provide some more detail on your case?

    Comment


    • #3
      Apparently, we make use of the opening that was in the ContentNegotiatingViewResolver.

      We have a parent-child view, where if you request the child as xml, you get xml. And when you request the child as html, you get a redirect to the parent.

      Comment


      • #4
        Would you mind posting what the controller method looks like?

        Comment


        • #5
          That would be very simmilar to this.

          Code:
          @RequestMapping(value ="/{parentName}/{childName}", method=RequestMethod.GET)
          public void doGet(Model model, 
                                  @PathVariable("parentName") String parentName,
                                  @PathVariable("childName") String childName) {
              DomainObject o = callSomeService.getObject(childName);
              model.addAttribute("object", o);
          
             return "redirect:/" + parentName";
          }

          Comment


          • #6
            Does anyone know a way to solve this?
            Do I need to remove the ContentNegotiationViewResolver?

            Comment


            • #7
              If you rely on the 'Accept' header you can have:

              Code:
              @RequestMapping(value ="/{parentName}/{childName}", method=RequestMethod.GET)
              public String doGet(Model model, 
                                        @PathVariable("parentName") String parentName,
                                        @PathVariable("childName") String childName) {
                  DomainObject o = callSomeService.getObject(childName);
                  model.addAttribute("object", o);
                  return "redirect:/" + parentName";
              }
              
              @RequestMapping(value ="/*/{childName}", method=RequestMethod.GET, produces="application/xml")
              public DomainObject doGetAsXml@PathVariable("childName") String childName) {
                  return callSomeService.getObject(childName);
              }
              The doGetAsXml method doesn't specify a view name because I assume you have MarshallingView as a default view in the ContentNegotiatingViewResolver. Not the only way to do it but to me it is a little more clear at the cost of some brevity.

              Comment


              • #8
                Hey Rossen

                I've tried to test the produces option, but it seems to me that the AnnotationMethodHandlerAdapter acknowledge this attribute.

                I could try to change to RequestMappingHandlerAdapter, but I was wondering if their is an Adapter that would compare the produces attribute with the extention instead of the Accept header.

                Comment


                • #9
                  Roald, the AnnotationMethodHandlerAdapter doesn't support the produces option. If you're on Spring 3.1 I recommend using RequestMappingHandlerAdapter, which also implies use of RequestMappingHandlerMapping and ExceptionHandlerExceptionResolver instead of (DefaultAnnotationHandlerMapping and AnnotationMethodExceptionResolver).

                  As for using relying on the extension, it is planned, see SPR-8410.

                  Comment

                  Working...
                  X