You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2002/01/01 21:39:18 UTC
Re: Refactoring and correction of error notification
Nicola Ken Barozzi wrote:
> ----- Original Message -----
> From: "Sylvain Wallez" <sy...@anyware-tech.com>
> To: <co...@xml.apache.org>
> 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" <sy...@anyware-tech.com>
>>>To: <co...@xml.apache.org>
>>>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" <sy...@anyware-tech.com>
>>>>>To: <co...@xml.apache.org>
>>>>>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. ;-)
;-) also !
>>>>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 browser view would be cool. What about the following behaviour :
request a special URL in a browser window, which waits until a new
request (started in another window) or an URL pattern is handled by
Cocoon and outputs the logs issued during that request ?
CocoonServlet already puts the object model and a request-id in LogKit's
context map (see CocoonServlet.java:791) that could be used to identify
requests.
Thoughts ?
>>>>>>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
Cool, but +1 for what : INFO or system-wide categories ?
>>>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.
OK. Got it now.
>>>>>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?
There's a misunderstanding here. I wanted to explain that each different
handle-errors is a regular pipeline that can do anything a pipeline
does, including choosing a generator, the only difference with other
pipelines being an additional Notifying in the object model.
>>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.
OK. Let's abandon the multiple handle-errors pipeline in favor of an
"error-type" 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.
Am I biased by the current implementation ? SimpleNofiyingBean only
accepts Strings as extra descriptions and Notifier performs a toString()
on entries of the Map. That's why I thought it was restricted to Strings.
>>>>>>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!
That's not really a difference : as I said above, each handle-errors can
be considered as an independent pipeline.
But I'm OK with the selector : this is even more flexible since we can
select on anything, and not only Notifying.getType() ;)
>>>>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?
I can't set my own generator in <handle-errors>. I'm happy with a fixed
DTD for exception reports to the user. But I would like to be able to
generate something else than the error DTD in some branches of the
"error-type" select statement.
This what my example with several <handle-errors> was all about : each
branch has a different generator, the "notification" generator being the
one that issues the standard error DTD from the Notifying object.
Finally, (my thoughts cleaned up with this discussion), this is not the
fixed DTD I am criticizing, but the fixed generator.
>>> 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.
Patch applied. My -1 is also pushed away because the discussion has some
very constructive results.
> 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?
Mostly : clean logging, single Notifying, single <handle-errors>. The
last remaining point is about non-fixed generator (didn't said DTD) in
<handle-errors>.
We also have some compatibility issues : what about the existing
multiple-<handle-errors> pipelines ?
> I will post more examples and use cases for the use, so things are better
> explained.
Eagerly waiting ;)
> 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?
Browser-view would be cool : a swing gui means you need to sit in front
of the server (win$) or are able to export it's display (Unix), which
isn't always the case, and tremendously slows down the system.
My thoughts about it is a special LogKit LogTarget that buffers
LogEvents for a request and a special generator that turns these events
to XML. The information put in LogKit's context map (see above) is the
key to per-request event filtering.
>>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.
Thanks :)
> I like discussions, the important thing is that they are based on facts and
> are constructive.
Cool. I share this view :)
Cheers... and a happy new year !
Sylvain
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Refactoring and correction of error notification
Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
----- Original Message -----
From: "Sylvain Wallez" <sy...@anyware-tech.com>
To: "cocoon-dev" <co...@xml.apache.org>
Sent: Thursday, January 03, 2002 4:18 PM
Subject: Re: Refactoring and correction of error notification
>
>
> Nicola Ken Barozzi a écrit :
> >
> > ----- Original Message -----
> > From: "Sylvain Wallez" <sy...@anyware-tech.com>
> > To: <co...@xml.apache.org>
> > Sent: Thursday, January 03, 2002 12:24 PM
> > Subject: Re: Refactoring and correction of error notification
> >
> > > Nicola Ken Barozzi a écrit :
> >
> <snip/>
> > >
> > > OK. So I propose system-wide categories. They imply more development in
> > > the Cocoon core, but provide the cleanest way for filtering.
> >
> > +1
> > If you can work on this, I'll take care of the output part (see below).
>
> I'll make a proposal soon. In order for it to be both speedy and
> available from every place in the code, I think we will need a component
> with a set of static accessor to static loggers. I know static variables
> are a bad thing, but looking up a regular component will certainly kill
> performance.
Hey, now why not use log4j?
It has static accessors... I don't understand why Avalon made his own version.
It stopped the testlet stuff because JUnit was way ahead, why then not use log4j?
What is needed that it cannot provide?
Ok Mr. Donald, don't hit me too hard on this ;-P
> The system-wide categories I foresee are (please add your own) :
> - deprecated features
- development (the *with* part)
> > > > <snip/>
> > > > > >
> > > > > > 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.
> > > > >
> > > > > Am I biased by the current implementation ? SimpleNofiyingBean only
> > > > > accepts Strings as extra descriptions
> > > >
> > > > Yes, because it's... well... simple ;-)
> > >
> > > So we will need a... well... less simple implementation !
> >
> > :-))
> >
> > Well, I did not prefer having a more complex one, because I prefer that objects implement the interface directly. This at least was the original intention that made me write a ...simple ;-) implementation.
> > Why do you need a more complex one?
> > I'm not against it, mind me, but if I know the purpose better I can write it with more "grano salis".
>
> With the non-fixed generator, I guess this may not be actually needed.
> So let's delay this until we have a real need for it.
Ok.
> > > > > >>> Ken: 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?
> > > > >
> > > > > I can't set my own generator in <handle-errors>. I'm happy with a fixed
> > > > > DTD for exception reports to the user. But I would like to be able to
> > > > > generate something else than the error DTD in some branches of the
> > > > > "error-type" select statement.
> > > >
> > > > Why?
> > > >
> > > > > This what my example with several <handle-errors> was all about : each
> > > > > branch has a different generator, the "notification" generator being the
> > > > > one that issues the standard error DTD from the Notifying object.
> > > > >
> > > > > Finally, (my thoughts cleaned up with this discussion), this is not the
> > > > > fixed DTD I am criticizing, but the fixed generator.
> > > >
> > > > A Generator translates "information-entities" in XML. When the
> > > > "information-entitiy" (Notifying and Env) are defined and the DTD is
> > > > defined... the Generator is defined. If you want to "filter" the Notifying,
> > > > you can make your own Builder. The Builder is basically a filter that gives
> > > > you the flexibility that multiple Generators have without the possible
> > > > varying DTD.
> > > > What you need, I think, is to be able to decide the mapping between the
> > > > Notifying and the DTD. But the notifying and the DTD basically mimic the
> > > > same structure; the Builder can filter and transform your Notigying to your
> > > > needs.
> > >
> > > Once again, the use case is not filtering the Notifying contents, but
> > > generating something completely different, this generation being
> > > triggered by the fact that an exception occured and that some selector
> > > directed to that generator.
> > >
> > > In that case, the information-entity isn't defined : the Notifying is
> > > just additional data which complements the environment and object model
> > > to _choose_ the content, i.e. direct pipeline assembly, as matchers and
> > > selectors do in regular pipelines.
> > >
> > > Let's consider a very common use case : most sites display nice pages
> > > when a requested URL doesn't exist instead of the raw "404-not found"
> > > server message.
> > >
> > > The below sitemap snippet shows an implementaton of this behaviour : the
> > > "notyfing-type" selector selects a branch depending on the value of
> > > Notifying.getType(). When a resource isn't found (type
> > > "rsrc-not-found"), the page to display uses the same content DTD and
> > > pipeline definition than other parts of the site. In this example, a
> > > standard page is a resource that aggregates page content and some common
> > > elements.
> > >
> > > <map:resource name="site-page">
> > > <!-- standard layout of the site -->
> > > <map:aggregate element="page">
> > > <map:part src="top-menu.xml" element="top"/>
> > > <map:part src="{page}" element="content"/>
> > > <map:part src="sidebar.xml" element="side"/>
> > > <map:aggregate/>
> > > <map:transform src="site-page2html.xsl"/>
> > > <map:serialize/>
> > > </map:resource>
> > >
> > > <map:handle-errors>
> > > <map:select type="notifying-type">
> > >
> > > <map:when test="rsrc-not-found">
> > > <!-- display the not-found page -->
> > > <map:call resource="site-page">
> > > <map:parameter name="page" value="not-found.xml"/>
> > > </map:call>
> > > </map:when>
> > >
> > > <map:otherwhise>
> > > <!-- generic formatting of the error DTD -->
> > > <map:generate type="notifying"/>
> > > <map:transform src="error2html.xsl"/>
> > > <map:serialize/>
> > > </map:otherwhise>
> > >
> > > </map:select>
> > > </map:handle-errors>
> > >
> > > This example may seem complex (a resource with an aggregation), but I'm
> > > sure it corresponds to real-world use cases.
> >
> > Ah, now I understand :-)
> > Indeed the example is very very clear, thank you.
> > <mind state="thinking">mumble...mumble...</mind>
>
> Pheeew ! I finally succeeded in making my thoughts clear :-)) It's
> sometimes not that easy for two people with different experiences and
> native languages to understand themselves in a third language ;)
:-) I think that we both make too many assumptions on what the other "should" know of our problems.
IMHO the best way to overcome this is to always acclude examples in use-cases and code.
> > > > <snip/>
> > > >
> > > > > >>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.
> > > > >
> > > > >
> > > > > Patch applied. My -1 is also pushed away because the discussion has some
> > > > > very constructive results.
> > > >
> > > > :-)
> > > >
> > > > > > 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?
> > > > >
> > > > > Mostly : clean logging, single Notifying, single <handle-errors>. The
> > > > > last remaining point is about non-fixed generator (didn't said DTD) in
> > > > > <handle-errors>.
> > > >
> > > > The problem is that you can't give flexibility of changing Generator while
> > > > fixing a DTD. IMO the Builder should do it. Comments?
> > >
> > > See the sitemap snippet above. Fixed DTD is OK when the content is the
> > > Notifying. But you don't always want the Notifying as the content.
> >
> > In other words you don't always want use the notification content, right?
>
> Right.
>
> > It's not that the notification content is not enough for you (as I originally though you meant), it's that you want to use a completely different content, with no knowledge whatsoever of what happened before!
>
> Totally right : in that case the notification is just an event for
> triggering <handle-errors> and some data used by a selector.
>
> > I understand, and your point is sensible.
> > My concern is that giving the users freedom to use custom Generators in handle-errors, they bypass the fixed DTD alltogether, which nullifies basically its benefits.
> > How do we solve this?
> > Maybe allowing only map:call resource (like in your example; as you see, no Generator with access to NOTIFYING-OBJECT is there) and resetting all the previous objectModel could do it.
> > What do you think?
>
> People are lazy by nature. So why would they write
> yet-another-NotifierGenerator when Cocoon already provides one ?
Don't be so sure of this.
Everyone -I mean everyone, really ;-) - that didn't know how to do something with Cocoon told me "How can I write my generator to do this?".
> And if
> they finally decide do write one, then it's their responsibility to
> write the corresponding stylesheets.
It's always their responsibility anyways.
But you write something one day, and the day after I have to maintain it ;-)
Or worse: I need to integrate two Cocoon apps written separately.
Brrrrr... ;-)
> So I would not limit to map:call, since soon people will claim "I don't
> want to use a resource. Why can't it put a <map:generate> ?"
"Limit" is the right word. I *want* to limit.
Making handle-errors a complete sitemap can lead easily to bad programming practice.
I fear the day someone will ask me to have an explicit handle-errors inside of handle-errors!
So, for what my vote counts (0 Kelvin) I'm -1 on it.
I think it breaks the contract that has been there in Cocoon of a fixed DTD.
Or use the NotifyingGenerator or a resource.
I don't want nested handle-errors.
<snip type="one of many"/>
> > > >
> > > > > My thoughts about it is a special LogKit LogTarget that buffers
> > > > > LogEvents for a request and a special generator that turns these events
> > > > > to XML. The information put in LogKit's context map (see above) is the
> > > > > key to per-request event filtering.
> > > >
> > > > As for the Generator, isn't there something that logs in XML. How much use
> > > > can come from that?
> > >
> > > Checkout org.apache.cocoon.util.log.XMLCocoonLogFormatter. It outputs
> > > XML as text, but the DTD good be a good starting point.
> >
> > Yes, thank you, I've seen it.
> > I will work on it in my spare time and reasonably finish it over this weekend.
>
> Wow, that's quick !
Ok then, next week ;-)
Ken
--
Nicola Ken Barozzi xml-cocoon@nicolaken.com
These are the days of miracle and wonder...
...so don't cry baby, don't cry...
Paul Simon
Re: Refactoring and correction of error notification
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi a écrit :
>
> ----- Original Message -----
> From: "Sylvain Wallez" <sy...@anyware-tech.com>
> To: <co...@xml.apache.org>
> Sent: Thursday, January 03, 2002 12:24 PM
> Subject: Re: Refactoring and correction of error notification
>
> > Nicola Ken Barozzi a écrit :
>
<snip/>
> >
> > OK. So I propose system-wide categories. They imply more development in
> > the Cocoon core, but provide the cleanest way for filtering.
>
> +1
> If you can work on this, I'll take care of the output part (see below).
I'll make a proposal soon. In order for it to be both speedy and
available from every place in the code, I think we will need a component
with a set of static accessor to static loggers. I know static variables
are a bad thing, but looking up a regular component will certainly kill
performance.
The system-wide categories I foresee are (please add your own) :
- deprecated features
> > > <snip/>
> > > > >
> > > > > 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.
> > > >
> > > > Am I biased by the current implementation ? SimpleNofiyingBean only
> > > > accepts Strings as extra descriptions
> > >
> > > Yes, because it's... well... simple ;-)
> >
> > So we will need a... well... less simple implementation !
>
> :-))
>
> Well, I did not prefer having a more complex one, because I prefer that objects implement the interface directly. This at least was the original intention that made me write a ...simple ;-) implementation.
> Why do you need a more complex one?
> I'm not against it, mind me, but if I know the purpose better I can write it with more "grano salis".
With the non-fixed generator, I guess this may not be actually needed.
So let's delay this until we have a real need for it.
> > > > >>> Ken: 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?
> > > >
> > > > I can't set my own generator in <handle-errors>. I'm happy with a fixed
> > > > DTD for exception reports to the user. But I would like to be able to
> > > > generate something else than the error DTD in some branches of the
> > > > "error-type" select statement.
> > >
> > > Why?
> > >
> > > > This what my example with several <handle-errors> was all about : each
> > > > branch has a different generator, the "notification" generator being the
> > > > one that issues the standard error DTD from the Notifying object.
> > > >
> > > > Finally, (my thoughts cleaned up with this discussion), this is not the
> > > > fixed DTD I am criticizing, but the fixed generator.
> > >
> > > A Generator translates "information-entities" in XML. When the
> > > "information-entitiy" (Notifying and Env) are defined and the DTD is
> > > defined... the Generator is defined. If you want to "filter" the Notifying,
> > > you can make your own Builder. The Builder is basically a filter that gives
> > > you the flexibility that multiple Generators have without the possible
> > > varying DTD.
> > > What you need, I think, is to be able to decide the mapping between the
> > > Notifying and the DTD. But the notifying and the DTD basically mimic the
> > > same structure; the Builder can filter and transform your Notigying to your
> > > needs.
> >
> > Once again, the use case is not filtering the Notifying contents, but
> > generating something completely different, this generation being
> > triggered by the fact that an exception occured and that some selector
> > directed to that generator.
> >
> > In that case, the information-entity isn't defined : the Notifying is
> > just additional data which complements the environment and object model
> > to _choose_ the content, i.e. direct pipeline assembly, as matchers and
> > selectors do in regular pipelines.
> >
> > Let's consider a very common use case : most sites display nice pages
> > when a requested URL doesn't exist instead of the raw "404-not found"
> > server message.
> >
> > The below sitemap snippet shows an implementaton of this behaviour : the
> > "notyfing-type" selector selects a branch depending on the value of
> > Notifying.getType(). When a resource isn't found (type
> > "rsrc-not-found"), the page to display uses the same content DTD and
> > pipeline definition than other parts of the site. In this example, a
> > standard page is a resource that aggregates page content and some common
> > elements.
> >
> > <map:resource name="site-page">
> > <!-- standard layout of the site -->
> > <map:aggregate element="page">
> > <map:part src="top-menu.xml" element="top"/>
> > <map:part src="{page}" element="content"/>
> > <map:part src="sidebar.xml" element="side"/>
> > <map:aggregate/>
> > <map:transform src="site-page2html.xsl"/>
> > <map:serialize/>
> > </map:resource>
> >
> > <map:handle-errors>
> > <map:select type="notifying-type">
> >
> > <map:when test="rsrc-not-found">
> > <!-- display the not-found page -->
> > <map:call resource="site-page">
> > <map:parameter name="page" value="not-found.xml"/>
> > </map:call>
> > </map:when>
> >
> > <map:otherwhise>
> > <!-- generic formatting of the error DTD -->
> > <map:generate type="notifying"/>
> > <map:transform src="error2html.xsl"/>
> > <map:serialize/>
> > </map:otherwhise>
> >
> > </map:select>
> > </map:handle-errors>
> >
> > This example may seem complex (a resource with an aggregation), but I'm
> > sure it corresponds to real-world use cases.
>
> Ah, now I understand :-)
> Indeed the example is very very clear, thank you.
> <mind state="thinking">mumble...mumble...</mind>
Pheeew ! I finally succeeded in making my thoughts clear :-)) It's
sometimes not that easy for two people with different experiences and
native languages to understand themselves in a third language ;)
> > > <snip/>
> > >
> > > > >>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.
> > > >
> > > >
> > > > Patch applied. My -1 is also pushed away because the discussion has some
> > > > very constructive results.
> > >
> > > :-)
> > >
> > > > > 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?
> > > >
> > > > Mostly : clean logging, single Notifying, single <handle-errors>. The
> > > > last remaining point is about non-fixed generator (didn't said DTD) in
> > > > <handle-errors>.
> > >
> > > The problem is that you can't give flexibility of changing Generator while
> > > fixing a DTD. IMO the Builder should do it. Comments?
> >
> > See the sitemap snippet above. Fixed DTD is OK when the content is the
> > Notifying. But you don't always want the Notifying as the content.
>
> In other words you don't always want use the notification content, right?
Right.
> It's not that the notification content is not enough for you (as I originally though you meant), it's that you want to use a completely different content, with no knowledge whatsoever of what happened before!
Totally right : in that case the notification is just an event for
triggering <handle-errors> and some data used by a selector.
> I understand, and your point is sensible.
> My concern is that giving the users freedom to use custom Generators in handle-errors, they bypass the fixed DTD alltogether, which nullifies basically its benefits.
> How do we solve this?
> Maybe allowing only map:call resource (like in your example; as you see, no Generator with access to NOTIFYING-OBJECT is there) and resetting all the previous objectModel could do it.
> What do you think?
People are lazy by nature. So why would they write
yet-another-NotifierGenerator when Cocoon already provides one ? And if
they finally decide do write one, then it's their responsibility to
write the corresponding stylesheets.
So I would not limit to map:call, since soon people will claim "I don't
want to use a resource. Why can't it put a <map:generate> ?"
> > > > We also have some compatibility issues : what about the existing
> > > > multiple-<handle-errors> pipelines ?
> > >
> > > Good point.
> > > I would keep it in the code for now and change the current webapp sitemaps
> > > to use the new concept.
> > > Then deprecate it, like redirects, and remove it in future releases.
> > >
> > > > > I will post more examples and use cases for the use, so things are
> > > > > better explained.
> > > >
> > > > Eagerly waiting ;)
> > > >
> > > > > 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?
> > > >
> > > > Browser-view would be cool : a swing gui means you need to sit in front
> > > > of the server (win$) or are able to export it's display (Unix), which
> > > > isn't always the case, and tremendously slows down the system.
> > >
> > > I think so too.
> > >
> > > > My thoughts about it is a special LogKit LogTarget that buffers
> > > > LogEvents for a request and a special generator that turns these events
> > > > to XML. The information put in LogKit's context map (see above) is the
> > > > key to per-request event filtering.
> > >
> > > As for the Generator, isn't there something that logs in XML. How much use
> > > can come from that?
> >
> > Checkout org.apache.cocoon.util.log.XMLCocoonLogFormatter. It outputs
> > XML as text, but the DTD good be a good starting point.
>
> Yes, thank you, I've seen it.
> I will work on it in my spare time and reasonably finish it over this weekend.
Wow, that's quick !
> > > But thinking of it, maybe an HTML appender that completely bypasses Cocoon
> > > could be better, because it doesn't interfere.
> >
> > Mmmh. Not so sure, because interferences can be easily filtered using
> > either the request id or URI that are in LogKit's ContextMap. And having
> > this feature as Cocoon components can be a starting point for a
> > full-featured log management webapp.
>
> Yes, it would be cool to have Cocoon as a logging output system.
> Ok, I'll go this way.
> Thanks. :-)
>
> Ciao,
> Ken
> --
> Nicola Ken Barozzi xml-cocoon@nicolaken.com
>
> These are the days of miracle and wonder...
> ...so don't cry baby, don't cry...
> Paul Simon
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Refactoring and correction of error notification
Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
----- Original Message -----
From: "Sylvain Wallez" <sy...@anyware-tech.com>
To: <co...@xml.apache.org>
Sent: Thursday, January 03, 2002 12:24 PM
Subject: Re: Refactoring and correction of error notification
> Nicola Ken Barozzi a écrit :
> > > >>
> > > >>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
> > >
> > > Cool, but +1 for what : INFO or system-wide categories ?
> >
> > +1 for logging instead of Notifications ;-)
>
> OK. So I propose system-wide categories. They imply more development in
> the Cocoon core, but provide the cleanest way for filtering.
+1
If you can work on this, I'll take care of the output part (see below).
> > > >>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.
> > >
> > > OK. Let's abandon the multiple handle-errors pipeline in favor of an
> > > "error-type" selector.
> > >
> > <snip/>
> > > >
> > > > 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.
> > >
> > > Am I biased by the current implementation ? SimpleNofiyingBean only
> > > accepts Strings as extra descriptions
> >
> > Yes, because it's... well... simple ;-)
>
> So we will need a... well... less simple implementation !
:-))
Well, I did not prefer having a more complex one, because I prefer that objects implement the interface directly. This at least was the original intention that made me write a ...simple ;-) implementation.
Why do you need a more complex one?
I'm not against it, mind me, but if I know the purpose better I can write it with more "grano salis".
> > > >>> Ken: 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?
> > >
> > > I can't set my own generator in <handle-errors>. I'm happy with a fixed
> > > DTD for exception reports to the user. But I would like to be able to
> > > generate something else than the error DTD in some branches of the
> > > "error-type" select statement.
> >
> > Why?
> >
> > > This what my example with several <handle-errors> was all about : each
> > > branch has a different generator, the "notification" generator being the
> > > one that issues the standard error DTD from the Notifying object.
> > >
> > > Finally, (my thoughts cleaned up with this discussion), this is not the
> > > fixed DTD I am criticizing, but the fixed generator.
> >
> > A Generator translates "information-entities" in XML. When the
> > "information-entitiy" (Notifying and Env) are defined and the DTD is
> > defined... the Generator is defined. If you want to "filter" the Notifying,
> > you can make your own Builder. The Builder is basically a filter that gives
> > you the flexibility that multiple Generators have without the possible
> > varying DTD.
> > What you need, I think, is to be able to decide the mapping between the
> > Notifying and the DTD. But the notifying and the DTD basically mimic the
> > same structure; the Builder can filter and transform your Notigying to your
> > needs.
>
> Once again, the use case is not filtering the Notifying contents, but
> generating something completely different, this generation being
> triggered by the fact that an exception occured and that some selector
> directed to that generator.
>
> In that case, the information-entity isn't defined : the Notifying is
> just additional data which complements the environment and object model
> to _choose_ the content, i.e. direct pipeline assembly, as matchers and
> selectors do in regular pipelines.
>
> Let's consider a very common use case : most sites display nice pages
> when a requested URL doesn't exist instead of the raw "404-not found"
> server message.
>
> The below sitemap snippet shows an implementaton of this behaviour : the
> "notyfing-type" selector selects a branch depending on the value of
> Notifying.getType(). When a resource isn't found (type
> "rsrc-not-found"), the page to display uses the same content DTD and
> pipeline definition than other parts of the site. In this example, a
> standard page is a resource that aggregates page content and some common
> elements.
>
> <map:resource name="site-page">
> <!-- standard layout of the site -->
> <map:aggregate element="page">
> <map:part src="top-menu.xml" element="top"/>
> <map:part src="{page}" element="content"/>
> <map:part src="sidebar.xml" element="side"/>
> <map:aggregate/>
> <map:transform src="site-page2html.xsl"/>
> <map:serialize/>
> </map:resource>
>
> <map:handle-errors>
> <map:select type="notifying-type">
>
> <map:when test="rsrc-not-found">
> <!-- display the not-found page -->
> <map:call resource="site-page">
> <map:parameter name="page" value="not-found.xml"/>
> </map:call>
> </map:when>
>
> <map:otherwhise>
> <!-- generic formatting of the error DTD -->
> <map:generate type="notifying"/>
> <map:transform src="error2html.xsl"/>
> <map:serialize/>
> </map:otherwhise>
>
> </map:select>
> </map:handle-errors>
>
> This example may seem complex (a resource with an aggregation), but I'm
> sure it corresponds to real-world use cases.
Ah, now I understand :-)
Indeed the example is very very clear, thank you.
<mind state="thinking">mumble...mumble...</mind>
> > <snip/>
> >
> > > >>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.
> > >
> > >
> > > Patch applied. My -1 is also pushed away because the discussion has some
> > > very constructive results.
> >
> > :-)
> >
> > > > 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?
> > >
> > > Mostly : clean logging, single Notifying, single <handle-errors>. The
> > > last remaining point is about non-fixed generator (didn't said DTD) in
> > > <handle-errors>.
> >
> > The problem is that you can't give flexibility of changing Generator while
> > fixing a DTD. IMO the Builder should do it. Comments?
>
> See the sitemap snippet above. Fixed DTD is OK when the content is the
> Notifying. But you don't always want the Notifying as the content.
In other words you don't always want use the notification content, right?
It's not that the notification content is not enough for you (as I originally though you meant), it's that you want to use a completely different content, with no knowledge whatsoever of what happened before!
I understand, and your point is sensible.
My concern is that giving the users freedom to use custom Generators in handle-errors, they bypass the fixed DTD alltogether, which nullifies basically its benefits.
How do we solve this?
Maybe allowing only map:call resource (like in your example; as you see, no Generator with access to NOTIFYING-OBJECT is there) and resetting all the previous objectModel could do it.
What do you think?
> > > We also have some compatibility issues : what about the existing
> > > multiple-<handle-errors> pipelines ?
> >
> > Good point.
> > I would keep it in the code for now and change the current webapp sitemaps
> > to use the new concept.
> > Then deprecate it, like redirects, and remove it in future releases.
> >
> > > > I will post more examples and use cases for the use, so things are
> > > > better explained.
> > >
> > > Eagerly waiting ;)
> > >
> > > > 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?
> > >
> > > Browser-view would be cool : a swing gui means you need to sit in front
> > > of the server (win$) or are able to export it's display (Unix), which
> > > isn't always the case, and tremendously slows down the system.
> >
> > I think so too.
> >
> > > My thoughts about it is a special LogKit LogTarget that buffers
> > > LogEvents for a request and a special generator that turns these events
> > > to XML. The information put in LogKit's context map (see above) is the
> > > key to per-request event filtering.
> >
> > As for the Generator, isn't there something that logs in XML. How much use
> > can come from that?
>
> Checkout org.apache.cocoon.util.log.XMLCocoonLogFormatter. It outputs
> XML as text, but the DTD good be a good starting point.
Yes, thank you, I've seen it.
I will work on it in my spare time and reasonably finish it over this weekend.
> > But thinking of it, maybe an HTML appender that completely bypasses Cocoon
> > could be better, because it doesn't interfere.
>
> Mmmh. Not so sure, because interferences can be easily filtered using
> either the request id or URI that are in LogKit's ContextMap. And having
> this feature as Cocoon components can be a starting point for a
> full-featured log management webapp.
Yes, it would be cool to have Cocoon as a logging output system.
Ok, I'll go this way.
Thanks. :-)
Ciao,
Ken
--
Nicola Ken Barozzi xml-cocoon@nicolaken.com
These are the days of miracle and wonder...
...so don't cry baby, don't cry...
Paul Simon
Re: Refactoring and correction of error notification
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi a écrit :
>
> ----- Original Message -----
> From: "Sylvain Wallez" <sy...@anyware-tech.com>
> To: <co...@xml.apache.org>
> Sent: Tuesday, January 01, 2002 9:39 PM
> Subject: Re: Refactoring and correction of error notification
>
> <snip cut-by="NKB">I'm cutting big chunks in the mail because the focus
> shifted and new "aspects" of the discussion are arising. The previous mail
> sums up all the conversation.</snip>
> >
> > The browser view would be cool. What about the following behaviour :
> > request a special URL in a browser window, which waits until a new
> > request (started in another window) or an URL pattern is handled by
> > Cocoon and outputs the logs issued during that request ?
> >
> > CocoonServlet already puts the object model and a request-id in LogKit's
> > context map (see CocoonServlet.java:791) that could be used to identify
> > requests.
> >
> > Thoughts ?
>
> +1
>
<snip/>
> > >>
> > >>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
> >
> > Cool, but +1 for what : INFO or system-wide categories ?
>
> +1 for logging instead of Notifications ;-)
OK. So I propose system-wide categories. They imply more development in
the Cocoon core, but provide the cleanest way for filtering.
> > >>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.
> >
> >
> > OK. Let's abandon the multiple handle-errors pipeline in favor of an
> > "error-type" selector.
> >
> <snip/>
> > >
> > > 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.
> >
> > Am I biased by the current implementation ? SimpleNofiyingBean only
> > accepts Strings as extra descriptions
>
> Yes, because it's... well... simple ;-)
So we will need a... well... less simple implementation !
> > and Notifier performs a toString()
> > on entries of the Map. That's why I thought it was restricted to Strings.
>
> I need to write docs, there are new concepts in this code that need to be
> explained because they aren't self-explaining.
>
<snip/>
> > But I'm OK with the selector : this is even more flexible since we can
> > select on anything, and not only Notifying.getType() ;)
> >
>
> <snip/>
>
> > >>> Ken: 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?
> >
> > I can't set my own generator in <handle-errors>. I'm happy with a fixed
> > DTD for exception reports to the user. But I would like to be able to
> > generate something else than the error DTD in some branches of the
> > "error-type" select statement.
>
> Why?
>
> > This what my example with several <handle-errors> was all about : each
> > branch has a different generator, the "notification" generator being the
> > one that issues the standard error DTD from the Notifying object.
> >
> > Finally, (my thoughts cleaned up with this discussion), this is not the
> > fixed DTD I am criticizing, but the fixed generator.
>
> A Generator translates "information-entities" in XML. When the
> "information-entitiy" (Notifying and Env) are defined and the DTD is
> defined... the Generator is defined. If you want to "filter" the Notifying,
> you can make your own Builder. The Builder is basically a filter that gives
> you the flexibility that multiple Generators have without the possible
> varying DTD.
> What you need, I think, is to be able to decide the mapping between the
> Notifying and the DTD. But the notifying and the DTD basically mimic the
> same structure; the Builder can filter and transform your Notigying to your
> needs.
Once again, the use case is not filtering the Notifying contents, but
generating something completely different, this generation being
triggered by the fact that an exception occured and that some selector
directed to that generator.
In that case, the information-entity isn't defined : the Notifying is
just additional data which complements the environment and object model
to _choose_ the content, i.e. direct pipeline assembly, as matchers and
selectors do in regular pipelines.
Let's consider a very common use case : most sites display nice pages
when a requested URL doesn't exist instead of the raw "404-not found"
server message.
The below sitemap snippet shows an implementaton of this behaviour : the
"notyfing-type" selector selects a branch depending on the value of
Notifying.getType(). When a resource isn't found (type
"rsrc-not-found"), the page to display uses the same content DTD and
pipeline definition than other parts of the site. In this example, a
standard page is a resource that aggregates page content and some common
elements.
<map:resource name="site-page">
<!-- standard layout of the site -->
<map:aggregate element="page">
<map:part src="top-menu.xml" element="top"/>
<map:part src="{page}" element="content"/>
<map:part src="sidebar.xml" element="side"/>
<map:aggregate/>
<map:transform src="site-page2html.xsl"/>
<map:serialize/>
</map:resource>
<map:handle-errors>
<map:select type="notifying-type">
<map:when test="rsrc-not-found">
<!-- display the not-found page -->
<map:call resource="site-page">
<map:parameter name="page" value="not-found.xml"/>
</map:call>
</map:when>
<map:otherwhise>
<!-- generic formatting of the error DTD -->
<map:generate type="notifying"/>
<map:transform src="error2html.xsl"/>
<map:serialize/>
</map:otherwhise>
</map:select>
</map:handle-errors>
This example may seem complex (a resource with an aggregation), but I'm
sure it corresponds to real-world use cases.
> <snip/>
>
> > >>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.
> >
> >
> > Patch applied. My -1 is also pushed away because the discussion has some
> > very constructive results.
>
> :-)
>
> > > 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?
> >
> > Mostly : clean logging, single Notifying, single <handle-errors>. The
> > last remaining point is about non-fixed generator (didn't said DTD) in
> > <handle-errors>.
>
> The problem is that you can't give flexibility of changing Generator while
> fixing a DTD. IMO the Builder should do it. Comments?
See the sitemap snippet above. Fixed DTD is OK when the content is the
Notifying. But you don't always want the Notifying as the content.
> > We also have some compatibility issues : what about the existing
> > multiple-<handle-errors> pipelines ?
>
> Good point.
> I would keep it in the code for now and change the current webapp sitemaps
> to use the new concept.
> Then deprecate it, like redirects, and remove it in future releases.
>
> > > I will post more examples and use cases for the use, so things are
> > > better explained.
> >
> > Eagerly waiting ;)
> >
> > > 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?
> >
> > Browser-view would be cool : a swing gui means you need to sit in front
> > of the server (win$) or are able to export it's display (Unix), which
> > isn't always the case, and tremendously slows down the system.
>
> I think so too.
>
> > My thoughts about it is a special LogKit LogTarget that buffers
> > LogEvents for a request and a special generator that turns these events
> > to XML. The information put in LogKit's context map (see above) is the
> > key to per-request event filtering.
>
> As for the Generator, isn't there something that logs in XML. How much use
> can come from that?
Checkout org.apache.cocoon.util.log.XMLCocoonLogFormatter. It outputs
XML as text, but the DTD good be a good starting point.
> But thinking of it, maybe an HTML appender that completely bypasses Cocoon
> could be better, because it doesn't interfere.
Mmmh. Not so sure, because interferences can be easily filtered using
either the request id or URI that are in LogKit's ContextMap. And having
this feature as Cocoon components can be a starting point for a
full-featured log management webapp.
<snip/>
> > > I like discussions, the important thing is that they are based on facts
> > > and are constructive.
> >
> > Cool. I share this view :)
> >
>
> :-)
>
> Happy New Year!
Thanks. Happy New Year to you also, and to the great Apache community.
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Refactoring and correction of error notification
Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
----- Original Message -----
From: "Sylvain Wallez" <sy...@anyware-tech.com>
To: <co...@xml.apache.org>
Sent: Tuesday, January 01, 2002 9:39 PM
Subject: Re: Refactoring and correction of error notification
<snip cut-by="NKB">I'm cutting big chunks in the mail because the focus
shifted and new "aspects" of the discussion are arising. The previous mail
sums up all the conversation.</snip>
>
> The browser view would be cool. What about the following behaviour :
> request a special URL in a browser window, which waits until a new
> request (started in another window) or an URL pattern is handled by
> Cocoon and outputs the logs issued during that request ?
>
> CocoonServlet already puts the object model and a request-id in LogKit's
> context map (see CocoonServlet.java:791) that could be used to identify
> requests.
>
> Thoughts ?
+1
> >>>>>>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
>
> Cool, but +1 for what : INFO or system-wide categories ?
+1 for logging instead of Notifications ;-)
> >>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.
>
>
> OK. Let's abandon the multiple handle-errors pipeline in favor of an
> "error-type" selector.
>
<snip/>
> >
> > 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.
>
> Am I biased by the current implementation ? SimpleNofiyingBean only
> accepts Strings as extra descriptions
Yes, because it's... well... simple ;-)
> and Notifier performs a toString()
> on entries of the Map. That's why I thought it was restricted to Strings.
I need to write docs, there are new concepts in this code that need to be
explained because they aren't self-explaining.
> >>>>>>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!
>
>
> That's not really a difference : as I said above, each handle-errors can
> be considered as an independent pipeline.
>
> But I'm OK with the selector : this is even more flexible since we can
> select on anything, and not only Notifying.getType() ;)
>
<snip/>
> >>> Ken: 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?
>
> I can't set my own generator in <handle-errors>. I'm happy with a fixed
> DTD for exception reports to the user. But I would like to be able to
> generate something else than the error DTD in some branches of the
> "error-type" select statement.
Why?
> This what my example with several <handle-errors> was all about : each
> branch has a different generator, the "notification" generator being the
> one that issues the standard error DTD from the Notifying object.
>
> Finally, (my thoughts cleaned up with this discussion), this is not the
> fixed DTD I am criticizing, but the fixed generator.
A Generator translates "information-entities" in XML. When the
"information-entitiy" (Notifying and Env) are defined and the DTD is
defined... the Generator is defined. If you want to "filter" the Notifying,
you can make your own Builder. The Builder is basically a filter that gives
you the flexibility that multiple Generators have without the possible
varying DTD.
What you need, I think, is to be able to decide the mapping between the
Notifying and the DTD. But the notifying and the DTD basically mimic the
same structure; the Builder can filter and transform your Notigying to your
needs.
<snip/>
> >>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.
>
>
> Patch applied. My -1 is also pushed away because the discussion has some
> very constructive results.
:-)
> > 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?
>
> Mostly : clean logging, single Notifying, single <handle-errors>. The
> last remaining point is about non-fixed generator (didn't said DTD) in
> <handle-errors>.
The problem is that you can't give flexibility of changing Generator while
fixing a DTD. IMO the Builder should do it. Comments?
> We also have some compatibility issues : what about the existing
> multiple-<handle-errors> pipelines ?
Good point.
I would keep it in the code for now and change the current webapp sitemaps
to use the new concept.
Then deprecate it, like redirects, and remove it in future releases.
> > I will post more examples and use cases for the use, so things are
better
> > explained.
>
> Eagerly waiting ;)
>
> > 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?
>
> Browser-view would be cool : a swing gui means you need to sit in front
> of the server (win$) or are able to export it's display (Unix), which
> isn't always the case, and tremendously slows down the system.
I think so too.
> My thoughts about it is a special LogKit LogTarget that buffers
> LogEvents for a request and a special generator that turns these events
> to XML. The information put in LogKit's context map (see above) is the
> key to per-request event filtering.
As for the Generator, isn't there something that logs in XML. How much use
can come from that?
But thinking of it, maybe an HTML appender that completely bypasses Cocoon
could be better, because it doesn't interfere.
> >>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.
>
> Thanks :)
>
> > I like discussions, the important thing is that they are based on facts
and
> > are constructive.
>
> Cool. I share this view :)
>
:-)
Happy New Year!
Ken
--
Nicola Ken Barozzi xml-cocoon@nicolaken.com
These are the days of miracle and wonder...
...so don't cry baby, don't cry...
Paul Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org