Announcement Announcement Module
Collapse
No announcement yet.
Overriding default Exception Handling in Portlet MVC Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Overriding default Exception Handling in Portlet MVC

    Hi,

    Firstly, apologies if this is not the right area to post this. I did have a good look around for a a Portlet MVC area, but couldn't see anything.

    OK, to my problem.

    I have an annotation based Liferay Portlet application for uploading files. This all works fine, I have been looking at the validation of the uploaded file and need to restrict based on size. This can be done in Spring config with the following:

    Code:
    <bean id="portletMultipartResolver"
    	        class="org.springframework.web.portlet.multipart.CommonsPortletMultipartResolver">
    
    	    <!-- one of the properties available; the maximum file size in bytes -->
    	   	<property name="maxUploadSize" value="9437000"/>
    	    <property name="uploadTempDir" value="/branches/"/>
    	</bean>
    This is great, however, when posting to the Controller with a file larger than 10MB, the portlet returns a HTTP Response code 400. I'm assuming that Spring is throwing the exception, and just deciding to post that back. This is not what I want to do. I want to decide on how I return the error, as I would like to populate a JSON object.

    I have found a few threads online.
    The first option I have found that is supposed to fix the problem is to include this annotation in my controller:

    Code:
    @ExceptionHandler
    public ModelAndView onException(Exception e) {
    	ModelAndView mav = new ModelAndView(AJAX_IMAGE_UPLOAD_RESULT);
    	mav.addObject("fileUploadError", e.getMessage());
    		
    	return mav;
    }
    This would allow me to redirect to a jsp page and produce the JSON I want, would be perfect, and the suggestion is that you can do this for any exception, which would be even better.

    Sadly, this doesn't seem to work!

    The second option I found that does work, but seems wrong, as I don't want to have to deal with all exceptions manually is to implement an HandlerExceptionResolver interface and implement it's methods! I can do it this way, but will loose default exception handling, and to be honest I don't really want to do that!

    Can any of you Spring experts out there let me know reasons why the first solution may not be working?

    As it's annotation based I have assumed that there is no application.xml config to add! But I maybe wrong.

    Thanks in advance

  • #2
    The first doesn't work because your controller is never reached and @ExceptionHandler methods only work for the controllers they are defined in.

    So the only working solution is to implement a HandlerExceptionResolver to handle your exceptions (which is only a single method and not methods!). You can define multiple HandlerExceptionResolvers in your configuration and when defining a HandlerExceptionResolver it disables the defaults so you will have to add the default ones and your custom one to enable all of them.

    Comment


    • #3
      Hi Marten,

      Thanks for your reply. It seems strange that you can add this exception handling, but then can't use it as it's being handled before dispatcher even gets to your portlet.

      I did try implementing the HandlerExceptionresolver with success, but was concerned that I would loose all the built in exception handling that spring offers out of the box, I did also find references to adding the exceptionHandler in config, but like you mentioned, it wipes out the default and and requires manual entry.

      In the end I decided to implement the size validation myself, it's only 3 lines of code, so not that greater deal, and works like a charm. you mentioned that I would only have to implement 1 method for the resolver, but for the portlet version of the resolver there is 2 mthods. one for action request, and one for resource request.

      Thanks again for your reply

      mARK

      Comment

      Working...
      X