cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: Return Error Code Based on Pipeline Content
Date Thu, 13 Apr 2006 23:55:48 GMT
I seem to recall you need to do:
<map:selector name="exception" 
src="org.apache.cocoon.selection.ExceptionSelector">
   <exception name="process" 
class="org.apache.cocoon.ProcessingException" unroll="true"/>
   <exception name="e501" class="com.dotech.util.StatusCode501Exception"/>
   <exception name="runtime" class="java.lang.RuntimeException" 
unroll="true"/>
</map:selector>

I'm actually surprised because if StatusCode501Exception is a 
RuntimeException I would expect you to be getting a 
ConfigurationException as the runtime exception hides the e501 exception.

Ralph

Daniel Curran wrote:

> I have put another 4 hours into looking at this.
>
> I believe that I should be using unroll="true" on the exceptions in 
> order to dig down to the appropriate exception.
>
> When I generate="notifying" my exception looks as such -
>
> org.apache.cocoon.ProcessingException: Exception in 
> StreamGenerator.generate(): java.lang.RuntimeException: 
> java.lang.RuntimeException: com.dotech.util.StatusCode501Exception: 501
>
> In this case I want access to com.dotech.util.StatusCode501Exception. 
> My selectors section in components has the following.
>
> <map:selector name="exception" 
> src="org.apache.cocoon.selection.ExceptionSelector">
>    <exception name="process" 
> class="org.apache.cocoon.ProcessingException" unroll="true"/>
>    <exception name="runtime" class="java.lang.RuntimeException" 
> unroll="true"/>
>    <exception name="e501" 
> class="com.dotech.util.StatusCode501Exception"/>
> </map:selector>
>
> I have my handle-errors section setup to select on these exceptions, 
> and a transform outputs an indication of which <map:when> path was taken.
>
> The expected behavior is that <map:when test="e501"> is going to be 
> the chosen path, but the selected path is <map:when test="runtime"/>
>
> I have inspected ExceptionSelector.java and the recursive function 
> find(Throwable thr) looks like it should be digging down through 
> RuntimeException to expose StatusCode501Exception.
>
> My idea now is that in order to unroll an exception the exception must 
> at some point extend 
> org.apache.commons.lang.exception.NestableException, and that 
> java.lang.RuntimeException obviously does not extend this exception.
>
> I might be off base with this estimate as I haven't had the time to 
> dig deeper into the source code. If anyone knows anything about this 
> bit of code I would be interested in more information on it. If this 
> is the case is there anyway that I could get around the 
> RuntimeException problem?
>
> Thanks,
> Dan
>
> Daniel Curran wrote:
>
>> It turns out that my transform was setup incorrectly.
>>
>> Instead of throwing an exception for a status code of 200, I was 
>> getting the default status code of 200 back as I was returning well 
>> formatted XML.
>>
>> I am now running up against a problem of correctly catching my thrown 
>> exception. When an exception is thrown at runtime via XSLT it is 
>> caught as an org.apache.cocoon.ProcessingException.
>>
>> What this does is cause all of the different exceptions I am throwing 
>> to be treated as a ProcessingException by the sitemap.
>>
>> <map:selector name="exception" 
>> src="org.apache.cocoon.selection.XPathExceptionSelector">
>>          <exception name="200" 
>> class="com.dotech.util.StatusCode200Exception"/>
>>          <exception name="201" 
>> class="com.dotech.util.StatusCode201Exception"/>
>>          <exception name="202" 
>> class="com.dotech.util.StatusCode202Exception"/>
>>          <exception name="404" 
>> class="com.dotech.util.StatusCode404Exception"/>
>>          <exception name="405" 
>> class="com.dotech.util.StatusCode405Exception"/>
>>          <exception name="406" 
>> class="com.dotech.util.StatusCode406Exception"/>
>>          <exception name="500" 
>> class="com.dotech.util.StatusCode500Exception"/>
>>          <exception name="501" 
>> class="com.dotech.util.StatusCode501Exception"/>
>> </map:selector>
>>
>> None of the above selections end up matching.
>>
>> I have been attemping to use the the java code for the exception I am 
>> throwing is -
>>
>> public class ThrowException{
>>    public static void statusCode200() throws StatusCode200Exception {
>>       throw new  StatusCode200Exception("200");
>>    }
>>
>>    ... other methods for the different status codes in the same 
>> pattern ...
>> }
>> class StatusCode200Exception extends Exception {
>>     public StatusCode200Exception(String error){
>>       super(error);
>>    }
>>
>>    ... other status types in same pattern ...
>>
>> }
>>
>> My question now becomes how would I go about trapping the portion of 
>> the processing exception with a xpath expression.
>>
>> I have tried something like -
>> <map:selector name="exception" 
>> src="org.apache.cocoon.selection.XPathExceptionSelector">
>>    <exception name="process" 
>> class="org.apache.cocoon.ProcessingException">
>>       <xpath name="200" test="getMessage=200"/>
>>    </exception>
>> </map:selector>
>>
>> But I the test is not matching correctly. I must be doing something 
>> wrong with my xpath test. Any ideas?
>>
>> Thanks,
>> Dan
>>
>> Daniel Curran wrote:
>>
>>> Since I need to make a choice between a number of different 
>>> exceptions to throw I used a xalan java extension, and then an 
>>> exception selector in the handle-errors section.
>>>
>>> This did the trick. In the transform I have defined 
>>> <exception:statusCode200/> which will cause Java to throw a 
>>> StatusCode200Exception which I can pick up in the handle-errors 
>>> section and return <map:serialize type="xml" status-code="200"/>
>>>
>>> Using the java extension allows me to easily define which error code 
>>> that I wish to throw and to pick based on an xsl:if or xsl:choose.
>>>
>>> Thanks for the advice, it worked out great,
>>> Dan
>>>
>>> Joerg Heinicke wrote:
>>>
>>>> On 10.04.2006 08:34, Bertrand Delacretaz wrote:
>>>>
>>>>> I don't think there is a standard way of throwing Exceptions from 
>>>>> XSLT code, but calling a small Java extension class from XSLT to 
>>>>> throw the Exception should do the trick, if you need to do this 
>>>>> from XSLT.
>>>>
>>>>
>>>> I could not read from his message that he needs exceptions from 
>>>> XSLT, but there is an easy solution for it: <xsl:message 
>>>> terminate="yes"/>.
>>>>
>>>> Regards,
>>>>
>>>> Jörg
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>


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


Mime
View raw message