Enterprise Client Community

When an error occurs, the user is informed basically with some text and a java stacktrace.

We would like to change this. The text should be more user friendly. We would like to add some links which

(1) allow an attempt to reconnect to the session (this should be possible)

(2) something like save the error message + stacktrace + possibly other client state, plus the most recent part of the client log, to a temporary location, and prepare an email to send this information to our help desk (or if mail client cannot be started directly, offer a detailed description on what files to attach). It seems important that the log be made accessible via such a procedure since the java console (webstart/applet) is not readily accessible for normal users.

I know that the layout of the error page can be changed (some start parameter "clienterrorscreen", defining a different xml layout), and we can probably implement (1), but this is definitely not sufficient, since the algorithm provides only very basic "real" information (error message + stack) to include into this screen, so any beautiful layout we might implement is not too helpful.

Maybe you (or others) find such thing also useful, so we might put this onto the big captain casa wish list (and find it under the Christmas tree, due in a dozen weeks);

or at least (--> this finally is a small dev request; ...especially since our detailed requirements are not yet fixed; so that we might even not find under the tree exactly what we wish...) please allow a better possibility to customize the behavior, not just provide different layout xml, but instead allow to provide the name of a handler class which is to implement some interface (with e.g. public String getLayoutForError(Throwable t, String contextMessage), where we can take over the task and return the xml to display, and make it as complicated or user friendly as we see fit).

For server side errors we can probably live with the current handling, defining the error page with client parameter "errorscreen", although passing this through our interface would not harm either so that we might pass client information (e.g. log, other state) into the roundtrip to the error page.

Manfred

p.s. as for the client log, maybe you know of some logger implementation where the the data is not just output to console/file, but the latest part (up to some configurable size) is also available in memory, to include in the above processing. If not, this is probably not too difficult to implement...

Hi,

this issue is not forgotten... we are just going through what we can do. In principal we receive the application crash info (latest) at client side. So we provided the possibility to open up a rescue page that you can define on your own (the one you mention).

We are bit afraid of building a "wonderful" error reaction page, because we believe it will neve fit to your needs (or: if it fulfills your needs, then it will not fulfill other ones' needs), it's just to specific to the application.

E.g.:
..."save log" - is is really the CaptainCasa log, typically this is not really useful from application point of view
..."save the information" - where? File or DB?
..."send mail" - who configures mail server etc. settings

So, what you propose "provide extended interface, name of handler class" etc. is the way to go.

In principal I think the specifc handler class is the managed bean class of the special error page that you define... the "only" thing you may want to know is all the error information. This you can get via:

Code:

 DefaultScreens.getSessionAccess().getShowServerError().getText()
 DefaultScreens.getSessionAccess().getShowServerError().getThrowable()

About logging: you can add a log output delegator to the CaptainCasa logging (e.g. delegate log messages into you own log, interface ILogOutput). We propose to use this feature to feed CaptainCasa log information into your own application log - then you are "master of your log" yourself and can present a better "crash log" then the raw CaptainCasa log.

What dou you think?

Björn

regarding server errors this is probably enough; and we are just about to assemble some elements to provide the required information.
Will send you some more issues encountered with the "try-to-reconnect-to-current-session" stuff.

Next thing is client triggered errors (typically connection errors), where currently the possibilities are rather limited. The log mentioned was the log of the client, typically written onto (invisible) stdout of the client.
This was mainly what we had in mind when looking for a developer's hook (of course this will require client programming; but then this is likely to be the only option since every one has different requirements).

regards
Manfred