tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r976599 - in /websites/production/tapestry/content: cache/main.pageCache runtime-exceptions.html
Date Tue, 29 Dec 2015 00:20:44 GMT
Author: buildbot
Date: Tue Dec 29 00:20:44 2015
New Revision: 976599

Log:
Production update by buildbot for tapestry

Modified:
    websites/production/tapestry/content/cache/main.pageCache
    websites/production/tapestry/content/runtime-exceptions.html

Modified: websites/production/tapestry/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/tapestry/content/runtime-exceptions.html
==============================================================================
--- websites/production/tapestry/content/runtime-exceptions.html (original)
+++ websites/production/tapestry/content/runtime-exceptions.html Tue Dec 29 00:20:44 2015
@@ -67,7 +67,7 @@
       </div>
 
       <div id="content">
-                <div id="ConfluenceContent"><p>Feedback is vitally important
when developing an application, and that is one of the areas where Tapestry has always excelled.</p><p>Especially
during development, requests can fail. There can be errors in templates, broken code in your
application, or something unexpected.</p><p>Tapestry has a built-in exception
report page that captures an amazing wealth of information:</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image confluence-content-image-border"
width="500" src="runtime-exceptions.data/Exception_Stack_Trace.png"></span></p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img class="confluence-embedded-image
confluence-content-image-border" width="500" src="runtime-exceptions.data/Exception_Request.png"></span></p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img class="confluence-embedde
 d-image confluence-content-image-border" height="443" width="500" src="runtime-exceptions.data/Application_Exception.png"></span></p><p>This
exception report features:</p><ul><li>The full stack of exceptions, top
to bottom.</li><li>All non-null properties of each exception.</li><li>The
stack trace&#160;<em>at the deepest level</em>.</li><li>Key&#160;<strong>request</strong>
properties, header, attributes, and parameters.</li><li>Key&#160;<strong>session</strong><em>&#160;</em>propertes</li><li>A
break down of the&#160;<em>thread</em> in your application</li><li>A
listing of all JVM System properties<br clear="none"><br clear="none"></li></ul><p>In
addition, Tapestry will write a text file for the exception with a similar level of detail.</p><p>This
exception report is also built-in to Tapestry's Ajax support. When an Ajax request fails,
Tapestry's client-side code will create an &lt;iframe&gt; to present this same information:</p><p><span
class="confluence-embedded-file-wrapper conf
 luence-embedded-manual-size"><img class="confluence-embedded-image confluence-content-image-border"
height="359" width="500" src="runtime-exceptions.data/Exception_Ajax.png"></span></p><p>In
production, you may want to <a  href="overriding-exception-reporting.html">override
the exception report page</a> (but will likely keep the text file output). However,
Tapestry's (from version 5.4) default exception reporter also allows you to handle specific
exception types in a pre-determined manner, similar to how servlet spec's standard error-page/exception-type
configuration option allows you to map exception types to URLs. At times, it's simpler to
just catch exceptions at the outermost layer of your application instead of carrying a typed
exception through multiple layers of abstractions just so you could show a sensible error
message to the user, especially if you can't do anything more clever about it anyway. Exception
type mapping in Tapestry is much more powerful than what the servlet
  spec dictates. If your email service or an external payment service goes down, you can't
do much more than display an error message to the user, so why would you need to implement
separate pages for each exception? Often, it'd be nicer if you could just reuse the page template
for any fatal exception and simply display a different error message. In addition to contributing
handlers for specific types of exceptions, you may also provide context for rendering the
same error page template with a different output.</p><p>You can contribute an
error page, mapping it to an exception type:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+                <div id="ConfluenceContent"><p>Feedback is vitally important
when developing an application, and that is one of the areas where Tapestry has always excelled.</p><p>Especially
during development, requests can fail. There can be errors in templates, broken code in your
application, or something unexpected.</p><p>Tapestry has a built-in exception
report page that captures an amazing wealth of information:</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image confluence-content-image-border"
width="500" src="runtime-exceptions.data/Exception_Stack_Trace.png"></span></p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img class="confluence-embedded-image
confluence-content-image-border" width="500" src="runtime-exceptions.data/Exception_Request.png"></span></p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img class="confluence-embedde
 d-image confluence-content-image-border" height="443" width="500" src="runtime-exceptions.data/Application_Exception.png"></span></p><p>This
exception report features:</p><ul><li>The full stack of exceptions, top
to bottom.</li><li>All non-null properties of each exception.</li><li>The
stack trace&#160;<em>at the deepest level</em>.</li><li>Key&#160;<strong>request</strong>
properties, header, attributes, and parameters.</li><li>Key&#160;<strong>session</strong><em>&#160;</em>propertes</li><li>A
break down of the&#160;<em>thread</em> in your application</li><li>A
listing of all JVM System properties<br clear="none"><br clear="none"></li></ul><p>In
addition, Tapestry will write a text file for the exception with a similar level of detail.
The default location for the exception files is a relative directory <em>build/exceptions</em>.
You can configure the location by setting <a  class="external-link" href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/SymbolConstants
 .html#EXCEPTION_REPORTS_DIR">SymbolConstants.EXCEPTION_REPORTS_DIR</a>.</p><p>This
exception report is also built-in to Tapestry's Ajax support. When an Ajax request fails,
Tapestry's client-side code will create an &lt;iframe&gt; to present this same information:</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img class="confluence-embedded-image
confluence-content-image-border" height="359" width="500" src="runtime-exceptions.data/Exception_Ajax.png"></span></p><p>In
production, you may want to <a  href="overriding-exception-reporting.html">override
the exception report page</a> (but will likely keep the text file output). However,
Tapestry's (from version 5.4) default exception reporter also allows you to handle specific
exception types in a pre-determined manner, similar to how servlet spec's standard error-page/exception-type
configuration option allows you to map exception types to URLs. At times, it's simpler to
just catch exceptions at t
 he outermost layer of your application instead of carrying a typed exception through multiple
layers of abstractions just so you could show a sensible error message to the user, especially
if you can't do anything more clever about it anyway. Exception type mapping in Tapestry is
much more powerful than what the servlet spec dictates. If your email service or an external
payment service goes down, you can't do much more than display an error message to the user,
so why would you need to implement separate pages for each exception? Often, it'd be nicer
if you could just reuse the page template for any fatal exception and simply display a different
error message. In addition to contributing handlers for specific types of exceptions, you
may also provide context for rendering the same error page template with a different output.</p><p>You
can contribute an error page, mapping it to an exception type:</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent pane
 lContent pdl">
 <pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">  
 public void contributeExceptionHandler(MappedConfiguration&lt;Class, Class&gt; configuration)
{
         configuration.add(SmtpNotRespondingException.class, ServiceFailure.class);
     }</pre>



Mime
View raw message