----- Original Message ----- From: "Sylvain Wallez" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
These are the days of miracle and wonder...
...so don't cry baby, don't cry...
Paul Simon
smime.p7s
Description: application/pkcs7-signature
