Nicola Ken Barozzi wrote: > ----- 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.
Couldn't find it in the archive. But was Avalon at that time as simple yet powerful as it is now ? Particularly LogKit and Excalibur. I guess not... > 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. Funny. I suggested a few days ago in the "over-logging" thread to clean up debug messages which should - now that 2.0 is stable - indicate what Cocoon is doing rather that debug the internals of components (see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100955234514600&w=4 ). > 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. I do. Most people who are developping *with* Cocoon write XSPs and actions, some write transformers and business-logic components. And all these are Avalon components which have immediate access to a Logger. So people quickly become familiar with getLogger().debug() and log files. If we want to avoid laughs like the one you experienced, we should not develop a parallel logging system to hide the existing one, but clean up what we already have so that it gives _useful_ information to users. Debug statements cleanup and reorganization of logging categories is the key to that. > >>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. That's what I was saying : how does this list go down e.g. to TraxErrorHandler ? Will we have to add a new setNotifyingList() to all components that have no access to the object model ? Why should we do that when Avalon automagically gives us a Logger ? >>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. Why don't you "tail -f" the log file in a separate window while requesting a page ? You simultaneously see the result and the produced warnings, if any. That's way easier than requesting a second time the same page with an additional parameter, especially for POST requests ;) I also use a GUI to follow logs while requesting a page (see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100956335005569&w=4 ). This is so usefull I think we should have an opensource equivalent as a part of LogKit. Any takers ? >>>>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. Wow, seems you really want a wide usage of Notifications. I strongly disagree with this. We can use INFO messages in the log files for that, or use special system-wide logging categories that go in a particular log file. > 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. ?? I don't follow you here. What will be displayed to the user if you don't call the error handlers ? >>>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? You're right if the handle-errors should be able to handle _any_ exception as is the case today. If you have specialized handle-errors like I suggested below, the exception only _triggers_ the handle-errors and this one is free to do anything afterwards (e.g. displaying a regular page). > Isn't this FS? Don't think so : you don't want to always dump a stack trace when there's an exception. Only unexpected exceptions (i.e. real errors) can lead to that. There can be a number of well-known exceptions in a webapp that should stop the current pipeline but don't dump a standard error message. The current assiociation of ResourceNotFoundException to type="404" is an example of that. >>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. You cannot output the above with the current Notifying : each extra description has only *one* value. You won't be able to have several <extra description="explanation">. > The DTD is not perfect, but simply extensible. > I don't say I love it, but since it works ok, why break compatibility? Could we extend it without breaking compatibility by accepting not only String descriptions, but also XMLizable objects ? >>>>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. Good point. You're right : this avoids yet another component type. But categorizing exceptions makes IMO the sitemap more readable. It's like the following code snippets : try { ... } catch(ResourceNotFoundException rnfe) { // resource not found } catch(Exception e) { // other exceptions } and try { ... } catch(Exception e) { if (e instanceof ResourceNotFoundException) { // resource not found } else { // other exceptions } } Both are equivalent, but the first one is more readable. Matter of taste... >>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). All I found is http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98710667032549&w=4 where Giacomo wasn't fully conviced... > 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 ;-) Mmmh. Or maybe people didn't understood, like I did, what to do with this too closed stuff... I've been working on C2 since around march 2001 and AFAIK nobody ever talked about a class he wrote implementing Notificable. Sorry to say that nobody can tell if it's bad or not because it seems nobody uses 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. Once again, I totally disagree. If people start using Notifying because log messages are messy, you will quickly want an Alarmable interface or whatever because there are too much Notifying objects with useless messages. We should clean up existing stuff by reducing the number of logs, output useful and meaningful messages, structure the log hierarchies, and if needed define system-wide loggers for categories orthogonal to component functions (deprecation is an example of this). So -1 for a list of Notifying in the object model. My opinion is that when an exception occurs while handling a pipeline, only one object representing the error should be available in the object model, and only in the <handle-errors> part of the pipeline. I'd be interested to hear also other people's opinion on all this (maybe next year ?) >> >>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 :-) Oh, complicated story ! Cheers, Sylvain. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
