cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Curran <daniel.cur...@dotech.com>
Subject Re: Return Error Code Based on Pipeline Content
Date Fri, 14 Apr 2006 02:38:13 GMT
I changed the order and this did not change the results of the test. The 
RuntimeException is still the exception being chosen. 
StatusCode501Exception is not a RuntimeException but is instead causes a 
RuntimeException.

The way I am reading it. The ProcessingException is caused by a 
RuntimeException which is caused by a StatusCode501Exception.

I think that my next step will be creating my own instance of the 
ExceptionSelector and then adding logging to it so that I can observe 
where the failure in unrolling the exception is being caused. 
RuntimeException looks to be where the chain stops, I still need to 
figure out why, and create a work around that does not require a huge 
change.

I am not sure that I understand the case where find(Throwable thr) 
returns a new FindResult when an Exception set as unroll="true" is not 
unrolled. From my perspective I would think that this should throw a 
ConfigurationException. As I am new to the uses of this selector I might 
be missing an obvious case where throwing this exception would be 
undesirable.

Dan

Ralph Goers wrote:
> 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



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


Mime
View raw message