cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <>
Subject Re: Refactoring and correction of error notification
Date Sun, 30 Dec 2001 14:54:20 GMT
----- Original Message -----
From: "Sylvain Wallez" <>
To: <>
Sent: Sunday, December 30, 2001 2:57 PM
Subject: Re: Refactoring and correction of error notification

> Nicola Ken Barozzi wrote:
> > ----- Original Message -----
> > From: "Sylvain Wallez" <>
> > To: <>
> > 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
> >>>>  way
> >>>>  warnings (from Xalan or Xerces 4 example) can be appended to this
> >>>>  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
> 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
> > the admin. The logs are not sufficient. Besides, using debug logging
> > 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
> > to the user. Before being sent to the Generator, the NotificableObjects
> > "filtered" by a NotifyingBuilder (avalon component) that can output
> > 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
> > or that a DB error occurred. Users sometimes can react much better and
> > 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.

This is a very good point. In fact in the first patch, I put
NOTIFYING_OBJECT (one) in the objectmodel, but later changed my mind again.
Quite some time ago, when Actions were not there and Stefano was still
wrestling with what a sitemap should look like, there was a RT (from Stefano
I think) of a parallel pipeline that caches all "notifications" from the
main pipeline and basically does what is in the patch.
The reason is that IMO there are two types of Cocoon developers:
those who develop Cocoon and
those who develop -with- Cocoon.
Now the second ones are our real customers. And when I told some of them to
look at the logs, they started laughing and turned away, saying that Cocoon
was still a hacker-made-alpha-of-some-sort.
Also ones who do use Cocoon for developing are annoyed by this.
If I'm developing an app with Cocoon, this type of quick info is invaluable.
Also, warnings I talk about are not warnings that are now logged, but
warnings that have to do with the current document-pipeline instance, ie are
about developing *with* cocoon. Xalan outputs warnings, where are they in
Cocoon? Should they be in the logs? I don't think so.

> Also, propagating the Notifyings object down to low-level objects
> (e.g. TraxErrorHandler) may be really difficult.

This is why I put a list of Notifying Objects in the Env. You don't need to
propagate, just add th that list.
Then propagate the (Cascading)Exception as always.

> 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.

This is the alternative that I also thought about, but I repeat that for me
the errors-warnings I'm talking about are different. IMNSHO no "normal"
programmer should have to see Cocoon internals. And the logs at any level
are full of them.

> >>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.

Wrong. The enviorment object is always there, that's what the view should be
When I ask a ?cocoon-view=notifications I should get all warnings-info of
the pipeline; handle-errors just serializes them with a common DTD, because
when there's an error they are all that's left to output.

> >>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 ?

Could be. If programmers use Cocoon to make a webapp, maybe I want to know
how many are using deprecated features.
But the main reason is not for send a mail to a sysadmin, I will not trigger
the handle errors if the notification view is not requested.

> > As for choosing a particular generator I thought the discussion was
> > 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.

Have you read the previous discussions?
The basic thing is that if you use a fixed DTD, whatever -i repeat whatever-
error comes in, you can display it with the same stylesheet. Say I'm using a
XSP component that uses his exception with his XML?
Do I have to write a stylesheet for it especially?
Isn't this FS?

> 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 ?

Sorry but I don't understand.
Each extraDescription is basically an <explanation/>.
Stacktraces are included as extra.
You can put in as many as you wish.
And use your Builder to build the one you want from all the Notifications.
Here is your XML using the current DTD:
  <error:notify error:type="error"
    <error:title>An error occurred</error:title>
    <error:message>Blah message</error:message>
    <error:description>Blah description</error:description>
    <error:extra error:description="explanation">First
    <error:extra error:description="explanation">Second
    <error:extra error:description="stacktrace"></error:extra>

I don't see that big difference.
The DTD is not perfect, but simply extensible.
I don't say I love it, but since it works ok, why break compatibility?

> >>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.

Hey, we have Selectors, use those.
I want to take away the double handle-errors pipeline, it's useless.
We should use the normal Cocoon methods if possible, so Selectors in this

> 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 :)

;-) Well, the type was originally intended to be as various as you say. The
default values are just a proposal, in fact I kept is as a String.
So yes, you can use that value for the Selectors if you want, but there is
no new semantics in this use.

> > 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 ;)

Don't worry, I'm much more modest than you ;-)

> 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.

FS. Please, do read the archives (maybe you should go back quite a bit). And
give me an example that explains how the current proposal is clearly
inadeguate in solving the problem. If nobody in all this time touted it as
inadeguate, it's not so bad, isn't it ;-)

> - 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 ?

Difficult to implement? You don't chain notifications, you append them to
the NOTIFYING_OBJECTS in the env. You chain exceptions. And if they're
Notifying, even better.
As for filtering, well you can delete the view and block them with a fixed
stylesheet... but for performance reasons I would propose a switch in
web-inf and-or in cocoon-xconf like logging.
People should use logging for Cocoon debugging.
They should use notifying allways: the Notifying interface is just an
augmentation that can be also showed in logging, while the notification
mechanism is basically for developers who use Cocoon.


> Cheers,
> Sylvain.
> > Ciao,
> > Ken
> BTW, what is your first name : Nicola or Ken ?

Legally my first name is Nicola Ken, because in my town they deleted all
second names for their informative system :-/
But really it's Nicola and Ken the second.
My full name is Nicola Ken Barozzi.
I'm Italian but my father worked in Japan for 20 years (I was there 5) so he
gave me a japanese name also (Ken).
The funny thing is that here they call me Ken, in Japan Nico(l|r)a!
Whatever you prefer :-)

Nicola Ken Barozzi       

These are the days of miracle and wonder...
 don't cry baby, don't cry...
                                                  Paul Simon

To unsubscribe, e-mail:
For additional commands, email:

View raw message