From portal-commits at lists.jboss.org Fri Oct 12 21:34:15 2007 Content-Type: multipart/mixed; boundary="===============0114596667144676299==" MIME-Version: 1.0 From: portal-commits at lists.jboss.org To: portal-commits at lists.jboss.org Subject: [portal-commits] JBoss Portal SVN: r8626 - in docs: branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules and 2 other directories. Date: Fri, 12 Oct 2007 21:34:14 -0400 Message-ID: --===============0114596667144676299== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/errorhand= ling/errorHandlingUI.png docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/errorhan= dling.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/er= rorhandling/errorHandlingUI.png =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (Binary files differ) Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/e= rrorhandling.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/errorha= ndling.xml 2007-10-13 00:08:20 UTC (rev 8625) +++ docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/errorha= ndling.xml 2007-10-13 01:34:14 UTC (rev 8626) @@ -8,18 +8,19 @@ Error handling configuration - JBoss Portal request pipeline provides configuring of the error h= andling policy. At runtime when an error - occurs it is possible to configure how the portal behaves in a fine gra= ined and dynamic manner. + JBoss Portal's request pipeline allows for fine-grained, dynamic = configuration of how Portal will behave when + an error occurs at runtime. Error types - There are several kind of errors that can be happen during a r= equest. - - Access denied: the user does not have the security righ= ts to access a resource - Error: an expected error, like a portlet threw an excep= tion - Internal error: an unexpected error - Resource not found: a resource is not found - Resource not available: a resource is found but is not = serviceable - + There are several kind of errors that can happen during a requ= est: + + Access denied: the user does not have the security r= ights to access a resource + Error: an anticipated error as when a portlet throws= an exception + Internal error: an unexpected error + Resource not found: a resource is not found + Resource not available: a resource is found but is n= ot serviceable + + Control policies @@ -28,29 +29,30 @@ Policy delegation and cascading Whenever a control policy is invoked it is given the opport= unity 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 er= ror. For instance, if a portlet part of a page - produces an exception, the following reactions are possible: - - The error is displayed in the window - The window is removed from the aggregation - An portal error page is displayed - An HTTP 500 error response is sent to the browser - + by the control flow. If the control policy ignores the error t= hen 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 possib= le: + + The error is displayed in the window + The window is removed from the aggregation + An portal error page is displayed + An HTTP 500 error response is sent to the browser= + + Default policy The default policy applies when error are not handled at ot= her level. By default errors are translated into the most appropriate HTTP response: + + Access denied: HTTP 403 Forbidden response + Error: HTTP 500 Internal Server Error response + Internal error: HTTP 500 Internal Server Error re= sponse + Resource not found: HTTP 404 Not Found response + Resource not available: HTTP 404 Not Found respon= se + - - Access denied: HTTP 403 Forbidden response - Error: HTTP 500 Internal Server Error response - Internal error: HTTP 500 Internal Server Error respo= nse - Resource not found: HTTP 404 Not Found response - Resource not available: HTTP 404 Not Found response<= /listitem> - Portal policy @@ -61,14 +63,15 @@ Page policy - Window error policy controls how the page reacts to aggrega= tion 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 th= at are possible upon an error are: - - Remove the window from the aggregation - Replace the markup of the window by a redirection to= a JSP page - + Window error policy controls how the page reacts to aggrega= tion 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 e= ither handle it or ignore it. If the error is + ignored then it will be treated by the portal policy. The diff= erent actions that are possible upon an error are: + + Remove the window from the aggregation + Replace the markup of the window by a redirection= to a JSP page + + @@ -310,11 +313,10 @@ clicking on the Properties link on each of these pages. You can a= lso specify how dashboards should behave with respect to error handling by clicking on the Dashboards tab of th= e Portal management application. - Screenshot: - - - - + Screenshot: + + + \ No newline at end of file Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/w= srp.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/wsrp.xm= l 2007-10-13 00:08:20 UTC (rev 8625) +++ docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/wsrp.xm= l 2007-10-13 01:34:14 UTC (rev 8626) @@ -70,7 +70,7 @@ JBoss Portal provides a complete support of WSRP 1.0 standard int= erfaces and offers both consumer and producer services. WSRP support is provided by = the portal-wsrp.sar - service archive, included in the main jboss-portal.sar<= /emphasis> service archive, if you've = + service archive, included in the main jboss-portal.sar<= /emphasis> service archive, if you've obtained JBoss Portal from a binary distribution. If you don't in= tend on using WSRP, we recommend that you remove the portal-wspr.sar from the main jboss-portal.sar service archive. @@ -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 portl= et providers. If all went well, you should see something similar to this: - - - - - - - - We have 3 available portlet providers: local, self and bea. 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 WSR= P consumer bundled with Portal that consumes - the portlets exposed by the default WSRP producer. The "bea" p= rovider corresponds to BEA's public producer - we just configured. Select it and click on "Change". You shoul= d now see something similar to: - - - - - - - - From there on out, you should be able to configure WSRP portle= ts just as any other. In particular, you - can create an instance of one of the remote portlets offered by BEA's p= ublic 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: - - - - - - + + + + + + + + We have 3 available portlet providers: local, sel= f and bea. 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 sh= ould now see something similar to: + + + + + + + + From there on out, you should be able to configure WSRP por= tlets just as any other. In particular, you + can create an instance of one of the remote portlets offere= d 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: + + + + + + = @@ -487,7 +487,7 @@ = = + = @@ -526,7 +526,7 @@ - = + @@ -557,7 +557,7 @@ - = + @@ -702,7 +702,7 @@ - = + com.example.portal.SomeCustomRegistrationPolicy Modified: docs/trunk/referenceGuide/en/images/errorhandling/errorHandlingUI= .png =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (Binary files differ) Modified: docs/trunk/referenceGuide/en/modules/errorhandling.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- 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 @@ Error handling configuration - JBoss Portal request pipeline provides configuring of the error h= andling policy. At runtime when an error - occurs it is possible to configure how the portal behaves in a fine gra= ined and dynamic manner. + JBoss Portal's request pipeline allows for fine-grained, dynamic = configuration of how Portal will behave when + an error occurs at runtime. Error types - There are several kind of errors that can be happen during a r= equest. - - Access denied: the user does not have the security righ= ts to access a resource - Error: an expected error, like a portlet threw an excep= tion - Internal error: an unexpected error - Resource not found: a resource is not found - Resource not available: a resource is found but is not = serviceable - + There are several kind of errors that can happen during a requ= est: + + Access denied: the user does not have the security r= ights to access a resource + Error: an anticipated error as when a portlet throws= an exception + Internal error: an unexpected error + Resource not found: a resource is not found + Resource not available: a resource is found but is n= ot serviceable + + Control policies @@ -28,29 +29,30 @@ Policy delegation and cascading Whenever a control policy is invoked it is given the opport= unity 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 er= ror. For instance, if a portlet part of a page - produces an exception, the following reactions are possible: - - The error is displayed in the window - The window is removed from the aggregation - An portal error page is displayed - An HTTP 500 error response is sent to the browser - + by the control flow. If the control policy ignores the error t= hen 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 possib= le: + + The error is displayed in the window + The window is removed from the aggregation + An portal error page is displayed + An HTTP 500 error response is sent to the browser= + + Default policy The default policy applies when error are not handled at ot= her level. By default errors are translated into the most appropriate HTTP response: + + Access denied: HTTP 403 Forbidden response + Error: HTTP 500 Internal Server Error response + Internal error: HTTP 500 Internal Server Error re= sponse + Resource not found: HTTP 404 Not Found response + Resource not available: HTTP 404 Not Found respon= se + - - Access denied: HTTP 403 Forbidden response - Error: HTTP 500 Internal Server Error response - Internal error: HTTP 500 Internal Server Error respo= nse - Resource not found: HTTP 404 Not Found response - Resource not available: HTTP 404 Not Found response<= /listitem> - Portal policy @@ -61,14 +63,15 @@ Page policy - Window error policy controls how the page reacts to aggrega= tion 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 th= at are possible upon an error are: - - Remove the window from the aggregation - Replace the markup of the window by a redirection to= a JSP page - + Window error policy controls how the page reacts to aggrega= tion 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 e= ither handle it or ignore it. If the error is + ignored then it will be treated by the portal policy. The diff= erent actions that are possible upon an error are: + + Remove the window from the aggregation + Replace the markup of the window by a redirection= to a JSP page + + @@ -310,11 +313,10 @@ clicking on the Properties link on each of these pages. You can a= lso specify how dashboards should behave with respect to error handling by clicking on the Dashboards tab of th= e Portal management application. - Screenshot: - - - - - + Screenshot: + + + + = \ No newline at end of file Modified: docs/trunk/referenceGuide/en/modules/wsrp.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- 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 portl= et providers. If all went well, you should see something similar to this: - - - - - - - - We have 3 available portlet providers: local, self and bea. 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 WSR= P consumer bundled with Portal that consumes - the portlets exposed by the default WSRP producer. The "bea" p= rovider corresponds to BEA's public producer - we just configured. Select it and click on "Change". You shoul= d now see something similar to: - - - - - - - - From there on out, you should be able to configure WSRP portle= ts just as any other. In particular, you - can create an instance of one of the remote portlets offered by BEA's p= ublic 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: - - - - - - + + + + + + + + We have 3 available portlet providers: local, sel= f and bea. 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 sh= ould now see something similar to: + + + + + + + + From there on out, you should be able to configure WSRP por= tlets just as any other. In particular, you + can create an instance of one of the remote portlets offere= d 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: + + + + + + = --===============0114596667144676299==--