[gatein-commits] gatein SVN: r9088 - in epp/docs/branches/6.0/Reference_Guide/en-US: modules and 5 other directories.

do-not-reply at jboss.org do-not-reply at jboss.org
Mon Jan 28 00:14:13 EST 2013


Author: jaredmorgs
Date: 2013-01-28 00:14:12 -0500 (Mon, 28 Jan 2013)
New Revision: 9088

Modified:
   epp/docs/branches/6.0/Reference_Guide/en-US/Reference_Guide.xml
   epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Config_Retrieval.xml
   epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml
   epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SSO.xml
   epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge.xml
   epp/docs/branches/6.0/Reference_Guide/en-US/modules/WSRP.xml
   epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr-with-gtn/managed-datasources-under-jboss-as.xml
   epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/cluster-config.xml
Log:
Changes to date for WSRP section pushing back in.

Modified: epp/docs/branches/6.0/Reference_Guide/en-US/Reference_Guide.xml
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/Reference_Guide.xml	2013-01-26 18:34:09 UTC (rev 9087)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/Reference_Guide.xml	2013-01-28 05:14:12 UTC (rev 9088)
@@ -30,8 +30,8 @@
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="modules/Advanced.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="modules/eXoJCR.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="Revision_History.xml"/>
-<part>
-<title>Server Integration</title>
-<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="modules/ServerIntegration.xml"/>
-</part>
+  <part>
+    <title>Server Integration</title>
+    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="modules/ServerIntegration.xml"/>
+  </part>
 </book>

Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Config_Retrieval.xml
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Config_Retrieval.xml	2013-01-26 18:34:09 UTC (rev 9087)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Config_Retrieval.xml	2013-01-28 05:14:12 UTC (rev 9088)
@@ -11,33 +11,22 @@
   <para>
   The container is initialized by looking into different locations. This container is used by portal applications. Configurations are overloaded in the following lookup sequence:
  </para>
-  <remark>NEEDINFO - FILE PATHS - the file before was configuration.xml, but I&apos;m pretty sure all this is defined in standalone.xml now, correct?</remark>
   <procedure>
     <step>
       <para>
-    Services default <envar>RootContainer</envar> configurations from JAR files <filename><replaceable>JPP_HOME/</replaceable>/standalone/configuration/standalone.xml</filename>.
+    Services default <envar>RootContainer</envar> configurations from JAR files <filename>/conf/configuration.xml</filename>.
    </para>
     </step>
     <step>
       <para>
-    External <envar>RootContainer</envar> configuration can be found at <filename><replaceable>JPP_HOME/</replaceable>/standalone/configuration/standalone.xml</filename>.
+    Services default <envar>PortalContainer</envar> configurations from JAR files <filename>/conf/portal/configuration.xml</filename>.
    </para>
     </step>
     <step>
       <para>
-    Services default <envar>PortalContainer</envar> configurations from JAR files <filename><replaceable>JPP_HOME/</replaceable>/standalone/configuration/standalone.xml</filename>.
-   </para>
-    </step>
-    <step>
-      <para>
     Web applications configurations from WAR files <filename>/WEB-INF/conf/configuration.xml</filename>
    </para>
     </step>
-    <step>
-      <para>
-    External configuration for services of named portal can be found at <filename><replaceable>JPP_HOME</replaceable>/standalone/configuration/standalone.xml</filename>.
-   </para>
-    </step>
   </procedure>
   <note>
     <para>

Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml	2013-01-26 18:34:09 UTC (rev 9087)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml	2013-01-28 05:14:12 UTC (rev 9088)
@@ -52,29 +52,23 @@
     <para>
             Authentication workflow consists of HTTP requests and redirects which include handshakes. Currently only Servlet 3.0 containers are supported, so authentication is triggered programmatically from Servlet API.
          </para>
-    <remark>NEEDINFO - FILE PATHS - in this file, the /dologin blocks seem to be in &lt;servlet-mapping&gt; directives. Is it OK for me to update to this format in this respect?</remark>
-    <para>
-            First you can see in <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/web.xml</filename> that authentication is triggered by accessing a secured URL  <systemitem>_/dologin_</systemitem>:
+    <para>In <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/web.xml</filename>, authentication is triggered by accessing a secured URL  <systemitem>_/dologin_</systemitem>:
          </para>
-    <programlisting language="XML" role="XML">
-<![CDATA[
-   <security-constraint>
-     <web-resource-collection>
-       <web-resource-name>user authentication</web-resource-name>
-         <url-pattern>/dologin</url-pattern>
-         <http-method>POST</http-method>
-         <http-method>GET</http-method>
-       </web-resource-collection>
-       <auth-constraint>
-         <role-name>users</role-name>
-       </auth-constraint>
-       <user-data-constraint>
-         <transport-guarantee>NONE</transport-guarantee>
-       </user-data-constraint>
-     </web-resource-collection>
-   </security-constraint>
-]]>
-        </programlisting>
+    <programlisting language="XML">&lt;security-constraint&gt;
+  &lt;web-resource-collection&gt;
+    &lt;web-resource-name&gt;user authentication&lt;/web-resource-name&gt;
+      &lt;url-pattern&gt;/dologin&lt;/url-pattern&gt;
+        &lt;http-method&gt;POST&lt;/http-method&gt;
+        &lt;http-method&gt;GET&lt;/http-method&gt;
+    &lt;/web-resource-collection&gt;
+    &lt;auth-constraint&gt;
+      &lt;role-name&gt;users&lt;/role-name&gt;
+    &lt;/auth-constraint&gt;
+    &lt;user-data-constraint&gt;
+      &lt;transport-guarantee&gt;NONE&lt;/transport-guarantee&gt;
+    &lt;/user-data-constraint&gt;
+  &lt;/web-resource-collection&gt;
+&lt;/security-constraint&gt;   </programlisting>
     <para>
             This means that access to URLs (such as <ulink url="http://localhost:8080/portal/dologin" type="http">http://localhost:8080/portal/dologin</ulink>) will directly trigger J2EE authentication in the case that the user is not already logged in.
          </para>
@@ -84,18 +78,14 @@
     <para>
             In the next part of the file we can see that authentication is FORM based and it starts by redirection to <emphasis>/login</emphasis> URL, which is mapped to <literal>LoginServlet</literal>.
          </para>
-    <programlisting language="XML" role="XML">
-<![CDATA[
-    <login-config>
-        <auth-method>FORM</auth-method>
-        <realm-name>gatein-domain</realm-name>
-        <form-login-config>
-            <form-login-page>/login</form-login-page>
-            <form-error-page>/login</form-error-page>
-        </form-login-config>
-    </login-config>
-]]>
-        </programlisting>
+    <programlisting language="XML">&lt;login-config&gt;
+  &lt;auth-method&gt;FORM&lt;/auth-method&gt;
+  &lt;realm-name&gt;gatein-domain&lt;/realm-name&gt;
+  &lt;form-login-config&gt;
+    &lt;form-login-page&gt;/login&lt;/form-login-page&gt;
+    &lt;form-error-page&gt;/login&lt;/form-error-page&gt;
+  &lt;/form-login-config&gt;
+&lt;/login-config&gt;  </programlisting>
     <para>
             <literal>LoginServlet</literal> redirects the user to the login page placed in <filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/login/jsp/login.jsp</filename>. 
             <mediaobject>

Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SSO.xml
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SSO.xml	2013-01-26 18:34:09 UTC (rev 9087)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SSO.xml	2013-01-28 05:14:12 UTC (rev 9088)
@@ -60,7 +60,7 @@
             </para>      -->    </warning>
   </section>
   <section id="sect-SSO_Single_Sign_On_-Central_Authentication_Service">
-    <title><remark>BZ#856430</remark>Central Authentication Service (CAS)</title>
+    <title><remark>BZ#856430 </remark>Central Authentication Service (CAS)</title>
     <para>
             The CAS single sign-on (SSO) plug-in enables seamless integration between the platform and the CAS SSO framework. General information about CAS can be found on the <ulink url="http://www.jasig.org/cas">Jasig website</ulink>.
          </para>
@@ -922,7 +922,7 @@
         <procedure>
           <step>
             <para>
-                        Assuming again that you have JBoss Portal Platform running on JBoss Enterprise Platform 6, you need to change some of the properties in the SSO sections of <filename>JBOSS_HOME/standalone/configuration/gatein/configuration.properties</filename> to match those below:
+                        Assuming again that you have JBoss Portal Platform running on JBoss Enterprise Application Platform 6, you need to change some of the properties in the SSO sections of <filename>JBOSS_HOME/standalone/configuration/gatein/configuration.properties</filename> to match those below:
                      </para>
             <informalexample>
               <programlisting>

Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge.xml
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge.xml	2013-01-26 18:34:09 UTC (rev 9087)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge.xml	2013-01-28 05:14:12 UTC (rev 9088)
@@ -26,50 +26,49 @@
         The other part of this implementation is provided by implementing a variety of (standard) <literal>Faces</literal> extensions.
     </para>
   </section>
-  <section id="Portlet_Bridge_File_Locations">
-    <title>File Locations</title>
-    <remark>BZ#856417 - NEEDINFO - will we be packaging the portletbridge binaries in this folder for JBoss Portal Platform 6? </remark>
-    <para>The binaries required for  Portlet Bridge applications, and example applications that can be used to learn and understand JSF applications are located in in <filename>JPP_DIST/portletbridge</filename>.  </para>
-    <para>Configuration files for Portlet Bridge are located in the following locations: </para>
-    <itemizedlist>
-      <listitem>
-        <para><filename><replaceable>JPP_DIST</replaceable>/standalone/<replaceable>portlet_name</replaceable>.war/WEB-INF/portlet.xml</filename></para>
-      </listitem>
-      <listitem>
-        <para><filename><replaceable>JPP_DIST</replaceable>/standalone/<replaceable>portlet_name</replaceable>.war/WEB-INF/faces-config.xml</filename></para>
-      </listitem>
-      <listitem>
-        <para><filename><replaceable>JPP_DIST</replaceable>/standalone/<replaceable>portlet_name</replaceable>.war/WEB-INF/web.xml</filename></para>
-      </listitem>
-    </itemizedlist>
-    <para><variablelist>
-        <varlistentry>
-          <term>
-            <filename>portlet.xml</filename>
-          </term>
-          <listitem>
-            <para>Contains the primary configuration information for the portlet. Information such as the GenericFacesPortlet location, and which Java Server Faces (JSF) pages to render are stored in this file.</para>
-          </listitem>
-        </varlistentry>
-        <varlistentry>
-          <term>
-            <filename>faces-config.xml</filename>
-          </term>
-          <listitem>
-            <para>Contains configuration directives that are specific to JSF applications. The specific directives will be covered as needed throughout this guide.</para>
-          </listitem>
-        </varlistentry>
-        <varlistentry>
-          <term>
-            <filename>web.xml</filename>
-          </term>
-          <listitem>
-            <para>Contains configuration directives that apply to the web application in general.</para>
-          </listitem>
-        </varlistentry>
-      </variablelist></para>
-  </section>
-  <section id="What_is_a_portlet_application">
+<!--BZ#856417 - File Locations Section intentionally commented out because Portlet Bridge is packaged with JPP, therefore libraries are deployed as modules in JPP.--><!--<section id="Portlet_Bridge_File_Locations">
+  <title>File Locations</title>
+  <remark>BZ#856417 - NEEDINFO - will we be packaging the portletbridge binaries in this folder for JBoss Portal Platform 6? </remark>
+  <para>The binaries required for  Portlet Bridge applications, and example applications that can be used to learn and understand JSF applications are located in in <filename>JPP_DIST/portletbridge</filename>.  </para>
+  <para>Configuration files for Portlet Bridge are located in the following locations: </para>
+  <itemizedlist>
+    <listitem>
+      <para><filename><replaceable>JPP_DIST</replaceable>/standalone/<replaceable>portlet_name</replaceable>.war/WEB-INF/portlet.xml</filename></para>
+    </listitem>
+    <listitem>
+      <para><filename><replaceable>JPP_DIST</replaceable>/standalone/<replaceable>portlet_name</replaceable>.war/WEB-INF/faces-config.xml</filename></para>
+    </listitem>
+    <listitem>
+      <para><filename><replaceable>JPP_DIST</replaceable>/standalone/<replaceable>portlet_name</replaceable>.war/WEB-INF/web.xml</filename></para>
+    </listitem>
+  </itemizedlist>
+  <para><variablelist>
+      <varlistentry>
+        <term>
+          <filename>portlet.xml</filename>
+        </term>
+        <listitem>
+          <para>Contains the primary configuration information for the portlet. Information such as the GenericFacesPortlet location, and which Java Server Faces (JSF) pages to render are stored in this file.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term>
+          <filename>faces-config.xml</filename>
+        </term>
+        <listitem>
+          <para>Contains configuration directives that are specific to JSF applications. The specific directives will be covered as needed throughout this guide.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term>
+          <filename>web.xml</filename>
+        </term>
+        <listitem>
+          <para>Contains configuration directives that apply to the web application in general.</para>
+        </listitem>
+      </varlistentry>
+    </variablelist></para>
+</section>-->  <section id="What_is_a_portlet_application">
     <title id="Portlet_Bridge_Portlet_Application">Portlet application</title>
     <para>A portlet application is defined as a single web archive (WAR). </para>
     <para>All portlets that are part of the same WAR are considered to form part of the same portlet application.</para>
@@ -77,7 +76,6 @@
   <section>
     <title id="Portlet_Bridge_Extensions">Extensions</title>
     <para>Portlet extensions sit atop the portlet bridge framework. They extend the functionality of other JBoss portlet applications, and are critical in JSF portlet development. </para>
-    <para>Extensions are made available in the impl development binary, located in <filename><replaceable>JPP_DIST</replaceable>/portletbridge</filename>. </para>
   </section>
   <section id="Portlet_Bridge_Examples">
     <title><remark>BZ#856417</remark>Examples</title>

Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/WSRP.xml
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/modules/WSRP.xml	2013-01-26 18:34:09 UTC (rev 9087)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/WSRP.xml	2013-01-28 05:14:12 UTC (rev 9088)
@@ -5,8 +5,9 @@
    ]>
 <chapter id="wsrp">
   <title>Web Services for Remote Portlets (WSRP)</title>
-  <section>
+  <section id="wsrp-Introduction">
     <title>Introduction</title>
+    <remark>https://docs.jboss.org/author/display/GTNPORTAL35/Web+Services+for+Remote+Portlets+%28WSRP%29</remark>
     <para>The Web Services for Remote Portlets specification defines a web service interface for accessing and
          interacting with interactive presentation-oriented web services. It has been produced through the efforts of
          the Web Services for Remote Portlets (WSRP) OASIS Technical Committee. It is based on the requirements
@@ -35,6 +36,7 @@
   </section>
   <section id="wsrp_support">
     <title>Level of support in JBoss Portal Platform</title>
+    <remark>Source: https://docs.jboss.org/author/display/GTNPORTAL35/Level+of+support</remark>
     <para>The WSRP Technical Committee defined
          <ulink url="http://www.oasis-open.org/committees/download.php/3073">WSRP Use Profiles</ulink>
          to help with WSRP interoperability. This section will refer to terms defined in that document.
@@ -44,7 +46,7 @@
          defined at the Complex level) are supported.
       </para>
     <para>On the Consumer side, JBoss Portal Platform provides a Medium level of support for WSRP, except that the consumer only handles
-         HTML markup (as JBoss Portal Platform itself does not handle other markup types). It does support explicit portlet
+         HTML markup (because JBoss Portal Platform itself does not handle other markup types). The platform does support explicit portlet
          cloning and it fully supports the PortletManagement interface.
       </para>
     <para>As far as caching goes, the component has Level 1 Producer and Consumer. Cookie handling is supported properly on the
@@ -65,25 +67,24 @@
     <note>
       <title>Note</title>
       <para>As of version &VZ; of JBoss Portal Platform, WSRP is only activated and supported
-            when JBoss Portal Platform is deployed on JBoss Application Server.
+using JBoss Portal Platform deployed on JBoss Enterprise Application Platform 6.
          </para>
     </note>
   </section>
-  <section>
+  <section id="Deploying_JPP_WSRP_Services">
     <title><remark>BZ#839355</remark>Deploying JBoss Portal Platform&apos;s WSRP services</title>
+    <remark>Source: https://docs.jboss.org/author/display/GTNPORTAL35/Deploying+GateIn%27s+WSRP+services</remark>
     <para>
 JBoss Portal Platform provides complete support for WSRP 1.0 and 2.0 standard interfaces, and offers both consumer and
          producer services. Starting with version 2.1.0-GA of the component, WSRP is packaged as a JBoss Portal Platform
          extension, and is  self-contained in a package named
-         <filename><replaceable>JPP_DIST</replaceable>/gatein/extensions/gatein-wsrp-integration.ear</filename>
+         <filename><replaceable>JPP_HOME</replaceable>/gatein/extensions/gatein-wsrp-integration.ear</filename>
 .
 </para>
-    <remark>NEEDINFO - FILE PATHS - there don&apos;t seem to be any config files that I can see in the directory below.</remark>
     <para>The only files of interest from a user perspective
 are located in the 
-                  <filename><replaceable>JPP_DIST</replaceable>/standalone/configuration/gatein/wsrp</filename>
+                  <filename><replaceable>JPP_HOME</replaceable>/standalone/configuration/gatein/wsrp</filename>
 directory.</para>
-    <remark>NEEDINFO - FILE PATHS - the wsse files are not present in the directory structure. Where do these live now?</remark>
     <itemizedlist>
       <listitem>
         <para><filename>gatein-wsse-consumer.xml</filename>,                   which allows you to configure WS-Security support for the consumer.</para>
@@ -156,7 +157,7 @@
     <section id="wsrp-ports">
       <title>Considerations to use WSRP when running JBoss Portal Platform on a non-default port or hostname</title>
       <para>
-         The web service stack that JBoss Portal Platform uses is based on JBoss WS. It updates the port and host name used in WSDL (for further details refer to the <citetitle>Web Services</citetitle> chapter in the <citetitle>JBoss Enterprise Application Platform Administration and Configuration User Guide</citetitle>).
+         The web service stack that JBoss Portal Platform uses is based on JBoss WS. It updates the port and host name used in WSDL (for further details refer to the <citetitle>Web Services</citetitle> chapter in the <citetitle>JBoss Enterprise Application Platform 6 Administration and Configuration User Guide</citetitle>).
          </para>
       <para>
             Of course, if you have modified the host name and port on which your server runs, you will
@@ -164,8 +165,9 @@
             update the configuration for the consumer used to consume JBoss Portal Platform&apos;s &apos;self&apos; producer.          </para>
     </section>
   </section>
-  <section>
-    <title><remark>BZ#856432</remark>Securing WSRP</title>
+  <section id="Securing_WSRP">
+    <title><remark>BZ#856432 </remark>Securing WSRP</title>
+    <remark>Source: https://docs.jboss.org/author/display/GTNPORTAL35/Securing+WSRP#SecuringWSRP-SecuringWSRP</remark>
     <para>There are two main ways to secure the communication between a producer and consumer:</para>
     <orderedlist>
       <listitem>
@@ -184,15 +186,15 @@
       </listitem>
     </orderedlist>
     <para>Depending on requirements, an HTTPs endpoint or/and ws-security can be used.</para>
-    <section>
+    <section id="WSRP_over_SSL_HTTPS_Endpoints">
       <title>WSRP over SSL with HTTPS endpoints</title>
+      <remark>Source: https://docs.jboss.org/author/display/GTNPORTAL35/Securing+WSRP#SecuringWSRP-WSRPoverSSLwithHTTPSendpoints</remark>
       <para>
-      It is possible to use WSRP over SSL for a secure exchange of data. Since GateIn Portal does not come initially configured for HTTPS connectors, we will need to configure the producer&apos;s server for this first. This is a global configuration change to JBoss AS and will affect more than just GateIn Portal and WSRP. Please see the
-      <ulink url="http://www.jboss.org/jbossas/docs">JBoss AS documentation</ulink>
-      for how to configure HTTPS connectors for the server.
+      It is possible to use WSRP over SSL for a secure exchange of data. Since JBoss Portal Platform does not come initially configured for HTTPS connectors, we will need to configure the producer&apos;s server for this first. This is a global configuration change, and  will affect more than just the portal and WSRP. Refer to the
+JBoss Enterprise Application Platform 6 <citetitle>Administration and Configuration Guide</citetitle>       for instructions about how to configure HTTPS connectors for the server.
     </para>
       <para>
-      Once the producer is configured for HTTPS connections, on the consumer you will just need to modify the URL for the WSRP endpoint to point to the new https based url. This will require either manually updating the value in the WSRP admin application, or by specifying it using the
+      Once the producer is configured for HTTPS connections, on the consumer you will just need to modify the URL for the WSRP endpoint to point to the new https based URL. This will require either manually updating the value in the WSRP administration application, or by specifying it using the
       <emphasis role="italics">wsrp-consumers-config.xml</emphasis>
       configuration file before the server is first started.
     </para>
@@ -200,31 +202,24 @@
         <title>Sample Configuration For Enabling SSL With WSRP</title>
         <warning>
           <para>
-          This is just a simple, test configuration to be used as an example as to how its possible to setup the https/ssl with wsrp. It is not meant to show best practices for configuring https with JBoss AS and does things which should not be used in a production server (such as self-signed certificates). Please see the
-          <ulink url="http://www.jboss.org/jbossas/docs">JBoss AS documentation</ulink>
-          for full configuration options.
+          The following procedures are provided as an example of configuring HTTPS/SSL with WSRP. </para>
+          <para>It is not meant to show best practices for configuring HTTPS with the platform, and does things which should not be used in a production server (such as self-signed certificates). Refer to the JBoss Enterprise Application Platform 6 product documentation for detailed, best practice configuration guidelines.
         </para>
         </warning>
-        <section id="sid-54264620_SecuringWSRP-ConfiguretheProducertoUseHTTPS">
+        <procedure>
           <title>Configure the Producer to Use HTTPS</title>
-          <para>First we will need to configure the producer&apos;s server to use https. This is handled in the same manner that you would configure any JBoss AS server for HTTPS.</para>
-          <orderedlist>
-            <listitem>
-              <para>Generate the keystore for the producer</para>
-              <informalexample>
-                <programlisting>keytool -genkey -alias tomcat -keyalg RSA -keystore producerhttps.keystore -dname &quot;cn=localhost&quot; -keypass changeme -storepass changeme</programlisting>
-              </informalexample>
-            </listitem>
-            <listitem>
-              <para>
+          <para>Configure the producer&apos;s server to use HTTPS. This is handled in the same manner that you would configure any JBoss AS server for HTTPS.</para>
+          <step>
+            <para>Generate the keystore for the producer by executing the following command.</para>
+            <programlisting>keytool -genkey -alias tomcat -keyalg RSA -keystore producerhttps.keystore -dname &quot;cn=localhost&quot; -keypass changeme -storepass changeme</programlisting>
+          </step>
+          <step>
+            <para>
               Configure the server to add an https connection. This requires modifying the
               <emphasis role="italics">standalone/configuration/standalone.xml</emphasis>
               file with the following content in bold:
             </para>
-              <sidebar>
-                <para>
-                ...
-                
+            <programlisting>                
                 &lt;subsystem xmlns=&quot;urn:jboss:domain:web:1.1&quot; default-virtual-server=&quot;default-host&quot; native=&quot;false&quot;&gt;
                 
                 &lt;connector name=&quot;http&quot; protocol=&quot;HTTP/1.1&quot; scheme=&quot;http&quot; socket-binding=&quot;http&quot;/&gt;
@@ -243,104 +238,89 @@
                 
                 &lt;/virtual-server&gt;
                 
-                ...
-              </para>
-              </sidebar>
-            </listitem>
-            <listitem>
-              <para>
+                ...</programlisting>
+          </step>
+          <step>
+            <para>
               Start the server and verify that
               <ulink url="https://localhost:8443/portal"/>
               is accessible. Note that since you are using a self-signed certificate that your browser will give a warning that the certificate cannot be trusted.
             </para>
-              <note>
-                <para>In this example case we are accessing the portal using &apos;localhost&apos; hence why we are using &quot;cn=localhost&quot; in the keytool command. If you are using this across another domain, you will need to make the necessary change.</para>
-              </note>
-            </listitem>
-          </orderedlist>
-        </section>
-        <section id="sid-54264620_SecuringWSRP-ConfiguretheConsumertoAccesstheWSRPEndpointoverHTTPS">
+            <note>
+              <para>In this example case we are accessing the portal using &apos;localhost&apos; hence why we are using &quot;cn=localhost&quot; in the keytool command. If you are using this across another domain, you will need to make the necessary changes.</para>
+            </note>
+          </step>
+        </procedure>
+        <procedure>
           <title>Configure the Consumer to Access the WSRP Endpoint over HTTPS</title>
-          <para>Ideally we should be able to just change the URL for the producer in the wsrp admin to use https, but we need to tell the consumer&apos;s server to trust our self-signed certificate first.</para>
-          <orderedlist>
-            <listitem>
-              <para>Export the producer&apos;s public key from the producer&apos;s keystore</para>
-              <informalexample>
-                <programlisting>keytool -export -alias tomcat -file producerkey.rsa -keystore producerhttps.keystore -storepass changeme</programlisting>
-              </informalexample>
-            </listitem>
-            <listitem>
-              <para>Import the producer&apos;s public key into a new keystore for the consumer</para>
-              <informalexample>
-                <programlisting>keytool -import -alias tomcat -file producerkey.rsa -keystore consumerhttps.keystore -storepass changeme -noprompt</programlisting>
-              </informalexample>
-            </listitem>
-            <listitem>
-              <para>
+          <step>
+            <para>Export the producer&apos;s public key from the producer&apos;s keystore</para>
+            <programlisting>keytool -export -alias tomcat -file producerkey.rsa -keystore producerhttps.keystore -storepass changeme</programlisting>
+          </step>
+          <step>
+            <para>Import the producer&apos;s public key into a new keystore for the consumer</para>
+            <programlisting>keytool -import -alias tomcat -file producerkey.rsa -keystore consumerhttps.keystore -storepass changeme -noprompt</programlisting>
+          </step>
+          <step>
+            <para>
               Configure the
               <emphasis role="italics">bin/standalone.conf</emphasis>
               file to add the following line at the end of the file:
             </para>
-              <informalexample>
-                <programlisting>JAVA_OPTS=&quot;$JAVA_OPTS -Djavax.net.ssl.trustStore=/path/to/consumerhttps.keystore -Djavax.net.ssl.trustStorePassword=changeme&quot;</programlisting>
-              </informalexample>
-            </listitem>
-            <listitem>
-              <para>
+            <programlisting>JAVA_OPTS=&quot;$JAVA_OPTS -Djavax.net.ssl.trustStore=/path/to/consumerhttps.keystore -Djavax.net.ssl.trustStorePassword=changeme&quot;</programlisting>
+          </step>
+          <step>
+            <para>
               Start the consumer and change the selfv2 producer url to
               <ulink url="https://localhost:8443/wsrp-producer/v2/MarkupService?wsdl"/>
               and verify that the consumer can access the producer.
             </para>
-            </listitem>
-          </orderedlist>
-          <note>
-            <para>
-            It is also possible to modify the
+          </step>
+        </procedure>
+        <note>
+          <para>
+            It is possible to modify the
             <emphasis role="italics">wsrp-consumers-config.xml</emphasis>
-            configuration file to change the URL instead of modifying it in the admin gui
+            configuration file to change the URL instead of modifying it in the administration GUI.
           </para>
-          </note>
-          <para>
-      It is possible to use WSRP over SSL for secure exchange of data. Configure your server appriopriately as described in the <citetitle>HTTPS Configuration</citetitle> section of the <citetitle>Installation Guide</citetitle>.
+        </note>
+        <para>
+      It is possible to use WSRP over SSL for secure exchange of data. Configure your server appropriately as described in the <citetitle>HTTPS Configuration</citetitle> section of the <citetitle>Installation Guide</citetitle>.
          </para>
-        </section>
       </section>
     </section>
-    <section>
+    <section id="WSRP_and_WS-Security">
       <title>WSRP and WS-Security</title>
       <para>Portlets may present different data or options depending on the currently authenticated user. For remote
               portlets, this means having to propagate the user credentials from the consumer back to the producer in
               a safe and secure manner. The WSRP specification does not directly specify how this should be
               accomplished, but delegates this work to the existing WS-Security standards. The WS-Security standards can also be used to secure the soap message, such as encryption and signing the message.
         </para>
-      <note>
-        <title>Web Container Compatibility</title>
-        <para>WSRP and WS-Security is currently only supported on JBoss Portal Platform when running on top of JBoss
-                AS 5.
-          </para>
-      </note>
       <warning>
-        <title>Encryption</title>
-        <para>You will want to encrypt the credentials being sent between the consumer and producer, otherwise they
-                will be sent in plain text and could be easily intercepted. You can either configure WS-Security to
-                encrypt and sign the SOAP messages being sent, or secure the transport layer by using an https endpoint.
+        <title>Encryption is strongly recommended</title>
+        <para>Encrypt the credentials being sent between the consumer and producer, otherwise they
+                will be sent in plain text and could be easily intercepted. Configure WS-Security to
+                encrypt and sign the SOAP messages being sent, or secure the transport layer by using an HTTPS endpoint.
                 Failure to encrypt the soap message or transport layer will result in the username and password being
-                sent in plain text. <emphasis role="bold">Use of encryption is strongly recommended.</emphasis>
+                sent in plain text. 
           </para>
       </warning>
+      <note>
+        <title>Web Container Compatibility</title>
+        <para>WSRP and WS-Security is  only supported on JBoss Portal Platform when running on JBoss Enterprise Application Platform 6.
+          </para>
+      </note>
     </section>
-    <section>
+    <section id="wsrp-Credentials">
       <title>Credentials</title>
       <para>When the consumer sends the user credentials to the producer, it is sending the credentials for the
                 currently authenticated user in the consumer. This makes signing in to remote portlets transparent
                 to end users, but also requires that the producer and consumer use the same credentials. This means
                 that the username and password must be the same and valid on both servers.
          </para>
-      <para>The recommended approach for this situation would be to use a common LDAP configuration. Please
-               see the user guide on how to configure LDAP for use with JBoss Portal Platform
-         </para>
+      <para>The recommended approach for this situation would be to use a common LDAP configuration. Refer to <xref linkend="chap-LDAP_Integration"/> to correctly configure LDAP on JBoss Portal Platform.         </para>
       <section id="wss_configuration">
-        <title><remark>BZ#839355</remark>WS-Security Configuration</title>
+        <title><remark>BZ#839355 </remark>WS-Security Configuration</title>
         <section id="sid-54264620_SecuringWSRP-Introduction">
           <title>Introduction</title>
           <para>JBoss AS7 uses a different web service implementation than the previous versions: it is now uses the JBossWS CXF Stack instead of the JBossWS Native Stack. Due to these changes, the way we configure WS-Security for WSRP with GateIn Portal on JBossAS 7 has changed.</para>
@@ -351,21 +331,17 @@
         </section>
         <section id="sid-54264620_SecuringWSRP-Overview">
           <title>Overview</title>
-          <para>CXF uses interceptors to extend and configure its behaviour. There are two main types of interceptors: inInterceptors and outInterceptors. InInterceptors are invoked for communication coming into the client or server, while outInterceptors are invoked when the client or server sends a message.</para>
+          <para>CXF uses interceptors to extend and configure its behavior. There are two main types of interceptors: <firstterm>inInterceptors</firstterm> and <firstterm>outInterceptors</firstterm>. InInterceptors are invoked for communication coming into the client or server, while outInterceptors are invoked when the client or server sends a message.</para>
           <para>So for the WSRP case, the communication from the consumer to the producer is governed by the consumer&apos;s OutInterceptor and the producer&apos;s InIntereceptor. The communication from the producer to the consumer is governed by the producer&apos;s OutInterceptor and the consumer&apos;s InInterceptor. This may mean having to configure 4 Interceptors.</para>
-          <note>
-            <para>When dealing with WS-Security, there are some things to consider here:</para>
-            <orderedlist>
-              <listitem>
-                <para>When dealing with user propagation, only the consumer sends the user credentials to the producer. So Username Tokens only need to be configured for the consumer&apos;s OutInterceptor and the producer&apos;s InInterceptor.</para>
-              </listitem>
-            </orderedlist>
-            <orderedlist>
-              <listitem>
-                <para>When dealing with things like encryption, you will most likely want to encrypt the message from the consumer to the producer and also the message from the producer to the consumer. This means that encryption properties must be configured for all 4 interceptors.</para>
-              </listitem>
-            </orderedlist>
-          </note>
+          <para>When dealing with WS-Security, there are some things to consider here:</para>
+          <orderedlist>
+            <listitem>
+              <para>When dealing with user propagation, only the consumer sends the user credentials to the producer. So Username Tokens only need to be configured for the consumer&apos;s OutInterceptor and the producer&apos;s InInterceptor.</para>
+            </listitem>
+            <listitem>
+              <para>When dealing with things like encryption, you will most likely want to encrypt the message from the consumer to the producer and also the message from the producer to the consumer. This means that encryption properties must be configured for all 4 interceptors.</para>
+            </listitem>
+          </orderedlist>
           <para>
           Please see the CXF Documentation for more details on interceptors and their types:
           <ulink url="http://cxf.apache.org/docs/interceptors.html"/>
@@ -376,7 +352,7 @@
         </para>
         </section>
       </section>
-      <section>
+      <section id="WSS4J_Interceptors_and_WSRP">
         <title>WSS4J Interceptors and WSRP</title>
         <para>The WSS4J Interceptors are configured using  using simple property files.
 
@@ -1166,15 +1142,13 @@
          </para>
       <note>
         <title>Note</title>
-        <remark>NEEDINFO - FILE PATH - while this path is valid, there is no XSD here any more. Should I just remove the note? Where is the XSD contained now?</remark>
         <para>An XML Schema defining which elements are available to configure Consumers via XML can be found
                   in
-                  <filename><replaceable>JPP_DIST</replaceable>/gatein/extensions/gatein-wsrp-integration.ear/lib/jboss7integration.jar/ </filename>
+                  <filename><replaceable>JPP_DIST</replaceable>/modules/org/gatein/wsrp/main/wsrp-integration-api-&WSRP_VERSION;.jar/xsd/gatein_wsrp_consumer_1_0.xsd </filename>
                </para>
       </note>
       <important>
-        <para>
-                  It is important to note that once the XML configuration file for consumers has been read upon
+        <para>Once the XML configuration file for consumers has been read upon
                   the WSRP service first start, the associated information is put under control of JCR (Java Content
                   Repository). Subsequent launches of the WSRP service will use the JCR-stored information and ignore
                   the content of the XML configuration file.

Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/cluster-config.xml
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/cluster-config.xml	2013-01-26 18:34:09 UTC (rev 9087)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/cluster-config.xml	2013-01-28 05:14:12 UTC (rev 9088)
@@ -7,79 +7,6 @@
   <title>Configuring Cluster</title>
   <section id="sect-Reference_Guide-Cluster_Configuration-Launching_Cluster">
     <title>Launching Cluster</title>
-    <section id="sect-Reference_Guide-Launching_Cluster-Deploying_eXo_JCR_to_JBoss_Application_Server">
-      <title>Deploying eXo JCR to JBoss Application Server</title>
-      <para>
-                To deploy eXo JCR to the JBoss AS, do the following:
-            </para>
-      <remark>NEEDINFO - FILE PATHS - do we need to do this for JPP 6. JCR is embedded isn&apos;t it?</remark>
-      <procedure>
-        <title/>
-        <step>
-          <para>
-                        Download the latest version of eXo JCR <filename>.ear</filename> file distribution.
-                    </para>
-        </step>
-        <step>
-          <para>
-                        Copy the file into <filename><replaceable>JPP_HOME</replaceable>/standalone/deployments</filename> directory.
-                    </para>
-        </step>
-        <step>
-          <para>
-                        Drop <filename>exo-configuration.xml</filename> into your root <filename><replaceable>JPP_DIST</replaceable>/jboss-as/</filename> directory.
-                    </para>
-        </step>
-        <step>
-          <para>
-                        Configure JAAS by inserting the XML fragment shown below into <filename><replaceable>JPP_DIST</replaceable>/jboss-as/server/<replaceable>PROFILE</replaceable>/conf/login-config.xml</filename>
-                    </para>
-          <programlisting language="XML" role="XML">&lt;application-policy name=&quot;exo-domain&quot;&gt;
-   &lt;authentication&gt;
-      &lt;login-module code=&quot;org.exoplatform.services.security.j2ee.JbossLoginModule&quot; flag=&quot;required&quot;&gt;&lt;/login-module&gt;
-   &lt;/authentication&gt;
-&lt;/application-policy&gt;</programlisting>
-        </step>
-        <step>
-          <para>
-                        To ensure that <emphasis>JBossTS</emphasis> and <emphasis>JBossCache</emphasis> are used, your <filename>configuration.xml</filename> file must contain:
-                    </para>
-          <programlisting language="XML" role="XML">&lt;component&gt;
-   &lt;key&gt;org.jboss.cache.transaction.TransactionManagerLookup&lt;/key&gt;
-   &lt;type&gt;org.jboss.cache.GenericTransactionManagerLookup&lt;/type&gt;^
-&lt;/component&gt;
-
-&lt;component&gt;
-   &lt;key&gt;org.exoplatform.services.transaction.TransactionService&lt;/key&gt;
-   &lt;type&gt;org.exoplatform.services.transaction.jbosscache.JBossTransactionsService&lt;/type&gt;
-   &lt;init-params&gt;
-      &lt;value-param&gt;
-         &lt;name&gt;timeout&lt;/name&gt;
-         &lt;value&gt;300&lt;/value&gt;
-      &lt;/value-param&gt;
-   &lt;/init-params&gt;
-&lt;/component&gt;</programlisting>
-        </step>
-        <step>
-          <para>
-                        Start server:
-                    </para>
-          <para>
-                        In Linux systems:
-                    </para>
-          <programlisting><command>sh bin/run.sh</command></programlisting>
-          <para>
-                        In Windows systems:
-                    </para>
-          <programlisting><command>bin/run.bat</command></programlisting>
-        </step>
-        <step>
-          <para>
-                        Navigate to <ulink url="http://localhostu:8080/browser" type="http"/> ans use the credentials <emphasis role="bold">root</emphasis>/<emphasis role="bold">exo</emphasis> (login/password).
-                    </para>
-        </step>
-      </procedure>
-    </section>
     <section id="sect-Reference_Guide-Launching_Cluster-Configuring_JCR_to_use_external_configuration">
       <title>Configuring JCR to use external configuration</title>
       <itemizedlist>

Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr-with-gtn/managed-datasources-under-jboss-as.xml
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr-with-gtn/managed-datasources-under-jboss-as.xml	2013-01-26 18:34:09 UTC (rev 9087)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr-with-gtn/managed-datasources-under-jboss-as.xml	2013-01-28 05:14:12 UTC (rev 9088)
@@ -4,11 +4,11 @@
 %BOOK_ENTITIES;
 ]>
 <section id="sect-Reference_Guide-How_to_use_AS_Managed_DataSource_under_JBoss_AS">
-  <title>How to use AS Managed DataSource under JBoss AS</title>
+  <title>How to use a Managed DataSource under JBoss AS</title>
   <section id="sect-Reference_Guide-How_to_use_AS_Managed_DataSource_under_JBoss_AS-Configurations_Steps">
     <title>Configurations Steps</title>
     <section id="sect-Reference_Guide-Configurations_Steps-Declaring_the_datasources_in_the_AS">
-      <title>Declaring the datasources in the AS</title>
+      <title>Declaring the Datasources in the AS</title>
       <remark>NEEDINFO - FILE PATHS - I know this isn&apos;t right. Where do these get deployed again?</remark>
       <para>
     To declare the datasources using a JBoss application server, deploy a <literal>ds</literal> file (<filename><replaceable>XXX</replaceable>-ds.xml</filename>) into the <emphasis>deploy</emphasis> directory of the appropriate server profile (<filename>/server/<replaceable>PROFILE</replaceable>/deploy</filename>, for example).
@@ -61,7 +61,7 @@
       <title>Do not bind datasources explicitly</title>
       <para>
     Do not let the portal explicitly bind datasources. </para>
-      <remark>NEEDINFO - FILE PATHS - I think some of the values have changed here when I look at the new file below. New info required?</remark>
+      <remark>NEEDINFO - FILE PATHS - I think some of the values have changed in the referenced file when I look at the new file below. New info required?</remark>
       <para>Edit the <filename><replaceable>JPP_HOME</replaceable>/standalone/configuration/gatein/configuration.properties</filename> and comment out the following rows in the JCR section:
    </para>
       <programlisting>#gatein.jcr.datasource.driver=org.hsqldb.jdbcDriver



More information about the gatein-commits mailing list