Bug 809422 - Services Management - Invalid parameters lead to methods failing with exceptions
Services Management - Invalid parameters lead to methods failing with exceptions
Status: VERIFIED
Product: JBoss Enterprise Portal Platform 6
Classification: JBoss
Component: Portal (Show other bugs)
6.0.x
i686 Linux
low Severity low
: ER01
: 6.1.1
Assigned To: Peter Palaga
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-03 06:31 EDT by Miroslav Cupák
Modified: 2015-01-05 20:30 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
The way Service Management method errors are displayed in the UI has been improved to better describe the error. Messages in the log file were descriptive, however messages displayed in the UI were not quite descriptive enough. The messages displayed are now more useful to the user.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Extract from the server log produced by loadConfiguration method. (9.60 KB, text/x-log)
2012-04-03 06:34 EDT, Miroslav Cupák
no flags Details
Extract from the server log produced by a get method in templatestatistics section. (9.70 KB, text/x-log)
2012-04-03 06:35 EDT, Miroslav Cupák
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker GTNPORTAL-3292 Minor Resolved Services Management - Invalid parameters lead to methods failing with exceptions 2014-02-20 04:36:58 EST

  None (edit)
Description Miroslav Cupák 2012-04-03 06:31:22 EDT
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.

Steps to Reproduce:
1. Sign in as "root".
2. Go to "Group" > "Administration" > "Services Management".
3. Switch to e.g. "templatestatistics".
4. Hit "Run" next to any of the methods.
  
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).
Comment 1 Miroslav Cupák 2012-04-03 06:34:38 EDT
Created attachment 574817 [details]
Extract from the server log produced by loadConfiguration method.
Comment 2 Miroslav Cupák 2012-04-03 06:35:32 EDT
Created attachment 574818 [details]
Extract from the server log produced by a get method in templatestatistics section.
Comment 4 Jared MORGAN 2013-11-05 18:31:30 EST
This could be a candidate for an Enhancement Release Note as it improves the way the log messages are recorded. Setting Flag to ? and provided draft release notes.
Comment 7 Peter Palaga 2013-12-17 15:08:16 EST
Nicolas agreed to fix this in WS. Fixing in WS means that it is too late for JBoss Portal 6.1.1.
Comment 8 Peter Palaga 2013-12-19 07:18:06 EST
I improved the pull request in upstream in accordance with the proposal of Nicolas Filotto.

https://github.com/gatein/gatein-portal/pull/741

The propagation of errors to the client is fixed in org.exoplatform.management.data.RestResource through making the methods return RestResource rather than Object.
Further, I have added parameter checks throwinf IllegalArgumentException on "id empty" and "object with the given id does not exist" in following methods:
org.exoplatform.groovyscript.text.TemplateService.reloadTemplate(String)
org.exoplatform.groovyscript.text.TemplateStatisticService.getMaxTime(String)
org.exoplatform.groovyscript.text.TemplateStatisticService.getMinTime(String)
org.exoplatform.groovyscript.text.TemplateStatisticService.getExecutionCount(String)
org.exoplatform.groovyscript.text.TemplateStatisticService.getAverageTime(String)
org.exoplatform.portal.application.ApplicationStatisticService.getMaxTime(String)
org.exoplatform.portal.application.ApplicationStatisticService.getMinTime(String)
org.exoplatform.portal.application.ApplicationStatisticService.getAverageTime(String)
org.exoplatform.portal.application.ApplicationStatisticService.getExecutionCount(String)
org.exoplatform.portal.application.PortalStatisticService.getMaxTime(String)
org.exoplatform.portal.application.PortalStatisticService.getMinTime(String)
org.exoplatform.portal.application.PortalStatisticService.getAverageTime(String)
org.exoplatform.portal.application.PortalStatisticService.getThroughput(String)
org.exoplatform.portal.application.PortalStatisticService.getExecutionCount(String)
Finally, the in JavaScript on the client side, I have added a piece of code that shows the error message (if available) to the user.
Comment 9 Jared MORGAN 2014-02-16 18:14:31 EST
I'm setting the Release Note aspect of this issue to ?

This is so a release note is not included for this issue prematurely before the issue is resolved.

Set needinfo to aakanksha or I if this issue passes QE before 6.1.1 is released, and we'll set the flag so the release note is included.
Comment 11 Tomas Kyjovsky 2014-02-18 11:28:08 EST
Verified with 6.1.1.CR1.

Note You need to log in before you can comment on or make changes to this bug.