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