cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <baro...@nicolaken.com>
Subject Re: Refactoring and correction of error notification
Date Sat, 29 Dec 2001 18:58:01 GMT

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


> giacomo wrote:
>
> > Ken,
> >
> > Is this patch ready to be applied before I restructure the CVS repos?
> >
> > Giacomo
> >
> > On Thu, 27 Dec 2001, Nicola Ken Barozzi wrote:
> >
> >
> >>Attatched is a first release of a possible patch to Cocoon HEAD for the
> >>correction of the error notification stuff.
> >>
> >>I've not yet submitted it as a patch because there are some minor
problems
> >>that I still need to solve before releasing it as such.
> >>
> >>This patch contains code and suggestions from Peter Royal whom I thank
for
> >>the valuable and kind cooperation.
> >>
> >>What has been done:
> >>1- Changed the names of the classes to be more clear; for example
> >>    Notificable becomes Notifying (that notifies), Notification becomes
> >>   SimpleNotifyingBean and ErrorNotifier becomes NotifyingGenerator.
> >>2- Refactored the error notification classes to fit under
> >>   components.notification and separated the code that builds a
Notifying
> >>   object from the SimpleNotifyingBean for max flexibility:
> >>   (Default)NotifyingBuilder, that is also an Avalon component. In this
way
> >>   you can filter your errors without touching the Notification DTD or
> >>   creating  custom Generators.
> >>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?

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

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

> Sorry for being so critical.

I'm happy for it, finally some interest ;-)

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

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

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

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

Ciao,
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


> About the selector problem : this is because there's a missing
> recompose() on pipelines newly created in handle_errors_xxx methods.
> Each sitemap has its own component manager for selectors managing
> components defined in <map:component>. Since pipelines are defined in
> the top-level component manager (cocoon.xconf), they don't "see" the
> selectors local to the sitemap manager. But I don't understand why
> error-handling ever worked without recompose()...

.
>
>
> >>4- Deprecated special method in AbstractEventPipeline for ErrorNotifier;
now
> >>   the Notification is gotten from the objectmodel.
> >>5- As a direct consequence of point 3 now Actions put in the
handle-errors
> >>   sitemap can get the NotifyingObjects and act on those; many times
> >>   requested for error reporting to admins.
> >>6- Last, but not least, any Exception that is alse Notifying gets
notified
> >>   using Notifying methods by the DefaultNotifyingBuilder.
> >>
> >>The DTD of the notification is the same and Notifying is almost
identical to
> >>Notificable (a HashMap became a Map). Old classes and methods have been
> >>deprecated.
> >>
> >>The points that I need to resolve before submitting the patch are:
> >>I - should Constants.NOTIFYING_OBJECTS be put in the objectmodel and
created
> >>   there instead of in the sitemap?
> >>II - How come the handle-error pipeline works only after some
> >>   time/invocations? The logs say that:
> >>
> >>DEBUG   (2001-12-27) 14:57.21:537   [core    ] (/cocoon/generror)
> >>HttpProcessor[8080][3]/ExcaliburComponentManager: Could not find
component
> >>for role: org.apache.cocoon.generation.GeneratorSelector
> >>ERROR   (2001-12-27) 14:57.21:537   [core    ] (/cocoon/generror)
> >>HttpProcessor[8080][3]/sitemap_xmap: NotifyingGenerator was not able to
> >>notify the exception.
> >>org.apache.avalon.framework.component.ComponentException: Could not find
> >>component
> >> at
>
>>org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(Exc
al
> >>iburComponentManager.java:318)
> >> at
>
>>org.apache.cocoon.components.pipeline.AbstractEventPipeline.setGenerator(A
bs
> >>tractEventPipeline.java:97)
> >> at
>
>>org.apache.cocoon.components.pipeline.CachingEventPipeline.setGenerator(Ca
ch
> >>ingEventPipeline.java:75)
> >> at
>
>>org.apache.cocoon.www.sitemap_xmap.error_process_9_500(sitemap_xmap.java:9
32
> >>9)
> >> at org.apache.cocoon.www.sitemap_xmap.process(sitemap_xmap.java:3285)
> >>
> >>   After some invocations/time it cutely says:
> >>
> >>DEBUG   (2001-12-27) 14:58.14:973   [core    ] (/cocoon/generror)
> >>HttpProcessor[8080][4]/ExcaliburComponentManager: Could not find
component
> >>for role: org.apache.cocoon.generation.GeneratorSelector
> >>DEBUG   (2001-12-27) 14:58.14:973   [core    ] (/cocoon/generror)
> >>HttpProcessor[8080][4]/ExcaliburComponentManager: The Role Manager has
not
> >>been set!
> >>DEBUG   (2001-12-27) 14:58.14:973   [core    ] (/cocoon/generror)
> >>HttpProcessor[8080][4]/AbstractEventPipeline: New GS
> >>org.apache.cocoon.sitemap.SitemapComponentSelector@24c22b
> >>DEBUG   (2001-12-27) 14:58.14:973   [core    ] (/cocoon/generror)
> >>HttpProcessor[8080][4]/ExcaliburComponentManager: The Role Manager has
not
> >>been set!
> >>DEBUG   (2001-12-27) 14:58.14:973   [core    ] (/cocoon/generror)
> >>HttpProcessor[8080][4]/LogKitLogger: Retrieving a
> >>org.apache.cocoon.sitemap.NotifyingGenerator from the pool
> >>DEBUG   (2001-12-27) 14:58.14:973   [core    ] (/cocoon/generror)
> >>HttpProcessor[8080][4]/AbstractEventPipeline:
> >>!NG!org.apache.cocoon.sitemap.NotifyingGenerator@392fe8
> >>
> >>   Then all works perfectly.
> >>   Does this have something to do with the Recomposable stuff?
> >>   Suggestions?
> >>III- I would prefer to add the special NotifyingGenerator
> >>   (ex-ErrorNotifier) to the sitemap in sitemap.roles instead
> >>   of doing it in code in the sitemap.
> >>   I've put tentative code in it (now commented) that doesn't work.
> >>   Does this have something to do with the Recomposable stuff?
> >>   Suggestions?
> >>
> >>Things that I will do when this is approved:
> >>a- create a <notify:xxx> XSP taglib, for reporting errors or setting
> >>   notifictions in the objectmodel.
> >>b- create a NotifyingBuilder that filters error messages and enhances
them
> >>   using a Resource Bundle (taken also from faqs?).
> >>c- make a notifications-view to see if non-error notifications were
issued
> >>d- documentation
> >>
> >>Finally, I've read the Constitution and [VOTE]s must be called by active
> >>developers. Being a developer, I humbly suggest that an active developer
> >>asks for a [VOTE] on this issue, being it a refactoring effort that
> >>touches the objectmodel and maybe Environment.
> >>
> >>Thank you.
> >>Nicola Ken Barozzi
> >>
> >>--
> >>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