----- Original Message ----- From: "Sylvain Wallez" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, December 31, 2001 12:17 AM Subject: Re: Refactoring and correction of error notification
> 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... In fact, no. > > > 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 ). I know. +1 > > 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. I know of many jsp developers who became xsp developers that simply get angry when the see loads of useless messages in the log. They want infos only on the page they are producing, not of the system. We need a filtering mechanism that can show only the infos that pertain to the current page invocation. > > > > >>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 ? +1 I knew it world come out. ;-) > > >>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 ? Me ;-) But not only graphical, also to the browser. > > >>>>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. +1 > > 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 ? If the info is there, you can display it (4 example a Transformer that outputs the notifs from the objectmodel). But it's just a possibility. > >>>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). I DON'T want to be obliged by another programmer to make a custom stylesheet for errors just because he decided to use his DTD for it. I'm -1 on it. > > > Isn't this FS? > > > Don't think so : you don't want to always dump a stack trace when > there's an exception. It seems like you don't want to understand. If you want you write a stylesheet that blocks the stacktrace on output. Can you do it? I can show you if you're not able <getting-nervous/> Or make your Builder that doesn't append stacktraces to the Notifying. Have you seen the code? > 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. Selector. > > >>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">. Who said that? It's correct xml. > > > 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 ? This is part of the interface: /** * Gets the ExtraDescriptions of the Notifying object */ Map getExtraDescriptions(); A Map has OBJECTS. You CAN make your Builder that checks for XMLizable and outputs that to extra or whatever. And extra is intended to have anything inside. > > >>>>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... Not only. Using Selector a programmer understands it's a pipeline like the others and can add Actions. Just think that Giacomo himself wasen't sure Actions worked in there, but they do! > > >>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... Don't fool me ;-) Here is the snippet: <snippet> > > > Ken: > > > Anyway, having written the ErrorNotifier stuff I would like to > > explain briefly why it's done that way. As you can guess I started > > > out thinking of a component for error reporting, but Stefano talked > > > me out of it, and I think he is right. Errors are not IMHO > > > "content", but system messages. Because of this there is no need to > > > generate a different DTD for any kind of error... imagine having 20 > > > different DTDs for errors and keeping track of all the stylesheet > > > that go with them... ;) So I decided to stick to a fixed DTD that > > > can deliver not just errors but messages. The DTD (implied) has some > > > fixed tags that give it a type,a name and short descriptions; after > > > that a series of added tags for possible new data to expose. This is > > > NOT fixed. :) In fact I decided to create an interface for > > > notifications. If your component-code-whatever throws an Exception > > > which implements also this interface the ErrorNotifier reads the > > > extra descriptions-data and appends them to the XML. So you have a > > > fixed DTD with the content you need. IMO this is flexible enough. > >Giacomo: > > Maybe flexible enough for reporting to the client. But I think other > > needs for errors arise like reporting to a management console > > whatsoever. > > > I'm sorry, I think I don't get it. Once the error is generated in XML, > can't you process it with all the C2 pipeline stuff? > Can't you trigger actions that report to a console? > AFAIK, Generators should *generate* xml, not send other stuff > to a console. Actions should do it, am I right? > And don't you think that a component-based approach can > make error reporting more difficult to administer with many different > DTDs? Personally I think that worse than having error pages on a site > is having criptic error pages. > Please, could you or anyone describe use-cases which are > impossible or extremely impractical to do with the current model? </snippet> Giacomo wants logging here ;-) Giacomo also said (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100747714231354&w=2): >Exceptions are Exceptions. If you think you missed something add it to the >Notifier. I'd like the idea having one Exception Schema only, don't you? > > And > > give me an example that explains how the current proposal is clearly > > > inadeguate in solving the problem. This question is in the snippet and here again. I want facts, not words. What can't you do? > > 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. But nobody fixed it. Anyway it was broken, because the fix I sent some time ago was left uncommitted. But let's stop talking of the past, I couldn't care less. > > >>- 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 agree. +1 In fact the patch is not based on many Notifying objects in the objectmodel, this is just a small part of it. To be honest I don't really care that much if it becomes only one Notifying like it was in the first patch version. I put it there as a "hack" to see how it could work out and how the dev-list reacted, and my concerns in fact were more than a feeling. Giacomo applied the patch, so I'm going to send a patch to it to make it only one; if you can apply it right away I guess your -1 goes away. But the problem it tried to solve (by creating others as you correctly demonstrated) is still there. Let's concentrate on the only part that's left to discuss: good logging. I would say that other issues are resolved, don't you think? I will post more examples and use cases for the use, so things are better explained. The thing I need, is to have the programmer see all logs (filtered) that had to do with his current invocation when he gets an error. If you give me a hint I will start working on it. And a graphical debug shower, how would you prefer it? > I'd be interested to hear also other people's opinion on all this (maybe > next year ?) If nobody replies, I guess we can be satisfied with our discussion. It seems quite complete, don' t you think? Don't forget that on this issue, the list has historically been +0, and I'm happy that you have strong feelings on this, it means you really feel it, and this makes you comments more valuable. I like discussions, the important thing is that they are based on facts and are constructive. Ciao, 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]
