Nicola Ken Barozzi a écrit :
>
> ----- 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
>
<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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
