Nicola Ken Barozzi wrote:
> ----- Original Message -----
> From: "Sylvain Wallez" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> 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 [EMAIL PROTECTED]
>
> These are the days of miracle and wonder...
> ...so don't cry baby, don't cry...
> Paul Simon
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
