----- Original Message -----
From: "Sylvain Wallez" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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 [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]
