[portal-commits] JBoss Portal SVN: r8626 - in docs: branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules and 2 other directories.

Author: chris.laprun(a)jboss.com Date: 2007-10-12 21:34:14 -0400 (Fri, 12 Oct 2007) New Revision: 8626 Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/images/errorhandling/errorHandlingUI.png docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/errorhandling.xml docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/wsrp.xml docs/trunk/referenceGuide/en/images/errorhandling/errorHandlingUI.png docs/trunk/referenceGuide/en/modules/errorhandling.xml docs/trunk/referenceGuide/en/modules/wsrp.xml Log: - Minor content improvements. - Updated error handling screenshot to be less wide. Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/images/errorhandling/errorHandlingUI.png =================================================================== (Binary files differ) Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/errorhandling.xml =================================================================== --- docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/errorhandling.xml 2007-10-13 00:08:20 UTC (rev 8625) +++ docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/errorhandling.xml 2007-10-13 01:34:14 UTC (rev 8626) @@ -8,18 +8,19 @@ </author> </chapterinfo> <title>Error handling configuration</title> - <para>JBoss Portal request pipeline provides configuring of the error handling policy. At runtime when an error - occurs it is possible to configure how the portal behaves in a fine grained and dynamic manner.</para> + <para>JBoss Portal's request pipeline allows for fine-grained, dynamic configuration of how Portal will behave when + an error occurs at runtime.</para> <sect1> <title>Error types</title> - <para>There are several kind of errors that can be happen during a request.</para> - <itemizedlist> - <listitem>Access denied: the user does not have the security rights to access a resource</listitem> - <listitem>Error: an expected error, like a portlet threw an exception</listitem> - <listitem>Internal error: an unexpected error</listitem> - <listitem>Resource not found: a resource is not found</listitem> - <listitem>Resource not available: a resource is found but is not serviceable</listitem> - </itemizedlist> + <para>There are several kind of errors that can happen during a request: + <itemizedlist> + <listitem>Access denied: the user does not have the security rights to access a resource</listitem> + <listitem>Error: an anticipated error as when a portlet throws an exception</listitem> + <listitem>Internal error: an unexpected error</listitem> + <listitem>Resource not found: a resource is not found</listitem> + <listitem>Resource not available: a resource is found but is not serviceable</listitem> + </itemizedlist> + </para> </sect1> <sect1> <title>Control policies</title> @@ -28,29 +29,30 @@ <sect2> <title>Policy delegation and cascading</title> <para>Whenever a control policy is invoked it is given the opportunity to change the response sent - by the control flow. If the control policy ignores the error then the next policy will handle the error - at this turn. However if the control policy decides to provide a new response then the next policy - will not be invoked since the new response will not be of type error. For instance, if a portlet part of a page - produces an exception, the following reactions are possible:</para> - <itemizedlist> - <listitem>The error is displayed in the window</listitem> - <listitem>The window is removed from the aggregation</listitem> - <listitem>An portal error page is displayed</listitem> - <listitem>An HTTP 500 error response is sent to the browser</listitem> - </itemizedlist> + by the control flow. If the control policy ignores the error then the next policy will handle the error + at this turn. However if the control policy decides to provide a new response then the next policy + will not be invoked since the new response will not be of type error. For instance, if a portlet part of a + page produces an exception, the following reactions are possible: + <itemizedlist> + <listitem>The error is displayed in the window</listitem> + <listitem>The window is removed from the aggregation</listitem> + <listitem>An portal error page is displayed</listitem> + <listitem>An HTTP 500 error response is sent to the browser</listitem> + </itemizedlist> + </para> </sect2> <sect2> <title>Default policy</title> <para>The default policy applies when error are not handled at other level. By default errors are translated into the most appropriate HTTP response: + <itemizedlist> + <listitem>Access denied: HTTP 403 Forbidden response</listitem> + <listitem>Error: HTTP 500 Internal Server Error response</listitem> + <listitem>Internal error: HTTP 500 Internal Server Error response</listitem> + <listitem>Resource not found: HTTP 404 Not Found response</listitem> + <listitem>Resource not available: HTTP 404 Not Found response</listitem> + </itemizedlist> </para> - <itemizedlist> - <listitem>Access denied: HTTP 403 Forbidden response</listitem> - <listitem>Error: HTTP 500 Internal Server Error response</listitem> - <listitem>Internal error: HTTP 500 Internal Server Error response</listitem> - <listitem>Resource not found: HTTP 404 Not Found response</listitem> - <listitem>Resource not available: HTTP 404 Not Found response</listitem> - </itemizedlist> </sect2> <sect2> <title>Portal policy</title> @@ -61,14 +63,15 @@ </sect2> <sect2> <title>Page policy</title> - <para>Window error policy controls how the page reacts to aggregation errors. Indeed the page is most of the time - an aggregation of several portlet windows and the action to take when an error occurs is different than the other - policies. Whenever an error occurs, the policy can either handle it or ignore it. If the error is ignored then - it will be treated by the portal policy. The different actions that are possible upon an error are:</para> - <itemizedlist> - <listitem>Remove the window from the aggregation</listitem> - <listitem>Replace the markup of the window by a redirection to a JSP page</listitem> - </itemizedlist> + <para>Window error policy controls how the page reacts to aggregation errors. Indeed the page is most of the + time an aggregation of several portlet windows and the action to take when an error occurs is different than + the other policies. Whenever an error occurs, the policy can either handle it or ignore it. If the error is + ignored then it will be treated by the portal policy. The different actions that are possible upon an error are: + <itemizedlist> + <listitem>Remove the window from the aggregation</listitem> + <listitem>Replace the markup of the window by a redirection to a JSP page</listitem> + </itemizedlist> + </para> </sect2> </sect1> <sect1> @@ -310,11 +313,10 @@ clicking on the Properties link on each of these pages. You can also specify how dashboards should behave with respect to error handling by clicking on the Dashboards tab of the Portal management application. </para> - <para>Screenshot:</para> - <para> - <imageobject> - <imagedata fileref="images/errorhandling/errorHandlingUI.png" format="png"/> - </imageobject> + <para>Screenshot: + <imageobject> + <imagedata fileref="images/errorhandling/errorHandlingUI.png" format="png" align="center"/> + </imageobject> </para> </sect1> </chapter> \ No newline at end of file Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/wsrp.xml =================================================================== --- docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/wsrp.xml 2007-10-13 00:08:20 UTC (rev 8625) +++ docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/wsrp.xml 2007-10-13 01:34:14 UTC (rev 8626) @@ -70,7 +70,7 @@ <para> JBoss Portal provides a complete support of WSRP 1.0 standard interfaces and offers both consumer and producer services. WSRP support is provided by the <emphasis>portal-wsrp.sar</emphasis> - service archive, included in the main <emphasis>jboss-portal.sar</emphasis> service archive, if you've + service archive, included in the main <emphasis>jboss-portal.sar</emphasis> service archive, if you've obtained JBoss Portal from a binary distribution. If you don't intend on using WSRP, we recommend that you remove the <emphasis>portal-wspr.sar</emphasis> from the main <emphasis>jboss-portal.sar</emphasis> service archive.</para> @@ -337,35 +337,35 @@ Let's now look at the Admin page and the Management portlet. Click on the "Portlet definitions" tab at the top. Once this is done, look at the list of available portlet providers. If all went well, you should see something similar to this: - <mediaobject> - <imageobject> - <imagedata fileref="images/wsrp/portlets.png" format="png" align="center" valign="middle"/> - </imageobject> - </mediaobject> - </para> - <para> - We have 3 available portlet providers: <emphasis>local, self</emphasis> and <emphasis>bea</emphasis>. The - "local" portlet provider exposes all the portlets deployed in this particular instance of Portal. As - explained above, the "self" provider refers to the default WSRP consumer bundled with Portal that consumes - the portlets exposed by the default WSRP producer. The "bea" provider corresponds to BEA's public producer - we just configured. Select it and click on "Change". You should now see something similar to: - <mediaobject> - <imageobject> - <imagedata fileref="images/wsrp/bea.png" format="png" align="center" valign="middle"/> - </imageobject> - </mediaobject> - </para> - <para> - From there on out, you should be able to configure WSRP portlets just as any other. In particular, you - can create an instance of one of the remote portlets offered by BEA's public producer just like you would - create an instance of a local portlet and then assign it to a window in a page. If you go to that page, you - should see something similar to below for this portlet: - <mediaobject> - <imageobject> - <imagedata fileref="images/wsrp/result.png" format="png" align="center" valign="middle"/> - </imageobject> - </mediaobject> - </para> + <mediaobject> + <imageobject> + <imagedata fileref="images/wsrp/portlets.png" format="png" align="center" valign="middle"/> + </imageobject> + </mediaobject> + </para> + <para> + We have 3 available portlet providers: <emphasis>local, self</emphasis> and <emphasis>bea</emphasis>. The + "local" portlet provider exposes all the portlets deployed in this particular instance of Portal. As + explained above, the "self" provider refers to the default WSRP consumer bundled with Portal that consumes + the portlets exposed by the default WSRP producer. The "bea" provider corresponds to BEA's public producer + we just configured. Select it and click on "Change". You should now see something similar to: + <mediaobject> + <imageobject> + <imagedata fileref="images/wsrp/bea.png" format="png" align="center" valign="middle"/> + </imageobject> + </mediaobject> + </para> + <para> + From there on out, you should be able to configure WSRP portlets just as any other. In particular, you + can create an instance of one of the remote portlets offered by BEA's public producer just like you would + create an instance of a local portlet and then assign it to a window in a page. If you go to that page, you + should see something similar to below for this portlet: + <mediaobject> + <imageobject> + <imagedata fileref="images/wsrp/result.png" format="png" align="center" valign="middle"/> + </imageobject> + </mediaobject> + </para> </sect3> </sect2> @@ -487,7 +487,7 @@ <para> <programlisting><![CDATA[ -<?xml version="1.0" encoding="UTF-8"?> +<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN" "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd"> @@ -526,7 +526,7 @@ <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN" "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd"> - + <deployments> <deployment> <wsrp-producer id="MyProducer" expiration-cache="120"> @@ -557,7 +557,7 @@ <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN" "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd"> - + <deployments> <deployment> <wsrp-producer id="AnotherProducer" expiration-cache="60"> @@ -702,7 +702,7 @@ <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE producer-configuration PUBLIC "-//JBoss Portal//DTD WSRP Local Producer Configuration 2.6//EN" "http://www.jboss.org/portal/dtd/jboss-wsrp-producer_2_6.dtd"> - + <producer-configuration> <registration-configuration fullServiceDescriptionRequiresRegistration="true"> <registration-policy>com.example.portal.SomeCustomRegistrationPolicy</registration-policy> Modified: docs/trunk/referenceGuide/en/images/errorhandling/errorHandlingUI.png =================================================================== (Binary files differ) Modified: docs/trunk/referenceGuide/en/modules/errorhandling.xml =================================================================== --- docs/trunk/referenceGuide/en/modules/errorhandling.xml 2007-10-13 00:08:20 UTC (rev 8625) +++ docs/trunk/referenceGuide/en/modules/errorhandling.xml 2007-10-13 01:34:14 UTC (rev 8626) @@ -8,18 +8,19 @@ </author> </chapterinfo> <title>Error handling configuration</title> - <para>JBoss Portal request pipeline provides configuring of the error handling policy. At runtime when an error - occurs it is possible to configure how the portal behaves in a fine grained and dynamic manner.</para> + <para>JBoss Portal's request pipeline allows for fine-grained, dynamic configuration of how Portal will behave when + an error occurs at runtime.</para> <sect1> <title>Error types</title> - <para>There are several kind of errors that can be happen during a request.</para> - <itemizedlist> - <listitem>Access denied: the user does not have the security rights to access a resource</listitem> - <listitem>Error: an expected error, like a portlet threw an exception</listitem> - <listitem>Internal error: an unexpected error</listitem> - <listitem>Resource not found: a resource is not found</listitem> - <listitem>Resource not available: a resource is found but is not serviceable</listitem> - </itemizedlist> + <para>There are several kind of errors that can happen during a request: + <itemizedlist> + <listitem>Access denied: the user does not have the security rights to access a resource</listitem> + <listitem>Error: an anticipated error as when a portlet throws an exception</listitem> + <listitem>Internal error: an unexpected error</listitem> + <listitem>Resource not found: a resource is not found</listitem> + <listitem>Resource not available: a resource is found but is not serviceable</listitem> + </itemizedlist> + </para> </sect1> <sect1> <title>Control policies</title> @@ -28,29 +29,30 @@ <sect2> <title>Policy delegation and cascading</title> <para>Whenever a control policy is invoked it is given the opportunity to change the response sent - by the control flow. If the control policy ignores the error then the next policy will handle the error - at this turn. However if the control policy decides to provide a new response then the next policy - will not be invoked since the new response will not be of type error. For instance, if a portlet part of a page - produces an exception, the following reactions are possible:</para> - <itemizedlist> - <listitem>The error is displayed in the window</listitem> - <listitem>The window is removed from the aggregation</listitem> - <listitem>An portal error page is displayed</listitem> - <listitem>An HTTP 500 error response is sent to the browser</listitem> - </itemizedlist> + by the control flow. If the control policy ignores the error then the next policy will handle the error + at this turn. However if the control policy decides to provide a new response then the next policy + will not be invoked since the new response will not be of type error. For instance, if a portlet part of a + page produces an exception, the following reactions are possible: + <itemizedlist> + <listitem>The error is displayed in the window</listitem> + <listitem>The window is removed from the aggregation</listitem> + <listitem>An portal error page is displayed</listitem> + <listitem>An HTTP 500 error response is sent to the browser</listitem> + </itemizedlist> + </para> </sect2> <sect2> <title>Default policy</title> <para>The default policy applies when error are not handled at other level. By default errors are translated into the most appropriate HTTP response: + <itemizedlist> + <listitem>Access denied: HTTP 403 Forbidden response</listitem> + <listitem>Error: HTTP 500 Internal Server Error response</listitem> + <listitem>Internal error: HTTP 500 Internal Server Error response</listitem> + <listitem>Resource not found: HTTP 404 Not Found response</listitem> + <listitem>Resource not available: HTTP 404 Not Found response</listitem> + </itemizedlist> </para> - <itemizedlist> - <listitem>Access denied: HTTP 403 Forbidden response</listitem> - <listitem>Error: HTTP 500 Internal Server Error response</listitem> - <listitem>Internal error: HTTP 500 Internal Server Error response</listitem> - <listitem>Resource not found: HTTP 404 Not Found response</listitem> - <listitem>Resource not available: HTTP 404 Not Found response</listitem> - </itemizedlist> </sect2> <sect2> <title>Portal policy</title> @@ -61,14 +63,15 @@ </sect2> <sect2> <title>Page policy</title> - <para>Window error policy controls how the page reacts to aggregation errors. Indeed the page is most of the time - an aggregation of several portlet windows and the action to take when an error occurs is different than the other - policies. Whenever an error occurs, the policy can either handle it or ignore it. If the error is ignored then - it will be treated by the portal policy. The different actions that are possible upon an error are:</para> - <itemizedlist> - <listitem>Remove the window from the aggregation</listitem> - <listitem>Replace the markup of the window by a redirection to a JSP page</listitem> - </itemizedlist> + <para>Window error policy controls how the page reacts to aggregation errors. Indeed the page is most of the + time an aggregation of several portlet windows and the action to take when an error occurs is different than + the other policies. Whenever an error occurs, the policy can either handle it or ignore it. If the error is + ignored then it will be treated by the portal policy. The different actions that are possible upon an error are: + <itemizedlist> + <listitem>Remove the window from the aggregation</listitem> + <listitem>Replace the markup of the window by a redirection to a JSP page</listitem> + </itemizedlist> + </para> </sect2> </sect1> <sect1> @@ -310,11 +313,10 @@ clicking on the Properties link on each of these pages. You can also specify how dashboards should behave with respect to error handling by clicking on the Dashboards tab of the Portal management application. </para> - <para>Screenshot:</para> - <para> - <imageobject> - <imagedata fileref="images/errorhandling/errorHandlingUI.png" format="png"/> - </imageobject> - </para> + <para>Screenshot: + <imageobject> + <imagedata fileref="images/errorhandling/errorHandlingUI.png" format="png" align="center"/> + </imageobject> + </para> </sect1> </chapter> \ No newline at end of file Modified: docs/trunk/referenceGuide/en/modules/wsrp.xml =================================================================== --- docs/trunk/referenceGuide/en/modules/wsrp.xml 2007-10-13 00:08:20 UTC (rev 8625) +++ docs/trunk/referenceGuide/en/modules/wsrp.xml 2007-10-13 01:34:14 UTC (rev 8626) @@ -337,35 +337,35 @@ Let's now look at the Admin page and the Management portlet. Click on the "Portlet definitions" tab at the top. Once this is done, look at the list of available portlet providers. If all went well, you should see something similar to this: - <mediaobject> - <imageobject> - <imagedata fileref="images/wsrp/portlets.png" format="png" align="center" valign="middle"/> - </imageobject> - </mediaobject> - </para> - <para> - We have 3 available portlet providers: <emphasis>local, self</emphasis> and <emphasis>bea</emphasis>. The - "local" portlet provider exposes all the portlets deployed in this particular instance of Portal. As - explained above, the "self" provider refers to the default WSRP consumer bundled with Portal that consumes - the portlets exposed by the default WSRP producer. The "bea" provider corresponds to BEA's public producer - we just configured. Select it and click on "Change". You should now see something similar to: - <mediaobject> - <imageobject> - <imagedata fileref="images/wsrp/bea.png" format="png" align="center" valign="middle"/> - </imageobject> - </mediaobject> - </para> - <para> - From there on out, you should be able to configure WSRP portlets just as any other. In particular, you - can create an instance of one of the remote portlets offered by BEA's public producer just like you would - create an instance of a local portlet and then assign it to a window in a page. If you go to that page, you - should see something similar to below for this portlet: - <mediaobject> - <imageobject> - <imagedata fileref="images/wsrp/result.png" format="png" align="center" valign="middle"/> - </imageobject> - </mediaobject> - </para> + <mediaobject> + <imageobject> + <imagedata fileref="images/wsrp/portlets.png" format="png" align="center" valign="middle"/> + </imageobject> + </mediaobject> + </para> + <para> + We have 3 available portlet providers: <emphasis>local, self</emphasis> and <emphasis>bea</emphasis>. The + "local" portlet provider exposes all the portlets deployed in this particular instance of Portal. As + explained above, the "self" provider refers to the default WSRP consumer bundled with Portal that consumes + the portlets exposed by the default WSRP producer. The "bea" provider corresponds to BEA's public producer + we just configured. Select it and click on "Change". You should now see something similar to: + <mediaobject> + <imageobject> + <imagedata fileref="images/wsrp/bea.png" format="png" align="center" valign="middle"/> + </imageobject> + </mediaobject> + </para> + <para> + From there on out, you should be able to configure WSRP portlets just as any other. In particular, you + can create an instance of one of the remote portlets offered by BEA's public producer just like you would + create an instance of a local portlet and then assign it to a window in a page. If you go to that page, you + should see something similar to below for this portlet: + <mediaobject> + <imageobject> + <imagedata fileref="images/wsrp/result.png" format="png" align="center" valign="middle"/> + </imageobject> + </mediaobject> + </para> </sect3> </sect2>