Hi Geert,
Very nice -- 2 lines of code! :)
* Will this be part of the RIFE 1.5 release, or on the next trunk?
Josh
Geert Bevin wrote:
Hi Joshua,
I added support for this in the repository and it'll thus be in this
night's snapshot:
http://rifers.org:8088/changelog/rifers/?cs=3335
Thanks for thinking into this direction!
Geert
On 03 Jul 2006, at 19:12, Joshua Hansen wrote:
I should correct an ambiguous statement about Jetty here:
"In this case, Jetty doesn't handle the situation (correctly) because
there is no valid RIFE instance to hand it to."
should read:
"In this case, Jetty (correctly) doesn't handle the situation because
there is no valid RIFE instance to hand it to."
I also changed the subject on the post.
Josh
--
Joshua Hansen
Up Bear Enterprises
(541) 760-7685 (new #)
Joshua Hansen wrote:
Hi Geert,
Haha -- thanks! :)
I just did quick test on your response 500 question with Jetty
using, as you said, PRETTY_ENGINE_EXCEPTIONS set to false. It looks
like there are two scenarios:
1) The 500 is caused by a failure in RIFE start up. In this case,
Jetty doesn't handle the situation (correctly) because there is no
valid RIFE instance to hand it to.
Tested by: using rife-crud-1.1-jdk14.jar and rife-crud-1.1-
templates.jar w/ a JDK 1.5 installation. These generate a "SEVERE:
java.lang.NoClassDefFoundError: rife/retroweaver/ ClassLiteral" error
for me. Using the rife-crud-1.2-jdk15.jar and
rife-crud-1.2-templates.jar works fine. Alternately, I tried just
commenting out the datasource in the config.xml, and this only
produced a 404, presumably because RIFE is able to correctly
identify a misconfiguration and gracefully shuts down allowing the
container to not install the mapping or filter.
2) The 500 is caused by an exception in an element in an otherwise
valid instance of RIFE. In this case, the error _is_ handled. This
also assumes the destination page doesn't have any exceptions of its
own. :)
Tested by: coding an element to explicitly throw an EngineException,
then navigating to that element.
I also went ahead and tried doing a setRequestAttribute() (as you
were thinking) with the custom exception I was throwing in scenario
2, and I was able to successfully read it and display it from the
destination page. So, your approach should work. Snippets are
pasted following my sig.
Josh
--
Joshua Hansen
Up Bear Enterprises
(541) 760-7685 (new #)
======[ Exception-throwing Element snippet ]=========
...
public void processElement()
{
EngineException e = new EngineException("Bogus exception.
Testing 500 response.");
setRequestAttribute("exception", e);
throw e;
}
...
=================================
======[ 'site.xml' (Destination Element) snippet ]=========
...
<element id="PAGE505" url="500"
implementation="com.test.ErrorPage">
<property name="name">500</property>
</element>
...
=================================
======[ 'ErrorPage.java' (Destination Element) snippet ]=========
...
public void processElement()
{
Template template = getHtmlTemplate("500");
if ( hasRequestAttribute("exception") ) {
EngineException e = (EngineException)
getRequestAttribute("exception");
String exString = e.toString();
String exHtmlText = exString.replaceAll("\n", "<br /> \n");
template.setValue("error", exHtmlText );
} else {
template.setValue("error", "Unknown Error");
}
print(template);
}
...
=================================
======[ '500.html' template snippet ]=========
<!--I 'common.blueprint'/-->
<!--BV 'content' -->
<h1 class="top">Error</h1>
<!--V 'error'/-->
<a href="[!V 'EXIT:QUERY:home'/]">Home</a>
<!--/BV-->
=================================
======[ 'web.xml' snippets ]=========
...
<filter-mapping>
<filter-name>RIFE</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>ERROR</dispatcher>
<dispatcher>INCLUDE</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
...
<error-page>
<error-code>500</error-code>
<location>/500</location>
</error-page>
...
=================================
Geert Bevin wrote:
Hi Joshua,
thanks a lot for adding this page. I'm not sure I told you before,
but I think this is a very clever way of still adding error-page
handling until RIFE has native support for it. Even without that,
it allows you to easily build error-page handling with RIFE for
any other solution :-)
Btw, have you tried to do this with other responses too, like 500,
when a real exception occurs? (you probably need to set
PRETTY_ENGINE_EXCEPTIONS config param to false). If those
dispatchers also work, then I wonder if the error handler has
access to the same request attributes as the initial handler. If
so, I can add the exception itself as a request attribute so that
it can be introspected by the error handler.
Best regards,
Geert
On 03 Jul 2006, at 17:33, Joshua Hansen wrote:
Hi Geert,
Good memory! I hadn't forgotten, but now was a good time for me
to go ahead and do it. Thanks for checking again and the reminder.
A writeup w/ explanation and slightly restructured info is now
posted on the Wiki under Tips and Tricks -> Using RIFE to Serve
404, 403, etc. Responses :
http://rifers.org/wiki/display/RIFE/Using+RIFE+to+Serve+404%2C
+403% 2C+etc.+Responses
Thanks for all the great work on RIFE!
Josh
Geert Bevin wrote:
Hey Josh,
If you're still planning on putting http://article.gmane.org/
gmane.comp.java.rife.user/2483 on the wiki, I think that this
would be the best place now: http://rifers.org/wiki/display/
RIFE/ Tips+and +Tricks
Take care,
Geert
On 03 Jul 2006, at 15:31, Joshua Hansen wrote:
Also here.
Josh
Geert Bevin wrote:
Hi guys,
Steve wrote me a small mail to ask if there was trouble with
the mailing list. Apparently he hasn't received many of this
week's posts. However, they are present in the archives.
Please reply to this message when you get it.
Thanks!
Geert
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users