cocoon-dev mailing list archives

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

> Sylvain Wallez wrote:
>

<snip/>

>>> 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...>
>
> TADA!
>
> 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 !
ROFL ;)

> 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) 


HEY, SOMEONE ELSE ?

> 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

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message