Re: exception handling / first failure diagnostic capture
B.J. Reed wrote: I would be interested in working on the exception handling / first failure diagnostics, but I need some help to get started. I guess I envision the following: 1) grouping of all message strings into a common place (or perhaps a specific place within each plugin/module), probably using resource bundles or something similar to make it easier to change languages and giving each message its own unique id. 2) What kind of diagnostic information are we looking for? 3) create a new class GeronimoException at the point of failure and throw these around (if we need to rethrow). This class would have the extra diagnostic info in it and would get the proper message string. Hello BJ, Excellent ideas that would make Geronimo more servicable and accessible to many users. 1a) It seems best that each plugin would have its own message properties file or bindle which would contain messages related to that plugin. Each property file could be appended with language and country locale to make the messages translatable. This is all standard Java internationalization. 1b) Each message having a unique prefix would help support teams identify problems and allow Geronimo to provide web pages with problem resolution hints. I am strong believer in giving customer self helps to take load off the support teams. 2) Diagnostic information. It seems to me at a minimum you need the exception and its message, the source of the exception (package and class) and a stack trace, and perhaps a toString listing of the object that throws the exception. You also might want to give a unique ID to each dump so that if there is an exception that happens repeatedly, maybe you can summarize how often it happens. This is something many other app servers provide. 3) New GeronimoException would be one way of gathering failure info (make sure you record the cause so getCause is useful). Another way would have a special JSR-47 log and a some APIs to trigger the recording of this info. Please reply with further ideas. I can help with the implementation if you like. Thanks, Dan Becker -- View this message in context: http://www.nabble.com/exception-handling---first-failure-diagnostic-capture-tp15505337s134p15549061.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: Exception Handling in Console
Hi Rakesh, Sorry for the delay. I will try to take a look today. Best wishes, Paul On 12/15/06, Rakesh Midha [EMAIL PROTECTED] wrote: Hello Paul, Vamsi and others Can you please have a look at mail below and coorsponding JIRA's so tat I can proceed and fix other parts of console. Thanks Rakesh -- Forwarded message -- From: Rakesh Midha [EMAIL PROTECTED] Date: Dec 4, 2006 6:17 PM Subject: Re: Exception Handling in Console To: dev@geronimo.apache.org I created a JIRA https://issues.apache.org/jira/browse/GERONIMO-2621 to handle this improvement. Paul, I am not sure till what level are you proposing to use dojo widgets. I made a changes required for this problem for web console deploy portlet. Following your hint about using dojo widget I used dojo dialog box to show detailed exception trace. Have a look at changes provided in Patch https://issues.apache.org/jira/secure/attachment/12346339/deployExp.patch in https://issues.apache.org/jira/browse/GERONIMO-2621 This patch provides a protocol proposed for exception handling in console. Apart from exception handling methods are provided to printInfo, printWarning, printErrors and printFullError. For now only web console part is taken care of, if we want to support logging using same setup this can be easily added. Paul, about your question about life span, I am in favour of giving a error/info message for life span of single request. I feel providing a explicitly dismissed by the user is an additional hassle going against the motive of ease of use. Anyways apart from being printed on web console, messages will continue to go to server log and further down the timeline if user wants details he can also look at logs. What do you say? Please have a look at patch and decide the path we are taking so that I can make changes in all other portlets. Thanks Rakesh On 12/1/06, Paul McMahan [EMAIL PROTECTED] wrote: I agree that exception handling is currently not one of the console's strong suits. I have been thinking about introducing a new dojo widget for displaying messages in the console. It would be based on the dialog widget which you can see by clicking the show dialog anchor in this page: http://archive.dojotoolkit.org/nightly/tests/widget/test_Dialog.html The design that you proposed sounds reasonable and would also provide a first step for introducing the message widget described above by wrapping the exceptions and providing a place to display them. I'm in favor of creating a JIRA for this. One question I have is what do you consider life span for an error message? If it only has the duration of a single request/response then it would be lost by the user refreshing the page, clicking the 'help' link, or using the minimize/maximize controls your GERONIMO-795 patch would introduce. Seems like error messages need to be explicitly dismissed by the user. Also, would your approach continue to log the message in the server log or just display it to the user? Best wishes, Paul On 12/1/06, Rakesh Midha [EMAIL PROTECTED] wrote: Hello In case I get any exception or error condition in Console, the nothing is printed on web console and huge stack trace is printed on server console. Only thing done in the name of Exception handling in all the portlets is throw PortletException I somehow don't like this behavior of console. As a console user I don't want to go and see server stacktrace, if there is some error I should atleast be informed in console. I think everytime there is a error or exception in console, it should be printed in either exception page in webconsole, or in header of portlet view page. This is done to some extent in configManager and CA part of console. But not in uniform way. This is what I am proposing for Exception handling in console : 1. Create a ConsoleException.java which extends PortletException, this class will have overridden printStackTrace(PrintWriter), which will set attribute required in _ConsoleException.jsp apart from printing the stack on PrintWriter. 2. Create _ConsoleException.jsp which should be included in all portlet, this jsp will be responsible to print a short message and long stack trace. (with a toggle button to view and hide long stack trace) 3. All Portlet classes should throw ConsoleException instead of PortletException I think this will be nice and cleaner way to handle the console problems. I am working on https://issues.apache.org/jira/browse/GERONIMO-2578 to solve the same problem in deploy new app portlet. Once don't I will supply the patch and open another JIRA to do this activity for all the portlets. Please let me know if I am thinking right or missing something. Your views and comments will be appreciated. Thanks Rakesh
Re: Exception Handling in Console
I created a JIRA https://issues.apache.org/jira/browse/GERONIMO-2621 to handle this improvement. Paul, I am not sure till what level are you proposing to use dojo widgets. I made a changes required for this problem for web console deploy portlet. Following your hint about using dojo widget I used dojo dialog box to show detailed exception trace. Have a look at changes provided in Patch https://issues.apache.org/jira/secure/attachment/12346339/deployExp.patch in https://issues.apache.org/jira/browse/GERONIMO-2621 This patch provides a protocol proposed for exception handling in console. Apart from exception handling methods are provided to printInfo, printWarning, printErrors and printFullError. For now only web console part is taken care of, if we want to support logging using same setup this can be easily added. Paul, about your question about life span, I am in favour of giving a error/info message for life span of single request. I feel providing a explicitly dismissed by the user is an additional hassle going against the motive of ease of use. Anyways apart from being printed on web console, messages will continue to go to server log and further down the timeline if user wants details he can also look at logs. What do you say? Please have a look at patch and decide the path we are taking so that I can make changes in all other portlets. Thanks Rakesh On 12/1/06, Paul McMahan [EMAIL PROTECTED] wrote: I agree that exception handling is currently not one of the console's strong suits. I have been thinking about introducing a new dojo widget for displaying messages in the console. It would be based on the dialog widget which you can see by clicking the show dialog anchor in this page: http://archive.dojotoolkit.org/nightly/tests/widget/test_Dialog.html The design that you proposed sounds reasonable and would also provide a first step for introducing the message widget described above by wrapping the exceptions and providing a place to display them. I'm in favor of creating a JIRA for this. One question I have is what do you consider life span for an error message? If it only has the duration of a single request/response then it would be lost by the user refreshing the page, clicking the 'help' link, or using the minimize/maximize controls your GERONIMO-795 patch would introduce. Seems like error messages need to be explicitly dismissed by the user. Also, would your approach continue to log the message in the server log or just display it to the user? Best wishes, Paul On 12/1/06, Rakesh Midha [EMAIL PROTECTED] wrote: Hello In case I get any exception or error condition in Console, the nothing is printed on web console and huge stack trace is printed on server console. Only thing done in the name of Exception handling in all the portlets is throw PortletException I somehow don't like this behavior of console. As a console user I don't want to go and see server stacktrace, if there is some error I should atleast be informed in console. I think everytime there is a error or exception in console, it should be printed in either exception page in webconsole, or in header of portlet view page. This is done to some extent in configManager and CA part of console. But not in uniform way. This is what I am proposing for Exception handling in console : 1. Create a ConsoleException.java which extends PortletException, this class will have overridden printStackTrace(PrintWriter), which will set attribute required in _ConsoleException.jsp apart from printing the stack on PrintWriter. 2. Create _ConsoleException.jsp which should be included in all portlet, this jsp will be responsible to print a short message and long stack trace. (with a toggle button to view and hide long stack trace) 3. All Portlet classes should throw ConsoleException instead of PortletException I think this will be nice and cleaner way to handle the console problems. I am working on https://issues.apache.org/jira/browse/GERONIMO-2578 to solve the same problem in deploy new app portlet. Once don't I will supply the patch and open another JIRA to do this activity for all the portlets. Please let me know if I am thinking right or missing something. Your views and comments will be appreciated. Thanks Rakesh
Re: Exception Handling in Console
Hi Rakesh, Even I noticed this lack of error reporting in console. So, I tried to make it some what better in the newly added CA Portlet. We definitely need something uniform across all the portlets. Why don't you create a JIRA for this? --vamsi On 12/1/06, Rakesh Midha [EMAIL PROTECTED] wrote: Hello In case I get any exception or error condition in Console, the nothing is printed on web console and huge stack trace is printed on server console. Only thing done in the name of Exception handling in all the portlets is throw PortletException I somehow don't like this behavior of console. As a console user I don't want to go and see server stacktrace, if there is some error I should atleast be informed in console. I think everytime there is a error or exception in console, it should be printed in either exception page in webconsole, or in header of portlet view page. This is done to some extent in configManager and CA part of console. But not in uniform way. This is what I am proposing for Exception handling in console : 1. Create a ConsoleException.java which extends PortletException, this class will have overridden printStackTrace(PrintWriter), which will set attribute required in _ConsoleException.jsp apart from printing the stack on PrintWriter. 2. Create _ConsoleException.jsp which should be included in all portlet, this jsp will be responsible to print a short message and long stack trace. (with a toggle button to view and hide long stack trace) 3. All Portlet classes should throw ConsoleException instead of PortletException I think this will be nice and cleaner way to handle the console problems. I am working on https://issues.apache.org/jira/browse/GERONIMO-2578 to solve the same problem in deploy new app portlet. Once don't I will supply the patch and open another JIRA to do this activity for all the portlets. Please let me know if I am thinking right or missing something. Your views and comments will be appreciated. Thanks Rakesh
Re: Exception Handling in Console
I agree that exception handling is currently not one of the console's strong suits. I have been thinking about introducing a new dojo widget for displaying messages in the console. It would be based on the dialog widget which you can see by clicking the show dialog anchor in this page: http://archive.dojotoolkit.org/nightly/tests/widget/test_Dialog.html The design that you proposed sounds reasonable and would also provide a first step for introducing the message widget described above by wrapping the exceptions and providing a place to display them. I'm in favor of creating a JIRA for this. One question I have is what do you consider life span for an error message? If it only has the duration of a single request/response then it would be lost by the user refreshing the page, clicking the 'help' link, or using the minimize/maximize controls your GERONIMO-795 patch would introduce. Seems like error messages need to be explicitly dismissed by the user. Also, would your approach continue to log the message in the server log or just display it to the user? Best wishes, Paul On 12/1/06, Rakesh Midha [EMAIL PROTECTED] wrote: Hello In case I get any exception or error condition in Console, the nothing is printed on web console and huge stack trace is printed on server console. Only thing done in the name of Exception handling in all the portlets is throw PortletException I somehow don't like this behavior of console. As a console user I don't want to go and see server stacktrace, if there is some error I should atleast be informed in console. I think everytime there is a error or exception in console, it should be printed in either exception page in webconsole, or in header of portlet view page. This is done to some extent in configManager and CA part of console. But not in uniform way. This is what I am proposing for Exception handling in console : 1. Create a ConsoleException.java which extends PortletException, this class will have overridden printStackTrace(PrintWriter), which will set attribute required in _ConsoleException.jsp apart from printing the stack on PrintWriter. 2. Create _ConsoleException.jsp which should be included in all portlet, this jsp will be responsible to print a short message and long stack trace. (with a toggle button to view and hide long stack trace) 3. All Portlet classes should throw ConsoleException instead of PortletException I think this will be nice and cleaner way to handle the console problems. I am working on https://issues.apache.org/jira/browse/GERONIMO-2578 to solve the same problem in deploy new app portlet. Once don't I will supply the patch and open another JIRA to do this activity for all the portlets. Please let me know if I am thinking right or missing something. Your views and comments will be appreciated. Thanks Rakesh
Re: Exception handling
There is nothing to really help you doing that. But you're right, it may be worth creating an EIP pattern for that. Could you please raise a JIRA ? If you have any time to write this small component, please do ;) On 7/27/06, travi [EMAIL PROTECTED] wrote: If i need to route message based on if an error occurs or not what do I do? Example I pass a message m0 to component c1, then pass message from component c1 to c2, if c2 returns an error I want to pass the contents in m0 to component c3. How can I do this, is there some EIP pattern to do this or do I need to write some custom component. Thanks. -- View this message in context: http://www.nabble.com/Exception-handling-tf2011368.html#a5527124 Sent from the ServiceMix - Dev forum at Nabble.com. -- Cheers, Guillaume Nodet
