Sylvain Wallez wrote:
> Michael Melhem wrote:
>
>> Dear Cocoon community,
>>
>> It seems to me that pipelines can only handle two error cases: Namely
>> error 500 (General Exception) and error 404 (ResourceNotFoundException).
>>
>> There appears to be no way currently to handle specific errors that
>> might be thrown by pipeline components other than to render a general
>> Error 500 page. Am I mistaken?
>>
>> For example, it may be the case that a custom built generator could
>> throw custom Exceptions that a developer would like to handle in a
>> specific fashion.
>>
>> To that end, I propose that pipeline be extendend so that it they can
>> handle X number of errors depending on the amount of
>> <map:handle-errors> defined in the sitemap for that pipeline.
>>
>> <sitemap>
>> ...
>>
>> <map:handle-errors type="500">
>> <map:transform src="stylesheets/error2html.xsl"/>
>> <map:serialize/>
>> </map:handle-errors>
>>
>> <map:handle-errors type="404">
>> <map:transform src="stylesheets/error2html.xsl"/>
>> <map:serialize />
>> </map:handle-errors>
>>
>> <!-- one more or extra error-handles -->
>> <map:handle-errors type="someSpecificException">
>> <-- "type" here could me some sort of short code or the actual
>> full name of the Exception class? -->
>> <map:transform src="stylesheets/SpecificError2html.xsl"/>
>> <map:serialize status-code="500"/>
>> </map:handle-errors>
>>
>> etc..
>> </sitemap>
>>
>> Does anyone see any problems with this approach? Comments?
>>
>>
>
> I like this, and proposed something similar back in december (see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100739814405987&w=2)
>
> It didn't had much acceptance at that time both because it involved
> class names in the pipelines and because Nicola Ken was refactoring
> error notification ;)
And because it isn't strictly needed ;-)
> But I still would like to have something like this, as I think having to
> write a <handle-errors type="500"> and then using a <map:select> to
> select depending on the error type is counter-intuitive.
no, you would have a <handle-errors>, we decided that type="" would be
deprecated, since it's redundant.
> When an exception occurs, the sitemap engine builds a Notifying object
> that is available within the <handle-errors>. This Notifying has a
> getType() method which is exactly what we need for this "type" attribute.
There are many other attributes, not only getType.
I wrongly assumed that it would be a "level" of error.
We should start giving it a real meaning.
> But getType() always returns "error" unless your exception implements
> Notifying (which none does, and IMO having an exception implement
> Notifying to drive sitemap error-handling is mixing concerns).
Not really true...
> So we
> could configure the NotifyingBuilder so that it can associate exception
> classes to notifying types.
>
> <notifying-builder>
> <type name="404" src="org.apache.cocoon.ResourceNotFoundException"/>
> <type name="500" src="org.apache.cocoon.ProcessingException"/>
> <type name="access-denied" src="java.lang.SecurityException"/>
> <type name="my-error-case" src="my.app.someSpecificException"/>
> </notifying-builder>
This I like better...
It basically means that you make the mapping of the exception name to an
easy handle...
> Notice the two first lines that ensure compatibility with what we have
> today.
>
> And then in the pipelines :
> <map:handle-errors type="access-denied">
> <map:transform src="accessDenied.xsl"/>
> <map:serialize/>
> </map:handle-errors>
>
> <map:handle-errors type="my-error-case">
> <map:transform src="SpecificError2html.xsl"/>
> <map:serialize status-code="500"/>
> </map:handle-errors>
>
> Thoughts ?
I would rewrite your case like this:
<notifying-builder>
<type name="404" src="org.apache.cocoon.ResourceNotFoundException"/>
<type name="500" src="org.apache.cocoon.ProcessingException"/>
<type name="access-denied" src="java.lang.SecurityException"/>
<type name="my-error-case" src="my.app.someSpecificException"/>
</notifying-builder>
<map:handle-errors>
<map:match type="error" pattern="access-denied">
<map:transform src="accessDenied.xsl"/>
<map:serialize/>
<map:match>
<map:match type="error" pattern="my-error-case">
<map:transform src="SpecificError2html.xsl"/>
<map:serialize status-code="500"/>
<map:match>
<map:match pattern="*">
<map:serialize status-code="500"/>
<map:match>
</map:handle-errors>
But we could simply do:
<map:handle-errors>
<map:match type="error" pattern="access-denied">
<map:transform src="accessDenied.xsl"/>
<map:serialize/>
<map:match>
<map:match type="exception" pattern="my.app.someSpecificException">
<map:transform src="SpecificError2html.xsl"/>
<map:serialize status-code="500"/>
<map:match>
<map:match pattern="*">
<map:serialize status-code="500"/>
<map:match>
</map:handle-errors>
Of course, we will need to put a
<notifying-builder>
<type name="404" src="org.apache.cocoon.ResourceNotFoundException"/>
<type name="500" src="org.apache.cocoon.ProcessingException"/>
<type name="access-denied" src="java.lang.SecurityException"/>
<type name="my-error-case" src="my.app.someSpecificException"/>
</notifying-builder>
thing in cocoon.xconf to handle the major types of errors, so that the
match type="exception" is not used a lot, or even at all.
Other thoughts?
Keep calm Stefano, I know you get nervous when Sylvain and I discuss at
this speed, but believe me, we are communicating, it's not noise ;-P
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
