Announcement Announcement Module
Collapse
No announcement yet.
JSP files not found after upgrading to 3.1 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • JSP files not found after upgrading to 3.1

    I am in the process of upgrading an application to Spring 3.1 during this slow Christmas time. Most of the issues found have been relatively easy to resolve except one.

    The app is basically a web services provider using json but we also have a few web pages (controllers and jsp) to see internal state for debugging/testing purposes. These are generated using JSP and are behind the security layer with a login page. Some of the jsp's are in a subdirectory under WEB-INF/jsp.

    Calling a url "http://<server>/dashboard" which calls the dashboard controller which returns a ModelAndView (ModelAndView("test/dashboard", context)) object to direct the call to the jsp page with a valid context. In spring 3.0.7 this worked fine but in 3.1 it fails. It returns a 404 error and the log shows "PWC6117: File "<edited>\classes\webapp\WEB-INF\jsp\dashboard.jsp" not found. The page is actually in WEB-INF\jsp\test\dashboard.jsp as the ModelAndView specifies.

    After a lot of tracing through the spring code in 3.0.7 and 3.1, for the DispatcherServlet.doDispatch() method (the same code between 3.0.7 and 3.1)

    Code:
    HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
    
    ...
    
    // Actually invoke the handler.
    mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
    
    // Do we need view name translation?
    if (mv != null && !mv.hasView()) {
    	mv.setViewName(getDefaultViewName(request));
    }
    For 3.1 the HandlerAdapter returned is an instance of RequestMappingHandlerAdaptor, where mappedHandler.getHandler() returns an org.springframework.web.method.HandlerMethod instance (which contains a ref to the DashboardController). When handle(...) is called it returns a ModelAndView.

    ModelAndView: materialized View is [null]; model is {modelAndView=ModelAndView: reference to view with name 'test/dashboard'; model is {accessToken=false, ...

    Since the wrapper model and view name is null the if condition is called and the name is reset back to what the original request url was, for the controller '/dashboard'. And no such jsp page exists with that name in the base jsp path. The ModelAndView returned from the controller method seems to be ignored.

    For 3.0.7 the HandlerAdapter returned is an instance of AnnotationMethodHandlerAdaptor, where mappedHandler.getHandler() returns a DashBoardController instance. When handle(...) is called it returns a ModelAndView.

    ModelAndView: reference to view with name 'test/dashboard'; model is {accessToken=false, ...

    The returned model appears as expected and the jsp page is invoked at 'WEB-INF/jsp/test/dashboard.jsp'.


    I realise that the HandlerMethod instance is new in 3.1 (to act as a proxy) but the AnnotationMethodHandlerAdaptor does not seem to work on a HandlerMethod instance or delegate the method annotation identification for it's enclosed member handler (in this case DashboardController). And the RequestMappingHandlerAdaptor seems to ignore the ModelAndView returned from the controller by wrapping it with another ModelAndView and hence returns the default request url.

    Am I missing something here as far as new configuration goes? Why in 3.1 is the ModelAndView returned from handle(...) not the same ModelAndView instance returned from the DashboardController handler method. Either there is an issue identifying the correct HandlerAdaptor to use given a HandlerMethod instance or the handle() method is wrapping the ModelAndView unnecessarily.

    Or is there another problem I am not seeing? Any thoughts or assistance gladly accepted.

    (I suppose the simple answer is to move the jsp from the subdirectory to the main jsp directory but I would like to understand why this has stopped working.)

  • #2
    Originally posted by nrj View Post
    Calling a url "http://<server>/dashboard" which calls the dashboard controller which returns a ModelAndView (ModelAndView("test/dashboard", context)) object to direct the call to the jsp page with a valid context.
    If you controller returns the following where context is a Map:

    Code:
    return new ModelAndView("test/dashboard", context);
    Then I would expect it to work fine. I am not sure what you mean by:

    Originally posted by nrj View Post
    Since the wrapper model and view name is null the if condition is called..
    given that you also report that what is printed is not null:

    Originally posted by nrj View Post
    When handle(...) is called it returns a ModelAndView.

    ModelAndView: materialized View is [null]; model is {modelAndView=ModelAndView: reference to view with name 'test/dashboard'; model is {accessToken=false, ...
    Since returning ModelAndView is a fairly basic feature, trying to isolate it to a simple, reproducible test-case would be the best thing to do. If you do manage to demonstrate the issue, consider adding it to the Spring Framework issues repository.

    Comment


    • #3
      Re: JSP files not found after upgrading to 3.1

      Originally posted by Rossen Stoyanchev View Post
      If you controller returns the following where context is a Map:

      Code:
      return new ModelAndView("test/dashboard", context);
      Then I would expect it to work fine. I am not sure what you mean by:

      given that you also report that what is printed is not null:
      I mis-typed my comment with an extra 'and'. It should read:
      "Since the wrapper model view name is null the if condition is called.."
      so when hasView() is called on the ModelAndView returned from handle(...) since it's name/view is null then hasView returns false so this condition is triggered since the ModelAndView is also not null.

      So calling toString on the ModelAndView returned by the handle(...) method on the HandlerAdaptor gives:

      ModelAndView: materialized View is [null]; model is {modelAndView=ModelAndView: reference to view with name 'test/dashboard'; model is {accessToken=false, ...

      So in 3.1 the returned ModelAndView seems to be a wrapper around the ModelAndView returned by my @RequestMapping method. In 3.0.7 there is no wrapper. This seems to be because in 3.1 the HandlerAdapter returned is a RequestMappingHandlerAdaptor where as in 3.0.7 an AnnotationMethoidHandlerAdapter is returned as I outlined in my original post. (In 3.1 due to the org.springframework.web.method.HandlerMethod which seems to wrap the DashboardController, and is not handled correctly when the AnnotationMethodHandlerAdaptor is asked if it can handle it. In 3.0.7 there is no wrapper around DashboardController so AnnotationMethodHandlerAdaptor seems to respond correctly when asked if it can handle it.)

      Do you know why the ModelAndView returned by my @RequestMapping method is wrapped with what appears to be another ModelAndView (proxy?) when being handled by the RequestMappingHandlerAdaptor?

      Since returning ModelAndView is a fairly basic feature, trying to isolate it to a simple, reproducible test-case would be the best thing to do. If you do manage to demonstrate the issue, consider adding it to the Spring Framework issues repository.
      I will see if I can reproduce the issue in a simple way when I have some time. I am not that familiar with Spring and I may be missing some configuration that has changed from 3.0.7 to 3.1 to get it to respond in the correct way.

      Thanks

      Comment


      • #4
        Okay I understand now. It sounds like the ModelAndView instance is not recognized as such and is instead treated as a model attribute and is added to the model. That should not happen. However I can't reproduce the behavior. Simply returning a ModelAndView in my tests works fine. So you'll need to reproduce the issue in as simple project as you can.

        There is a template project at the Spring Framework issues repository mentioned above but of course you're welcome to debug it anyway you like.

        Comment


        • #5
          Hi were you able to solve this problem? I'm facing the same issue and can't find a solution, any help would be greatly appreciated!

          Comment

          Working...
          X