cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Refactoring and correction of error notification
Date Sun, 30 Dec 2001 13:57:37 GMT
Nicola Ken Barozzi wrote:

> ----- Original Message -----
> From: "Sylvain Wallez" <sylvain.wallez@anyware-tech.com>
> To: <cocoon-dev@xml.apache.org>
> Sent: Saturday, December 29, 2001 7:31 PM
> Subject: Re: Refactoring and correction of error notification
> 
<snip/>


>>>>3- Added to the objectModel (in sitemap.xsl) from the beginning of
>>>>  processing a NotifyingObjects object that can contain any Notifying
>>>>  object  that any component in the sitemap wants to add to it. In this
>>>>  way
>>>>  warnings (from Xalan or Xerces 4 example) can be appended to this and
>>>>  reported at the end with a notifications-view.
>>>>
>>Nicola, could you please elaborate more about this ? Warnings are
>>already output in the logs. What would be the purpose/interest of a
>>notifications-view ?
>>
> 
> For developers.
> 
> 
>>Notifications seem too developer-oriented to me : they give a direct
>>visual feedback of a failure in the application which is good at
>>development time but really bad in production.
>>
> 
> Well, content-view and links-view is not very user oriented, aren't they?


Mmmh. Yes and no : they aren't directly visible to the user, but are 
used by components that are really user-oriented, like the Lucene indexer.

Views also have a broader potential than content and links. We can have 
PDF-view, WAP-view, Excel-view, etc. Maybe the current use of views is 
limited by the fact that we can only specify them using the 
"cocoon-view" parameter. It would be good to have some matchers to 
select the view in the sitemap. But this is another discussion.


>>In our apps, we have two running modes : development and production. In
>>development mode, exceptions are displayed in the browser using either a
>>special resource (for "ExplainableExceptions" I already talked about),
>>or Cocoon's default error handling.
>>
>>In production mode, the user never sees such errors. Instead a polite
>>message is written : "The application encountered and error which
>>prevents the handling of your request. If this persists, please contact
>>the sysadmin". Since the error is in the logs, there's no problem to
>>find it afterwards.
>>
> 
> Many asked me to make it possible for the error pipeline to send a mail to
> the admin. The logs are not sufficient. Besides, using debug logging really
> bogs the server down, while error logging only not always shows what the
> error is about.


Sure DEBUG log hinders performances. Setting the log level to WARN gives 
you all errors and warnings without much speed loss.


> 
>>And IMHO, the end-user *should not* see these errors :
>>
> 
> Never stated the contrary.
> 
> 
>>- it can't do anything with them. They're only useful to someone that
>>can act upon the error : a sysadmin or a developper.
>>- displaying a stacktrace is catastrophic from a marketing point of
>>view. When receiving crash screens, people either ROFL or insult the
>>computer, but all leave the site because they don't trust it anymore.
>>- some security-picky people may also consider that a stacktrace can
>>expose sensitive information.
>>
> 
> I agree, but I repeat, never said the contrary.
> 
> But being the error in the pipeline, it is possible to output sensitive info
> to the user. Before being sent to the Generator, the NotificableObjects is
> "filtered" by a NotifyingBuilder (avalon component) that can output whatever
> it wants based on those infos.
> For example, it can create a Notifying that says that the service is down or
> that a generic error occurred or that the user must start from the homepage,
> or that a DB error occurred. Users sometimes can react much better and not
> leave the site if the explanation is not simply -shit-it-went-wrong-.


Sure. Giving access to Notifying to actions/selectors/matchers is an 
important step to allow customized error pages.


> And then the error can be sent anywhere by email, or logged to a special
> cat, or whatever, but with sensitive info that is not only the last
> exception or exception chain but eventual warnings happened down the
> pipeline.


Does this mean warnings should go through Notifyings ? This sets up a 
parallel logging mechanism, while we already have a powerful unified 
one. Also, propagating the Notifyings object down to low-level objects 
(e.g. TraxErrorHandler) may be really difficult.

I you really want to gather all warnings that occured during a request 
to send them in case of error, LogKit offers all that is needed : we can 
write a special LogTarget that buffers all warning/errors for a request 
so that they can be handled as a whole when needed.


>>Sorry for being so critical.
>>
> 
> I'm happy for it, finally some interest ;-)


I am the only one to be interested in this (apart you and Peter Royal) ?


> 
>>Maybe I don't catch the real interest of
>>this stuff, but I don't see the need for notifications other than
>>exceptions and find all this overcomplicated for just generating XML out
>>of an exception.
>>
> 
> Not only exceptions, also warnings.


Yep. But the collected warnings are used only if there has been an 
exception that is handled by a <handle-errors> in the sitemap.


>>The good thing is that information about the error is now put in the
>>object model. But what about just placing the Throwable in the object
>>model and let the error handling pipeline decide what to do with it,
>>including choosing a particular generator ?
>>
> 
> Throwable is not enough for info (your Explainable stuff proves it) and
> besides, how do you notify things that are not errors?


Can you explain what "notify things" means if there has been no error ? 
You will not display an error page or send a mail to a sysadmin for 
warnings, will you ?


> As for choosing a particular generator I thought the discussion was closed:
> fixed DTD was deemed best on this list more than once. Why would you need a
> custom generator? Please read the archives and elaborate on those
> discussions if the reasons are not enough for you.


Where does Cocoon impose DTDs on the produced content ? There are fixed 
DTDs for xdocs, but this is more a usage of Cocoon than Cocoon itself. 
Some transformers impose DTDs (e.g. i18n, sql) but this is because they 
have to know on which elements/attributes they should act.

The fixed error DTD is a good thing for objects that don't know how to 
render themselves as XML (i.e. most of them). But taking again my 
ExplainableException as an example : it implements XMLizable and 
outpouts the following XML :
<error>
   <message>Blah message</message>
   <explanations>
     <explanation>First explanation</explanation>
     <explanation>Second explanation</explanation>
   </explanations>
   <stacktrace>
     ...
   </stacktrace>
</error>

You can notice the several <explanation> elements. This is because an 
error can have several possible causes, and they are later formatted as 
an HTML list. How could I do that with the flat extraDescription Map of 
Notifying ?


>>Let the patch go in, but let's continue the discussion. I had some
>>thoughts about an enhanced <handle-errors> that I'll sum up in a
>>RT/Proposal soon.


Briefly : for now, we only have type="500" or type="404" handle-erros. 
I'd like to be able to define new types to allow things like :

<map:handle-errors type="access-denied">
   <map:act type="log-intrusion"/>
   <map:redirect-to uri="login.html"/>
</map:handle-errors>

<map:handle-errors type="too-many-users">
   <map:generate type="serverpages" src="overloaded.xsp"/>
   <map:transform src="simple2html.xsl"/>
   <map:serialize/>
</map:handle-errors>

<map:handle-errors type="explainable">
   <map:generate type="explain"/>
   <map:transform src="explain2html"/>
   <map:serialize/>
</map:handle-errors>

<map:handle-errors>
   <map:generate type="notification"/>
   <map:transform src="error2html.xsl"/>
   <map:serialize/>
</map:handle-errors>

The values for "type" could be associated to exception classes in 
map:components or in cocoon.xconf.

Note that this exception/type mapping could be a configuration of 
NotifyingBuilder for setting the value returned by Notifying.getType() 
instead of just "error". But only if we come to a consensus on 
Notifications :)

> Why don't we start now, I'm still "warm" and can keep up! :-)
> Pleeease, don't leave me waiting too long ;-)


Let me make things clear : I sometimes start hot discussions, but that's 
not because I like fighting (rather the contrary) : I know by experience 
that when I'm not comfortable with something but cannot sat why at the 
moment, it most always proves to be justified on the long-run. Sorry for 
being so un-modest ;)

To summarize what I'm not comfortable with :
- fixed DTD and generator. Use this only as a fallback : if an exception 
is XMLizable, use this feature.
- Notifyings for chaining warnings : it will be difficult to implement, 
cannot be filtered like getLogger().isWarnEnabled(), and will confuse 
people : should they use logger or notifying ?

Cheers,
Sylvain.


> Ciao,
> Ken


BTW, what is your first name : Nicola or Ken ?


> --
> Nicola Ken Barozzi                 xml-cocoon@nicolaken.com
> 
> These are the days of miracle and wonder...
>           ...so don't cry baby, don't cry...
>                                                   Paul Simon
> 
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message