Announcement Announcement Module
Collapse
No announcement yet.
question re migrating from spring mvc 2.5 to mvc 3.x Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • question re migrating from spring mvc 2.5 to mvc 3.x

    Currently, we have an app on spring 2.5, and are embarking on upgrading to spring 3.0...

    We make use of mvc controllers to handle ajax json requests, and then use jsonview to render the json back to the client.

    Specifically...

    - the controllers are a subclass of AbstractCommandController (actually a variation of AbstractCommandController described below).
    - the jsonview org.springframework.web.servlet.view.json.jsonView .

    Our abstract controller superclass looks like this...

    Code:
    public abstract class ExceptionCatchingAbstractCommandController extends AbstractCommandController {
    
      /**
        * Catch any exception that might occur, and return the exception & stacktrace in a json wrapper.
        */
      public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response)
      throws Exception
      {
      	try {
      		return super.handleRequest(request, response);
      	} catch(Exception ex) {
      		if ( errorStrategy.canHandleError(ex) ) {
      			ModelAndView view = new ModelAndView("jsonView");
      			errorStrategy.populateErrors(view, ex);
      			return view;
      		} else {
      			throw ex;
      		}
      	}
    }
    The above will catch any exception that occurred while processing the request, and send it in a response to the client as a json object.
    The client comm infrastructure intercepts "server exceptions" and then renders the exception in an error box on the client side, even with a UI for the stack trace, etc..
    We also have a strategy for handling "known" exceptions that we call "Business logic exceptions".. again these are rendered in a more appropriate UI on the client side, and without the stack trace of course.

    It works really really nicely, and minimizes the exception handling code we have to write on the server _and_ the client.
    (but it unfortunately depends on the current spring 2.5 platform.)

    Here's the question...

    With spring3.0 AbstractCommandController is deprecated.
    And there's a new configuration approach for defining controllers (@Controller).

    So.. What would be the best way to migrate the above pattern (and AbstractCommandController, in general) to spring 3.0?

    I see that AbstractCommandController and BaseCommandController are deprecated in 3.0, but the next class up AbstractController is not.

    Instead, should we subclass from AbstractController, and then use the new 3.0 request mapping @RequestBody, etc, as a replacement for the command object?

    Or.. better yet, implement a HandlerExceptionResolver to return the jsonview containing the formatted exception? (and remove the need to subclass AbstractController, moving everything towards annotation.)

    (Hmm.. ok, this sounds acceptable.)

    I'm just starting to dig into some new controllers (among other things) on this app and have some breathing room to apply the 3.0 patterns.

    thx for any suggestions.

    Btw, I presume we will also migrate from jackson for our json rendering -- i've yet to dig into jackson, but we did have some obscure issues with jsonview and (iirc) date objects, etc., so I'm a cautious of switching out the json rendering implementation without digging into it first with some test cases. So, if you know pitfalls/suggestions with using jackson json rendering, that would also be useful info here.

    jeff

  • #2
    Here's a great article that deals with multiple representations using Spring MVC 3.0.

    This uses annotations and HTTPMessageConverter. There's JSON, XML, ATOM, and other representations available in that tutorial. It's really quite simple.

    If you need some guides in setting a simple Spring 3 MVC, check the following: http://krams915.blogspot.com/2010/12...tegration.html

    Comment


    • #3
      Originally posted by skram View Post
      Here's a great article that deals with multiple representations using Spring MVC 3.0.
      Maybe so... Ahem...

      I read through your pages... Um... sorry, but I do not see anything related to my question about generalized exception handling for JSON requests such that the response contains well formed json as opposed to a common error jsp.

      (yes, this stuff is indeed easy... and I've pretty much already grokked what you describe in your tutorials.. that's the basic textbook content.
      Fwiw I'm thinking the reply was simply self-promotion.. maybe to drive page views for advertising?)

      Maybe I missed something .. if so, apologies, but at least point me to something relating to the question about exception handling customization w/ mvc 3, and ideally json.

      thx again.

      Comment


      • #4
        Hi Jeff,

        You might want to look at the HandlerExceptionResolver interface (described here). You can put pretty much everything you had in your catch block there.

        (This assumes that exceptions aren't always caught by your strategy. If they are, you might want to just skip that check, subclass SimpleMappingExceptionResolver, add your errors to the ModelAndView in the getModelAndView() method, and set the defaultView property to "jsonView")

        Hope this helps
        - Don

        Comment


        • #5
          Thanks for the suggestion...

          Originally posted by dbrinker View Post
          Hi Jeff,

          You might want to look at the HandlerExceptionResolver
          ...
          Hope this helps
          - Don
          Don.. thanks for the reply. It did indeed help immensely.

          Turns out we already had the JsonExceptionResolver configured to handle things like prettyprinting stack traces for displaying via ajax (json view) to the client.

          As you might surmise, we had an ExceptionHandler that did this prettyprinting, and was plugged into the JsonExceptionResolver. I merely extended this existing exception handler, and integrated the error handling strategy -- essentially certain exceptions are converted to validation errors.

          Seems to be working out nicely.

          thanks again for the suggestion.

          Comment

          Working...
          X