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 ? 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. 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. And IMHO, the end-user *should not* see these errors : - 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. Sorry for being so critical. 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. 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 ? 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. 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()... Sylvain. >>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(Excal >>iburComponentManager.java:318) >> at >>org.apache.cocoon.components.pipeline.AbstractEventPipeline.setGenerator(Abs >>tractEventPipeline.java:97) >> at >>org.apache.cocoon.components.pipeline.CachingEventPipeline.setGenerator(Cach >>ingEventPipeline.java:75) >> at >>org.apache.cocoon.www.sitemap_xmap.error_process_9_500(sitemap_xmap.java:932 >>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 [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]
