----- Original Message ----- From: "Sylvain Wallez" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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" <[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. 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 about. 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 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. 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:sender="org.apache.cocoon.www.sitemap_xmap" xmlns:error="http://apache.org/cocoon/error/2.0";> <error:title>An error occurred</error:title> <error:source>MyException</error:source> <error:message>Blah message</error:message> <error:description>Blah description</error:description> <error:extra error:description="explanation">First explanation</error:extra> <error:extra error:description="explanation">Second explanation</error:extra> <error:extra error:description="stacktrace"></error:extra> </error:notify> 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. FSFSFSFSFSFSFS 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 case. > 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. Ciao, Ken > 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 [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]
