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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
