cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [heads up!] new error handling fails weirdly!
Date Mon, 07 Apr 2003 09:05:51 GMT
Stefano Mazzocchi wrote:

>I've updated cvs today and rebuilt my cocoon. I'm following gump-mode and I'm crazily
developing the web site I'm working on against Cocoon-2.1 HEAD and I'm updating every week
or so. I'm basically debugging cocoon along with my work.
>Anyway, today I updated cvs and recompiled. I relaunched and all went well. But then,
during development, I got:
>  Request Processing Failed
>  Message: Cocoon engine failed in process the request
>  Description: The processing engine failed to process the request. This could be due
to lack of matching or bugs in the pipeline engine.
>This is the infamous "cocoon confusion" error that I recently updated to a more friendly
>Still, the problem remain: the above is the most cryptical error message we can give to
our developer.
>Yes, *developer*. I normally expect to see important error information *directly* in my
browser window before I freeze my site and I build it for production.
>I normally even use an 'IP selector' in my error handling pipeline so that I can still
get useful stacktraces from localhost or from my subnetwork.

Clever : we should add this in the default sitemap (e.g. only localhost 
gets stacktraces).

>Anyway, the above message suggests me to look into the sitemap for a mismatch.... but
after careful looking, there is none.
>Hmmmm, so I get suspicious and open up the logs and *holy cow* I have 300Kb of error.log
for a few reloads!!! what's going on? I open it up and I get:
> ERROR   (2003-04-06) 23:28.10:671   [sitemap] (/admin/index) PoolThread-3/PipelineNode:
Error notifier is unable to notify the problem. Please check the logs. In the default webapp,
look in the WEB-INF/logs dir.
>org.apache.cocoon.ProcessingException: Incomplete pipeline :
>'handle-error' without a 'type' must include a generator, at
>Either add a generator (preferred) or a type='500' attribute
>(deprecated) on 'handle-errors'

>Despite the stacktrace, the messages I get are:
>1) "Error notifier is unable to notify the problem. Please check the logs. In the default
webapp, look in the WEB-INF/logs dir."
>Ah, thanks, that helps. I am *already* looking into the logs! If the error notifier was
unable to notify the problem, how in hell am I suppose to see this message if not directly
from WEB-INF/logs?
>These are things that really trash our usability as they get *extremely* irritating. Cocoon
should never appear *dumb* and this is clearly the case here.
>2) org.apache.cocoon.ProcessingException: Incomplete pipeline :
>'handle-error' without a 'type' must include a generator, at file:/Users/stefano/Code/ormaz/sito/sitemap.xmap:554:24
>Either add a generator (preferred) or a type='500' attribute (deprecated) on 'handle-errors'
>Wait a second!
>Deprecation doesn't mean that it's suddently gone!
>This error is basically saying that my sitemap *requires* modification in order to run!
This means that Cocoon 2.1-dev it's currently *NOT* transparently back compatible with 2.0.x!!!!
>Please confirm because if so, this is a *very* serious issue.

Before reading further, please check

The new error handling allows to put any generator in the error-handling 
pipeline. Combined with the ExceptionSelector, this deprecates the use 
of 'type' attribute on <handle-errors> which is a long-time hack 
allowing to choose only between 404 (ResourceNotFound) and 500 (all 
other exceptions).

The deprecation is about the use of 'type' attributes on <handle-errors> 
: the use of this attribute is still valid, but deprecation encourages 
users to move to using an explicit <generate> and the ExceptionSelector 
in their error handling.

Since the new feature deprecates the use of the 'type' attribute on 
<handle-errors>, the choice between implicit and explicit generator is 
driven by the existence of this attribute.

Why so ? Because I don't like the sitemap engine automagically adding a 
generator if none was given : is the pipeline lacking a generator 
because 2.0 error handling is used, or because the user wanted 2.1 
handling but forgot to write <generate> ? Having the user intention 
unambiguously defined in the sitemap by the user itself seems IMO 
better. This is what is suggested by the message.

Now you're right that this is badly reported to the user. So I just 
updated error handling so that the "Incomplete pipeline : 'handle-error' 
without....." message is now displayed *on screen* instead of being 
hidden in the logs.

>I'm not against the ability to be able to specify a custom generator in the error-handling
pipeline, but I don't want to witness a flood of
> why my sitemap doesn't work?
>messages on the various mail lists, with the automatic perception that cocoon 2.1 is *yet
another* revolutionary step and this is something we have to make all possible efforts to
>Migration *must* be smooth. And smooth, means: install, move my stuff over and enjoy.
period. That's it.
>The only thing that will be tollerated are small issues, those that require a change in
one or two places.

Is adding a type='500' to your <handle-errors> such a big change, 
considering that many sitemaps already have this attribute ?

Note that you already have to define some <pipes> in the <components> 
section for a sitemap to run in 2.1.

>this is a change that requires potentially *tens* of sitemaps to be updated. This is simply
too much of a change for a smooth transition and for something that should be considered 'deprecated'
not simply removed.
>So, a few issues *must* be resolved:
> 1) error handling *must* be totally back compatible. It's ok if a warning is written
in the log, but the processing should not fail.

We have to choose between explicit behaviour driven by the 'type' 
attribute as explained above, or some automagic assumptions in the 
sitemap engine. I'm in favor of the first solution.

We can also have a configuration of the <sitemap> in cocoon.xconf 
allowing to choose between 2.1 strict mode or 2.0 automagic mode.

> 2) the sitemap processing should try to provide more reasonable error messages in case
something like this goes wrong and the tree processor isn't able to process.



Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message