cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [PROPOSAL] Extending Sitemap Error Handling
Date Thu, 11 Jul 2002 08:30:11 GMT
Nicola Ken Barozzi wrote:

> Sylvain Wallez wrote:


>>> Wouldnt the ability to have custom handle-errors generators make it 
>>> more likely that the handle-errors pipe would throw the very 
>>> error/exception thats its trying to handle..and wouldnt this cause 
>>> an infinate loop?
>> No risk of infinite loops, as exceptions occuring inside a 
>> <handle-errors> aren't processed again by the sitemap. Also, not only 
>> generators can throw exceptions, but also matchers, transformers, 
>> actions, etc. which are allowed in handle-errors.
> Sylvain, you know what?
> You're right :-)
> A generator can fail in handle-errors with no real problem, if not 
> that the error is then processed by the servlet, as with any other 
> failing component in that part of pipeline.
> The only thing that has to be avoided is redirects.
> As for having different DTDs, it's not a problem, since users will 
> presumably use the supplied Generator for notifications, and also 
> error handling pipelines are usually very simple.
> Sylvain, now listen to me.
> Sit down, and stay calm...
> <drums rolling...>
> I remove my -1 on using custom Generators from handle-errors.
> Hey, Sylvain, don't faint ;-P

Woohoo ! No, I didn't faint, as I was prepared by the drums !

> Yes, for me it's +0 to enable generators in handle-errors, given that
> 1 there are no -1s for this (I'm not sure I was the only one) 


> 2 that redirects are completely banned from handle-errors. 

Can be checked.

> 3 that the NotifyingGenerator simply notifies what is given in a 
> well-known and public key of the Context (rather than hidden), that it 
> fails gracefully if not present (outputs an empty notification), and 
> that it's called automatically if not defined (backwards compatibility).

You mean "object model" and not "context", right ? Currently, the 
NotifyingGenerator throws a ProcessingException if there is no Notifying 
in the object model, and IMO it's wiser than silently generating an 
empty notification. Don't you think so ?

To ensure maximum backward compatibility with the current implicit 
generator, and considering that we deprecate the "type" attribute on 
handle-errors, I propose to require an explicit generator for 
handle-errors _without_ the "type" attribute and keep the current 
implicit generator for handle-errors _with_ this attribute.

The effect is that current sitemaps that have a "type-less" 
handle-errors can be ported by simply adding a type="500". An adequate 
error message will help people to migrate smoothly.

> This way users can use it to just notify things directly from actions 
> if needed, even if they are not errors.

Yes, this will finally allow a wider usage of the notification stuff.

> After/if you do the change, I will see what can be done to nuke the 
> Builder someway if better (seems so now, just need to check).

Why do you want to nuke it ? We just need to add configuration stuff to 
have some meaningful getType().

As for doing the change, Vadim reminded us there are some bugs to 
correct, and I still have my paid-work to do :-/ I should have some time 
for Cocoon development bu the end of the month and in august.

So if nobody objects, let's add this to the todo list for 2.1.


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message