[gatein-issues] [JBoss JIRA] (GTNPORTAL-3292) Services Management - Invalid parameters lead to methods failing with exceptions

[Peter Palaga (JIRA)]

    [ https://issues.jboss.org/browse/GTNPORTAL-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932124#comment-12932124 ] 

Peter Palaga edited comment on GTNPORTAL-3292 at 12/17/13 11:49 AM:
--------------------------------------------------------------------

This issue is valid with the present GateIn master.

After a little bit of debugging, I can state the following:

(1) The {{NullPointerException}} is thrown in {{TemplateStatisticService.getExecutionCount(TemplateStatisticService.java:120)}}
(2) The {{NullPointerException}} is catched in {{RestResource.safeInvoke(MethodInvoker, Map<String, List<String>>)}} where {{Response.serverError()}} is returned, see [here|https://github.com/gatein/gatein-portal/blob/master/component/management/src/main/java/org/exoplatform/management/data/RestResource.java#L223]. This is probably incorrect, {{Response.serverError().build()}} or {{Response.serverError().entity(e.getMessage()).build()}} would probably be better.
(3) However, this return value is not handled properly in {{RequestDispatcher.processResponse(...)}}. There, the result is handled only based on the expected return type, in this case {{java.lang.Object}}, which boils down to the last {{else}}, see [here|https://github.com/exoplatform/ws/blob/master/exo.ws.rest.core/src/main/java/org/exoplatform/services/rest/impl/RequestDispatcher.java#L763].

Hence, the main question is if this can be fixed in {{RequestDispatcher}}. Could perhaps the {{Resource}} type check ([here|https://github.com/exoplatform/ws/blob/master/exo.ws.rest.core/src/main/java/org/exoplatform/services/rest/impl/RequestDispatcher.java#L747]) be applied also on {{o}}, like this:
{code}
else if (Response.class.isAssignableFrom(returnType) || o instanceof Response)
{code}
                
      was (Author: ppalaga):
    This issue is valid with the present GateIn master.

After a little bit of debugging, I can state the following:

(1) The {{NullPointerException}} is thrown in {{TemplateStatisticService.getExecutionCount(TemplateStatisticService.java:120)}}
(2) The {{NullPointerException}} is catched in {{RestResource.safeInvoke(MethodInvoker, Map<String, List<String>>)}} where {{Response.serverError()}} is returned, see [here|https://github.com/gatein/gatein-portal/blob/master/component/management/src/main/java/org/exoplatform/management/data/RestResource.java#L223]. This is probably incorrect, {{Response.serverError().build()}} or {{Response.serverError().entity(e.getMessage()).build()}} would probably be better.
(3) However, this return value is not handled properly in {{RequestDispatcher.processResponse(...)}}. There, the result is handled only based on the expected return type, in this case {{java.lang.Object}}, which boils down to the last {{else}}, see [here|https://github.com/exoplatform/ws/blob/master/exo.ws.rest.core/src/main/java/org/exoplatform/services/rest/impl/RequestDispatcher.java#L763].

Hence, the main question is if this can be fixed in {{RequestDispatcher}}.
                  
> Services Management - Invalid parameters lead to methods failing with exceptions
> --------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3292
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3292
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.3.Final
>            Reporter: Miroslav Cupak
>            Assignee: Peter Palaga
>            Priority: Minor
>
> Description of problem:
> Methods in "templatestatistics" and "portalcontroller" section of the Services Management gadget fail with exception (NPE/MalformedURLException) if they are called with an invalid parameter. The exception is visible in the server log, but in the UI, you only see the message "Method's executed, return no result", which might be a bit confusing.
> For example methods "reloadConfiguration" without a parameter and "loadConfiguration" called with an invalid path both lead to the same message being shown in the gadget, whereas only one of them really failed with exception.
>   
> Actual results:
> Exception is logged, message "Method's executed, return no result" is displayed.
> Expected results:
> It would be nice to have these two situations (failure/no return value) distinguished in a consistent way (methods in other sections don't log an exception and usually return at least some value).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira