10:54 a.m.
Author: ekopalov
Date: 2012-10-12 11:54:27 -0400 (Fri, 12 Oct 2012)
New Revision: 8885
Modified:
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/DataImportStrategy.xml
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalNavigationConfiguration.xml
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/NavigationController.xml
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge/configuration.xml
epp/docs/branches/5.2/Reference_Guide/en-US/modules/WSRP.xml
Log:
partial fix of BZ 850885; until comment 3: community links
Modified:
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/DataImportStrategy.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/DataImportStrategy.xml 2012-10-12
15:25:08 UTC (rev 8884)
+++
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/DataImportStrategy.xml 2012-10-12
15:54:27 UTC (rev 8885)
@@ -8,7 +8,7 @@
<section id="sect-Reference_Guide-Data_Import_Strategy-Introduction">
<title>Introduction</title>
<para>
- In the Portal extension mechanism, developers can define an extension that
Portal data can be customized by configurations in the extension. There are several cases
which an extension developer wants to define how to customize the Portal data, for example
modifying, overwriting or just inserting a bit into the data defined by the portal.
Therefore, GateIn also defines several modes for each case and the only thing which a
developer has to do is to clarify the use-case and reasonably configure extensions.
+ In the Portal extension mechanism, developers can define an extension that
Portal data can be customized by. There are several cases when it is useful to be able to
define how to customize the Portal data; for example modifying, overwriting or just
inserting data into the data defined by the Portal. Therefore, GateIn also defines several
modes for each case so that the developer only need to clarify the use-case and configure
the extensions.
</para>
<para>
This section shows you how data are changes in each mode.
@@ -34,7 +34,7 @@
<section
id="sect-Reference_Guide-Data_Import_Strategy-Portal_Config">
<title>Portal Configuration</title>
<para>
- PortalConfig defines the portal name, permission, layout and some
properties of a site. These information are configured in the
<emphasis>portal.xml</emphasis>, <emphasis>group.xml</emphasis> or
<emphasis>user.xml</emphasis>, depending on the site type. The PortalConfig
importer performs a strategy that is based on the mode defined in NewPortalConfigListener,
including <literal>CONSERVE</literal>, <literal>INSERT</literal>,
<literal>MERGE</literal> or <literal>OVERWRITE</literal>.
Let's see how the import mode affects in the process of portal data performance:
+ PortalConfig defines the portal name, permission, layout and some
properties of a site. These information are configured in the
<emphasis>portal.xml</emphasis>, <emphasis>group.xml</emphasis> or
<emphasis>user.xml</emphasis>, depending on the site type. The PortalConfig
importer performs a strategy that is based on the mode defined in NewPortalConfigListener,
including <literal>CONSERVE</literal>, <literal>INSERT</literal>,
<literal>MERGE</literal> or <literal>OVERWRITE</literal>.
Let's see how the import mode affects the process of portal data performance:
</para>
<itemizedlist>
<listitem>
@@ -57,18 +57,18 @@
<section id="sect-Reference_Guide-Data_Import_Strategy-Page_Data">
<title>Page Data</title>
<para>
- The import mode affects the page data import as the same as
PortalConfig.
+ The import mode affects the page data import in the same way as
PortalConfig.
</para>
<note>
<para>
- If the Import mode is <literal>CONSERVE</literal> or
<literal>INSERT</literal>, the data import strategy always performs as the
<literal>MERGE</literal> mode in the first data initialization of the Portal.
- </para>
+ If the Import mode is <literal>CONSERVE</literal> or
<literal>INSERT</literal>, the data import strategy acts as if in the
<literal>MERGE</literal> mode in the first data initialization of the Portal.
+ </para>
</note>
</section>
<section
id="sect-Reference_Guide-Data_Import_Strategy-Navigation_Data">
<title>Navigation Data</title>
<para>
- The navigation data import strategy will be processed to the import mode
level as the followings:
+ The navigation data import strategy is processed at the import mode level
in the following way:
</para>
<itemizedlist>
<listitem>
@@ -78,12 +78,12 @@
</listitem>
<listitem>
<para>
- <literal>INSERT</literal>: Insert the missing
description data, but add only new nodes. Other modifications remains untouched.
+ <literal>INSERT</literal>: Insert the missing
description data, but add only new nodes. Other modifications remain untouched.
</para>
</listitem>
<listitem>
<para>
- <literal>MERGE</literal>: Merge the description data,
add missing nodes and update same name nodes.
+ <literal>MERGE</literal>: Merge the description data,
add missing nodes and update existing nodes.
</para>
</listitem>
<listitem>
Modified:
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalNavigationConfiguration.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalNavigationConfiguration.xml 2012-10-12
15:25:08 UTC (rev 8884)
+++
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalNavigationConfiguration.xml 2012-10-12
15:54:27 UTC (rev 8885)
@@ -77,12 +77,12 @@
</callout>
<callout
arearefs="area-Reference_Guide-Portal_Navigation_Configuration-Overview-ownerType">
<para>
- <parameter>ownerType</parameter> define the type of
portal navigation. It may be a portal, group or user
+ <parameter>ownerType</parameter> defines the type of
portal navigation. It may be a portal, group, or user.
</para>
</callout>
<callout
arearefs="area-Reference_Guide-Portal_Navigation_Configuration-Overview-templateLocation">
<para>
- <parameter>templateLocation</parameter> the classpath
where contains all portal configuration files
+ <parameter>templateLocation</parameter> defines the
classpath to all portal configuration files
</para>
</callout>
<callout
arearefs="area-Reference_Guide-Portal_Navigation_Configuration-Overview-importMode">
@@ -117,7 +117,7 @@
Based on these parameters, the portal will look for the configuration files
and create a relevant portal navigation, pages and data import strategy.
</para>
<para>
- The portal configuration files will be stored in folders with path look like
<filename>{templateLocation}/{ownerType}/{predefinedOwner}</filename>, all
navigations are defined in the <filename>navigation.xml</filename> file, pages
are defined in <filename>pages.xml</filename> and portal configuration is
defined in <filename>portal.xml</filename>.
+ The portal configuration files are stored in the
<filename>{templateLocation}/{ownerType}/{predefinedOwner}</filename> folder:
navigations are defined in the <filename>navigation.xml</filename> file; pages
are defined in <filename>pages.xml</filename>; portal configuration is defined
in <filename>portal.xml</filename>.
</para>
<para>
For example, with the above configuration, portal will look for all
configuration files from <filename>war:/conf/portal/portal/classic
path.</filename>
@@ -160,10 +160,10 @@
This file defines all the navigation nodes the portal will have.
The syntax is simple and uses nested node tags. Each node references a page defined in
<filename>pages.xml</filename> file.
</para>
<!-- Updated based on Gatein revision 6987 --> <para>
- If the administrator wants to create node labels for each
language, they will have to use <literal>xml:lang</literal> attribute in the
label tag with value of <literal>xml:lang</literal> is the relevant locale.
+ To create node labels for each language, define the
<property>label</property> tag with the
<literal>xml:lang</literal> attribute with the relevant locale value.
</para>
<para>
- Otherwise, if they want the node label is localized by resource
bundle files, the <literal>#{...}</literal> syntax will be used, the enclosed
property name serves as a key that is automatically passed to internationalization
mechanism which replaces the literal property name with a localized value taken from the
associated properties file matching the current locale.
+ Otherwise, if you want the node label to be localized by resource
bundle files, the <literal>#{...}</literal> syntax will be used, the enclosed
property name serves as a key that is automatically passed to internationalization
mechanism which replaces the literal property name with a localized value taken from the
associated properties file matching the current locale.
</para>
<!-- DOC NOTE: Replaced code navigation.xml with code from GateIn commit r3831
(as per instruction from theute) --> <programlisting
language="XML" role="XML"><xi:include
xmlns:xi="http://www.w3.org/2001/XInclude"
href="../../extras/PortalDevelopment_DefaultPortalNavigationConfiguration/navigation.xml"
parse="text"/></programlisting>
<para>
Modified:
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/NavigationController.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/NavigationController.xml 2012-10-12
15:25:08 UTC (rev 8884)
+++
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/NavigationController.xml 2012-10-12
15:54:27 UTC (rev 8885)
@@ -33,7 +33,7 @@
<section id="sect-Reference_Guide-Controller_in_Action-Controller">
<title>Controller</title>
<para>
- The <application>WebAppController</application> is the
component of JBoss Enterprise Portal Platform that process
<literal>http</literal> invocations and transforms them into a portal request.
It has been improved with the addition of a request mapping engine (<emphasis
role="bold">controller</emphasis>) whose role is to make the decoupling
of the <literal>http</literal> request and create a portal request.
+ The <application>WebAppController</application> is the
component of JBoss Enterprise Portal Platform that processes
<literal>http</literal> invocations and transforms them into a portal request.
It has been improved with the addition of a request mapping engine (<emphasis
role="bold">controller</emphasis>) whose role is to make the decoupling
of the <literal>http</literal> request and create a portal request.
</para>
<para>
The mapping engine makes two essential tasks:
@@ -54,7 +54,7 @@
The goal of the controller (mapping engine) is to <emphasis
role="bold">decouple</emphasis> the request processed by JBoss
Enterprise Portal Platform from the incoming <literal>HTTP</literal> request.
</para>
<para>
- Indeed a request contain data that determines how the request will be
processed and such data can be encoded in various places in the request such as the
request path or a query parameter. The controller allows JBoss Enterprise Portal Platform
route a request according to a set of parameters (a map) instead of the servlet request.
+ Indeed a request contains data that determines how the request will be
processed and such data can be encoded in various places in the request such as the
request path or a query parameter. The controller allows JBoss Enterprise Portal Platform
route a request according to a set of parameters (a map) instead of the servlet request.
</para>
<para>
The controller configuration is declarative in an XML file, allowing easy
reconfiguration of the routing table and it is processed into an internal data structure
that is used to perform resolution (routing or rendering)
@@ -109,7 +109,7 @@
</listitem>
<listitem>
<para>
- Operation findRoutes: route the request argument through the
controller and returns a list of all parameter map resolution. The argument is a request
uri such as <uri>/g/:platform:administrators/administration/registry</uri>. It
returns a string representation (<code>List<Map></code>) of the
matched routes.
+ Operation findRoutes: routes the request argument through the
controller and returns a list of parameter map resolution. The argument is a request URI
such as <uri>/g/:platform:administrators/administration/registry</uri>. It
returns a string representation (<code>List<Map></code>) of the
matched routes.
</para>
</listitem>
</itemizedlist>
@@ -117,32 +117,33 @@
<section
id="sect-Reference_Guide-Controller_in_Action-Controller_Configuration_controller.xml">
<title>Controller Configuration (controller.xml)</title>
<para>
- Most of the controller configuration cares about defining rules (Routing
table - contains routes object) that will drive the resolution. Routes are processed
during the controller initialization to give a tree of node. Each node:
</para>
+ Most of the controller configuration cares about defining rules (Routing
table - contains routes object) that will drive the resolution. Routes are processed
during the controller initialization to give a tree of nodea. For every node, the
following is true: </para>
<itemizedlist>
<listitem>
<para>
- is related to its parent with a matching rule that can either be
an <emphasis role="bold">exact string matching</emphasis> or a
<emphasis role="bold">regular expression matching</emphasis>
+ It is related to its parent with a matching rule that can either be an
<emphasis role="bold">exact string matching</emphasis> or a
<emphasis role="bold">regular expression matching</emphasis>
</para>
</listitem>
<listitem>
<para>
- is associated with a set of parameters
+ It is associated with a set of parameters.
</para>
</listitem>
</itemizedlist>
- <para> A parameter is defined by a qualified name and there are
three kind of parameters: Route, Path, and Request.
- </para>
+ <para>
+ A parameter is defined by a qualified name. There are three types of parameters:
Route, Path, and Request.
+ </para>
<section
id="sect-Reference_Guide-Controller_Configuration_controller.xml-_Route_parameters_">
<title>
<emphasis role="bold">Route parameters</emphasis>
</title>
<para>
- Route parameters defines a fixed value associate with a qualified
name.
+ The Route parameter defines a fixed value associated with a qualified
name.
</para>
<itemizedlist>
<listitem>
<para>
- Routing: route parameters allow the controller to distinguish
branches easily and route the request accordingly.
+ Routing: route parameters allow the controller to distinguish
branches and route the request accordingly.
</para>
</listitem>
<listitem>
@@ -277,12 +278,12 @@
<itemizedlist>
<listitem>
<para>
- selection occurs for required parameters when is the
parameter is present and matched in the map.
+ selection occurs for required parameters when the
parameter is present and matched in the map.
</para>
</listitem>
<listitem>
<para>
- selection occurs for optional parameters when is the
parameter is absent or matched in the map.
+ selection occurs for optional parameters when the
parameter is absent or matched in the map.
</para>
</listitem>
</itemizedlist>
@@ -302,7 +303,7 @@
<itemizedlist>
<listitem>
<para>
- a <code>value</code> or a
<code>pattern</code> element a child element to match a constant or a pattern
+ a <code>value</code> or a
<code>pattern</code> element child element to match a constant or a pattern
</para>
</listitem>
<listitem>
@@ -320,7 +321,7 @@
<section
id="sect-Reference_Guide-Controller_Configuration_controller.xml-Route_precedence">
<title>Route precedence</title>
<para>
- The order of route declaration is important as it influence how rules
are matched. Sometimes the same request could be matched by several routes and the routing
table is ambiguous.
+ The order of route declaration is important as it influences how
rules are matched. Sometimes the same request could be matched by several routes and the
routing table is ambiguous.
</para>
<programlisting language="XML">
<route path="/foo">
@@ -397,7 +398,7 @@
<section
id="sect-Reference_Guide-Integrate_to_JBoss_Enterprise_Portal_Platform_WebUI_framework-Routing">
<title>Routing</title>
<para>
- JBoss Enterprise Portal Platform defines a set of parameters in its
routing table, for each client request, the mapping engine processes the request path and
return the defined parameters with their values as a Map<QualifiedName,
String>
+ JBoss Enterprise Portal Platform defines a set of parameters in its
routing table: for each client request, the mapping engine processes the request path and
returns the defined parameters with their values as a Map<QualifiedName,
String>
</para>
<para>
<emphasis role="bold">gtn:handler</emphasis>
@@ -436,13 +437,13 @@
<emphasis role="bold">gtn:sitetype / gtn:sitename /
gtn:path</emphasis>
</para>
<para>
- Those qualified names drives a request for the portal handler. They are
used to determine which site to show and which path to resolve against a navigation. For
instance the (gtn:sitetype=portal,gtn:sitename=classic,gtn:path=home) instruct the portal
handler to show the home page of the classic portal site.
+ The qualified names drive a request for the portal handler. They are used
to determine which site to show and which path to resolve against a navigation. For
instance the (gtn:sitetype=portal,gtn:sitename=classic,gtn:path=home) instruct the portal
handler to show the home page of the classic portal site.
</para>
<para>
<emphasis role="bold">gtn:lang</emphasis>
</para>
<para>
- The language in the URL for the portal handler. This is a new feature
offered, now language can be specified on URL. that mean user can bookmark that URL (with
the information about language) or he can changed language simply by modifying the URL
address
+ The language in the URL for the portal handler. This is a new feature
offered, now language can be specified in a URL: user can bookmark the URL along with the
information about the language or change the language by modifying the URL address.
</para>
<para>
<emphasis role="bold">gtn:componentid / gtn:action /
gtn:objectid</emphasis>
@@ -461,7 +462,7 @@
<emphasis role="bold">Portal URL</emphasis>
</title>
<para>
- <code>PortalURL</code> play a similar role at the portal
level, its main role is to abstract the creation of an URL for a resource managed by the
portal.
+ <code>PortalURL</code> has a similar role at the portal
level: its main role is to abstract the creation of a URL for a resource managed by the
portal.
</para>
<programlisting language="Java">
public abstract class PortalURL<R, U extends PortalURL<U>>
@@ -485,7 +486,7 @@
</listitem>
</itemizedlist>
<para>
- A portal URL has various methods but certainly the most important
method is the <code>toString()</code> method that generates an URL
representing that will target the resource associated with the URL. The remaining methods
are getter and setter for mutating the URL configuration, those options will affect the
URL representation when it is generated.
+ A portal URL has various methods but certainly the most important
method is the <code>toString()</code> method that generates a URL representing
that will target the resource associated with the URL. The remaining methods are getter
and setter for mutating the URL configuration, those options will affect the URL
representation when it is generated.
</para>
<itemizedlist>
<listitem>
@@ -519,7 +520,7 @@
RequestContext ctx = RequestContext.getCurrentInstance();
</programlisting>
<para>
- <code>PortalURL</code> are created via to the
<code>createURL</code> method that takes as input a resource type. A resource
type is usually a constant and is a type safe object that allow to retrieve
<code>PortalURL</code> subclasses:
+ <code>PortalURL</code> is created with the
<code>createURL</code> method that has a resource type as its input parameter.
A resource type is usually a constant and a type-safe object that allows to retrieve the
<code>PortalURL</code> subclasses:
</para>
<programlisting language="Java">
RequestContext ctx = RequestContext.getCurrentInstance();
@@ -534,7 +535,7 @@
</programlisting>
<note>
<para>
- The <code>NodeURL.TYPE</code> is actually declared as
<code>new ResourceType<NavigationResource, NodeURL>()</code>
that can be described as a <emphasis role="bold">type
literal</emphasis> object emulated by a Java anonymous inner class. Such literal
were introduced by Neil Gafter as Super Type Token and popularized by Google Guice as Type
Literal. It's an interesting way to create a literal representing a kind of Java
type.
+ The <code>NodeURL.TYPE</code> is actually declared as
<code>new ResourceType<NavigationResource, NodeURL>()</code>
that can be described as a <emphasis role="bold">type
literal</emphasis> object emulated by a Java anonymous inner class. Such literals
were introduced by Neil Gafter as Super Type Token and popularized by Google Guice as Type
Literal. It's an interesting way to create a literal representing a kind of Java
type.
</para>
</note>
</section>
@@ -636,7 +637,7 @@
<section id="sect-Reference_Guide-Rendering-Groovy_Templates">
<title>Groovy Templates</title>
<para>
- Within a Groovy template the mechanism is the same, however a splash
of integration has been done to make creation of NodeURL simpler. A closure is bound under
the <code>nodeurl</code> name and is available for invocation anytime. It will
simply create a NodeURL object and return it:
+ Within a Groovy template the mechanism is the same, however a splash
of integration has been done to make creation of NodeURL simpler. A closure is bound under
the <code>nodeurl</code> name and is available for invocation anytime. It will
simply create and return a NodeURL object:
</para>
<programlisting language="Java">
UserNode node = ...;
Modified:
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml 2012-10-12
15:25:08 UTC (rev 8884)
+++
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml 2012-10-12
15:54:27 UTC (rev 8885)
@@ -177,7 +177,7 @@
<term>WEB-INF/gatein-resources.xml</term>
<listitem>
<para>
- For the default portal skin, this file contains definitions for the
portal skin, the window decorations that this skin provides and well as defining some
JavaScript resources which are not related to the skin. The default portal skin
doesn't directly define portlet skins, these should be provided by the portlets
themselves.
+ For the default portal skin, this file contains definitions for the portal
skin, the window decorations that this skin provides as well as defining some JavaScript
resources which are not related to the skin. The default portal skin doesn't
directly define portlet skins, these should be provided by the portlets themselves.
</para>
</listitem>
</varlistentry>
@@ -185,7 +185,7 @@
<term>WEB-INF/web.xml</term>
<listitem>
<para>
- For the default portal skin, the
<filename>web.xml</filename> of the
<literal>eXoResources.war</literal> will contains a lot of information which
is mostly irrelevant to the portal skinning. The area of interest in this file is the
<literal>resourcerequestfilter</literal> and the fact that the
<parameter>display-name</parameter> is set.
+ For the default portal skin, the
<filename>web.xml</filename> of the
<literal>eXoResources.war</literal> contains a lot of information which is
mostly irrelevant to the portal skinning. The area of interest in this file is the
<literal>resourcerequestfilter</literal> and the fact that the
<parameter>display-name</parameter> is set.
</para>
</listitem>
</varlistentry>
@@ -406,7 +406,7 @@
</listitem>
</itemizedlist>
<para>
- This causes JBoss Enterprise Portal Platform to create non-functioning
a CSS-link in html-src-code.
+ This causes JBoss Enterprise Portal Platform to create a
non-functioning CSS-link in html-src-code.
</para>
<procedure>
<title>To Resolve This:</title>
Modified:
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge/configuration.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge/configuration.xml 2012-10-12
15:25:08 UTC (rev 8884)
+++
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge/configuration.xml 2012-10-12
15:54:27 UTC (rev 8885)
@@ -624,7 +624,7 @@
The bridge maps a render parameter to a backing bean using settings
in your <filename>faces-config.xml</filename> and
<filename>portlet.xml</filename>.
</para>
<para>
- A clear and working example can be found in the Seam Booking Demo
portlet. <ulink
url="http://anonsvn.jboss.org/repos/portletbridge/tags/2.3.0.CP01.EP...
+ An example can be found in the Seam Booking Demo portlet. <ulink
url="http://anonsvn.jboss.org/repos/portletbridge/tags/2.3.1.GA.EPP5...
</para>
<para>
You must define the following <emphasis>init
params</emphasis> in your <filename>portlet.xml</filename>.
@@ -652,7 +652,7 @@
We have setup a few examples to show you how to use
<literal>EL</literal> and a simple bean that will allow you to use the portlet
resource serving mechanism within a JSF portlet.
</para>
<para>
- In <ulink
url="http://anonsvn.jboss.org/repos/portletbridge/tags/2.3.0.CP01.EP...;,
you can see a very simple implementation of a Map object that uses the bridge to get and
encode a resource URL served from the portlet application.
+ In <ulink
url="http://anonsvn.jboss.org/repos/portletbridge/tags/2.3.1.GA.EPP5...;,
you can see a very simple implementation of a Map object that uses the bridge to get and
encode a resource URL served from the portlet application.
</para>
<para>
So, when you have the normal
"<filename>/images</filename>",
"<filename>/styles</filename>" and other resource folders in
your web application, you can use the following <literal>EL</literal>
expression to serve them in your JSF application.
Modified: epp/docs/branches/5.2/Reference_Guide/en-US/modules/WSRP.xml
===================================================================
--- epp/docs/branches/5.2/Reference_Guide/en-US/modules/WSRP.xml 2012-10-12 15:25:08 UTC
(rev 8884)
+++ epp/docs/branches/5.2/Reference_Guide/en-US/modules/WSRP.xml 2012-10-12 15:54:27 UTC
(rev 8885)
@@ -113,7 +113,7 @@
<listitem>
<para>
The <filename>extension-config-&VZ;.jar</filename>,
which contains the configuration file
- needed by the GateIn extension mechanism to properly register this EAR
as an extension.
+ needed by the portal extension mechanism to properly register this EAR
as an extension.
</para>
</listitem>
<listitem>
@@ -154,18 +154,11 @@
<section id="wsrp-ports">
<title>Considerations to use WSRP when running JBoss Enterprise Portal
Platform on a non-default port or hostname</title>
<para>
- JBoss WS (the web service stack that JBoss Enterprise Portal Platform uses)
should take care of the details of updating the
- port and host name used in WSDL. See the
- <ulink
url="http://community.jboss.org/wiki/JBossWS-UserGuide#Configuration...
WS user guide on that subject </ulink>
- for more details.
+ JBoss WS, the web service stack that JBoss Enterprise Portal Platform uses,
is used to update the
+ port and host name used in WSDL. Refer to <citetitle>JBoss WS user
guide</citetitle> for more details.
</para>
<para>
- Of course, if you have modified the host name and port on which your server
runs, you will
- need to
- update the configuration for the consumer used to consume JBoss Enterprise
Portal Platform's 'self' producer. Please refer to
- the
- <xref linkend="consumer_configuration"/>
- to learn how to do so.
+ If you have modified the host name and port on which your server runs, make
sure that you update the configuration for the consumer used to consume JBoss Enterprise
Portal Platform's 'self' producer (refer to <xref
linkend="consumer_configuration"/>).
</para>
</section>
</section>