Author: smumford
Date: 2010-05-16 19:22:28 -0400 (Sun, 16 May 2010)
New Revision: 3100
Modified:
portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US/Book_Info.xml
portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US/modules/Advanced/JCR/configuration.xml
portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US/modules/Advanced/JCR/intro.xml
portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US/modules/WSRP.xml
Log:
JBEPP-276: Edits in JCR section
Modified:
portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US/Book_Info.xml
===================================================================
---
portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US/Book_Info.xml 2010-05-16
17:02:45 UTC (rev 3099)
+++
portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US/Book_Info.xml 2010-05-16
23:22:28 UTC (rev 3100)
@@ -6,10 +6,10 @@
<bookinfo id="book-Reference_Guide-Reference_Guide">
<title>Reference Guide</title>
<subtitle>An in-depth guide to Enterprise Portal Platform 5.0</subtitle>
- <productname>&PRODUCT;</productname>
- <productnumber>&VERSION;</productnumber>
+ <productname>JBoss Enterprise Portal Platform</productname>
+ <productnumber>5.0</productnumber>
<edition>1</edition>
- <pubsnumber>1.0</pubsnumber>
+ <pubsnumber>1.1</pubsnumber>
<abstract>
<para>
This Reference Guide is a high-level usage document. It deals with more advanced
topics than the Installation and User Guides, adding new content or taking concepts
discussed in the earlier documents further. It aims to provide supporting documentation
for advanced users of the &PRODUCT; product. Its primary focus is on advanced use of
the product and it assumes an intermediate or advanced knowledge of the technology and
terms.
Modified:
portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US/modules/Advanced/JCR/configuration.xml
===================================================================
---
portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US/modules/Advanced/JCR/configuration.xml 2010-05-16
17:02:45 UTC (rev 3099)
+++
portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US/modules/Advanced/JCR/configuration.xml 2010-05-16
23:22:28 UTC (rev 3100)
@@ -9,7 +9,7 @@
<section
id="sect-Reference_Guide-eXo_JCR_configuration-Portal_and_Standalone_configuration">
<title>Portal and Standalone configuration</title>
<para>
- Like other eXo services eXo JCR can be configured and used in portal or embedded mode
(as a service embedded in eXo Portal) and in standalone mode.
+ Like other eXo services eXo JCR can be configured and used in Portal (or Embedded)
mode (as a service embedded in eXo Portal) and in Standalone mode.
</para>
<para>
In Embedded mode, JCR services are registered in the Portal container. In Standalone
mode JCR uses a Standalone container.
@@ -20,204 +20,342 @@
<para>
The following setup procedure is used to obtain a Standalone configuration:
<!--(DOC TODO find more in Container configuration)-->
</para>
+<!-- DOC TODO: The following list of points are unclear. Are the edited versions
correct? -->
+
<itemizedlist>
<listitem>
- <para>
+ <!--Original <para>
Configuration that is set explicitly using
StandaloneContainer.addConfigurationURL(String url) or
StandaloneContainer.addConfigurationPath(String path) before getInstance()
+ </para> -->
+ <!-- Revised --><para>
+ Configuration must be explicitly set using
<literal>StandaloneContainer.addConfigurationURL(String url)</literal> or
<literal>StandaloneContainer.addConfigurationPath(String path)</literal>before
<literal>getInstance()</literal> makes a call.
</para>
</listitem>
<listitem>
- <para>
+ <!-- Original <para>
Configuration from $base:directory/exo-configuration.xml or
$base:directory/conf/exo-configuration.xml file. Where $base:directory is either AS's
home directory in case of J2EE AS environment or just the current directory in case of a
standalone application.
+ </para> -->
+ <!-- Revised --><para>
+ Configuration settings are read from
<filename><replaceable>$base:directory</replaceable>/exo-configuration.xml</filename>
or
<filename><replaceable>$base:directory</replaceable>/conf/exo-configuration.xml</filename>.
</para>
+ <para>
+ Replace <replaceable>$base:directory</replaceable> in the above
locations with, either the Application Server's home directory (in J2EE environments)
or the current directory for standalone applications.
+ </para>
</listitem>
<listitem>
- <para>
+ <!-- Original <para>
/conf/exo-configuration.xml in the current classloader (e.g. war, ear archive)
+ </para> -->
+ <!-- Revised --><para>
+ The current classloader <code>war</code> or <code>ear</code>
archive must contain a <filename>/conf/exo-configuration.xml</filename> file.
</para>
</listitem>
<listitem>
- <para>
+ <!-- Original <para>
Configuration from $service_jar_file/conf/portal/configuration.xml. WARNING: do not
rely on some concrete jar's configuration if you have more than one jar containing
conf/portal/configuration.xml file. In this case choosing a configuration is
unpredictable.
+ </para> -->
+ <!-- Revised --><para>
+ Further configuration setting are read from
<filename><replaceable>$service_jar_file</replaceable>/conf/portal/configuration.xml</filename>
</para>
+ <important>
+ <para>
+ Do not rely on the settings contained in any particular configuration file if you
have more than one <code>jar</code> archive that contains a
<filename>conf/portal/configuration.xml</filename> file. Behavior in this
scenario can be erratic as the JCR's choice of configuration file is unpredictable.
+ </para>
+ </important>
</listitem>
</itemizedlist>
<para>
- JCR service configuration looks like:
+ The JCR service configuration is formatted as follows:
</para>
+ <programlistingco>
+ <areaspec>
+ <area coords="10"
id="area-Reference_Guide-eXo_JCR_configuration-Portal_and_Standalone_configuration-JCR_Service_Configuration-conf-path"
/>
+ <area coords="16"
id="area-Reference_Guide-eXo_JCR_configuration-Portal_and_Standalone_configuration-JCR_Service_Configuration-working-conf"
/>
+ </areaspec>
-<programlisting><component>
-
<key>org.exoplatform.services.jcr.RepositoryService</key>
-
<type>org.exoplatform.services.jcr.impl.RepositoryServiceImpl</type>
- </component>
- <component>
-
<key>org.exoplatform.services.jcr.config.RepositoryServiceConfiguration</key>
-
<type>org.exoplatform.services.jcr.impl.config.RepositoryServiceConfigurationImpl</type>
- <init-params>
- <value-param>
- <name>conf-path</name>
- <description>JCR repositories configuration
file</description>
-
<value>jar:/conf/standalone/exo-jcr-config.xml</value>
- </value-param>
- <properties-param>
- <name>working-conf</name>
- <description>working-conf</description>
- <property name="source-name" value="jdbcjcr"
/>
- <property name="dialect" value="hsqldb" />
- <property name="persister-class-name"
value="org.exoplatform.services.jcr.impl.config.JDBCConfigurationPersister"
/>
- </properties-param>
- </init-params>
- </component>
-</programlisting>
- <para>
- conf-path : a path to a RepositoryService JCR Configuration
- </para>
- <para>
- working-conf : optional; JCR configuration persister configuration. If there isn't
a working-conf the persister will be disabled
- </para>
+<programlisting language="XML"
role="XML"><![CDATA[<component>
+ <key>org.exoplatform.services.jcr.RepositoryService</key>
+ <type>org.exoplatform.services.jcr.impl.RepositoryServiceImpl</type>
+ </component>
+ <component>
+
<key>org.exoplatform.services.jcr.config.RepositoryServiceConfiguration</key>
+
<type>org.exoplatform.services.jcr.impl.config.RepositoryServiceConfigurationImpl</type>
+ <init-params>
+ <value-param>
+
+ <name>conf-path</name>
+ <description>JCR repositories configuration file</description>
+ <value>jar:/conf/standalone/exo-jcr-config.xml</value>
+ </value-param>
+ <properties-param>
+
+ <name>working-conf</name>
+ <description>working-conf</description>
+ <property name="source-name" value="jdbcjcr" />
+ <property name="dialect" value="hsqldb" />
+ <property name="persister-class-name"
value="org.exoplatform.services.jcr.impl.config.JDBCConfigurationPersister"
/>
+ </properties-param>
+ </init-params>
+ </component>]]></programlisting>
+ <calloutlist>
+ <callout
arearefs="area-Reference_Guide-eXo_JCR_configuration-Portal_and_Standalone_configuration-JCR_Service_Configuration-conf-path">
+ <para>
+ <literal><conf-path></literal> is a path to a
<literal>RepositoryService</literal> JCR Configuration.
+ </para>
+ </callout>
+ <callout
arearefs="area-Reference_Guide-eXo_JCR_configuration-Portal_and_Standalone_configuration-JCR_Service_Configuration-working-conf">
+ <para>
+ <literal><working-conf></literal> is an optional JCR
configuration persister configuration. The persister will be disabled if there is no
<literal><working-conf></literal> defined.
+ </para>
+ </callout>
+ </calloutlist>
+ </programlistingco>
+
<section
id="sect-Reference_Guide-Portal_and_Standalone_configuration-JCR_Configuration">
<title>JCR Configuration</title>
<para>
- The Configuration is defined in an XML file (see DTD below).
+ The JCR configuration is defined in an XML file (as per the DTD below).
</para>
<para>
- JCR Service can use multiple Repositories and each repository can have multiple
Workspaces.
+ The JCR Service can use multiple Repositories and each repository can have multiple
Workspaces.
</para>
<para>
- Repositories configuration parameters support human-readable formats of values. They
are all case-insensitive:
+ The Repositories configuration parameters support human-readable formats of values.
They are not case-sensitive.
</para>
- <itemizedlist>
+ <para>
+ The parameters are:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term>Number formats:</term>
<listitem>
<para>
- Numbers formats: K,KB - kilobytes, M,MB - megabytes, G,GB - gigabytes, T,TB -
terabytes.
+ <itemizedlist>
+ <listitem>
+ <para>
+ <emphasis role="bold">K</emphasis> or <emphasis
role="bold">KB</emphasis> for kilobytes.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">M</emphasis> or <emphasis
role="bold">MB</emphasis> for megabytes.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">G</emphasis> or <emphasis
role="bold">GB</emphasis> for gigabytes.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">T</emphasis> or <emphasis
role="bold">TB</emphasis> for terrabytes.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Examples: 200k or 200 Kbytes; 4m or 4 Mbytes; 1.4G or 1.4 Gbytes; 10T or 10
Tbytes
+ </para>
+ </listitem>
+ </itemizedlist>
</para>
- <para>
- Examples: 100.5 - digit 100.5, 200k - 200 Kbytes, 4m - 4 Mbytes, 1.4G - 1.4 Gbytes,
10T - 10 Tbytes
- </para>
</listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Time formats:</term>
<listitem>
<para>
- Time format endings: ms - milliseconds, s - seconds, m - minutes, h - hours, d -
days, w - weeks, if no ending - seconds.
+ <itemizedlist>
+ <listitem>
+ <para>
+ <emphasis role="bold">ms</emphasis> for milliseconds.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">s</emphasis> for seconds.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">m</emphasis> for minutes.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">h</emphasis> for hours.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">d</emphasis> for days.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">w</emphasis> for weeks.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The default time format is seconds if no other format is specified.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Examples: 500ms or 500 milliseconds; 20, 20s or 20 seconds; 30m or 30 minutes;
12h or 12 hours; 5d or 5 days; 4w or 4 weeks.
+ </para>
+ </listitem>
+ </itemizedlist>
</para>
- <para>
- Examples: 500ms - 500 milliseconds, 20 or 20s - 20 seconds, 30m - 30 minutes, 12h -
12 hours, 5d - 5 days, 4w - 4 weeks.
- </para>
</listitem>
- </itemizedlist>
- <para>
- </para>
+ </varlistentry>
+ </variablelist>
</section>
<section
id="sect-Reference_Guide-Portal_and_Standalone_configuration-Repository_service_configuration">
<title>Repository service configuration</title>
<para>
- Default configuration of the Repository Service located in
jar:/conf/portal/exo-jcr-config.xml, it will be available for portal and standalone
modes.
+ The default configuration of the Repository Service is defined in
<filename><replaceable>jar:</replaceable>/conf/portal/exo-jcr-config.xml</filename>.
It is available in both portal and standalone modes.
</para>
<para>
- In portal mode it is overriden and located in the portal web application
portal/WEB-INF/conf/jcr/repository-configuration.xml.
+ In portal mode it is overriden and located in the portal web application
<filename>portal/WEB-INF/conf/jcr/repository-configuration.xml</filename>.
</para>
<para>
- Example of Repository Service configuration for standalone mode:
+ An example of the Repository Service configuration for standalone mode is included
below:
</para>
-
-<programlisting><repository-service
default-repository="repository">
- <repositories>
- <repository name="db1" system-workspace="ws"
default-workspace="ws">
- <security-domain>exo-domain</security-domain>
- <access-control>optional</access-control>
- <session-max-age>1h</session-max-age>
-
<authentication-policy>org.exoplatform.services.jcr.impl.core.access.JAASAuthenticator</authentication-policy>
- <workspaces>
- <workspace name="production">
- <!-- for system storage -->
- <container
class="org.exoplatform.services.jcr.impl.storage.jdbc.optimisation.CQJDBCWorkspaceDataContainer">
- <properties>
- <property name="source-name"
value="jdbcjcr" />
- <property name="multi-db" value="false"
/>
- <property name="update-storage"
value="false" />
- <property name="max-buffer-size"
value="200k" />
- <property name="swap-directory"
value="../temp/swap/production" />
- </properties>
- <value-storages>
- <value-storage id="system"
class="org.exoplatform.services.jcr.impl.storage.value.fs.TreeFileValueStorage">
- <properties>
- <property name="path"
value="../temp/values/production" />
- </properties>
- <filters>
- <filter property-type="Binary" />
- </filters>
- </value-storage>
- </value-storages>
- </container>
- <initializer
class="org.exoplatform.services.jcr.impl.core.ScratchWorkspaceInitializer">
- <properties>
- <property name="root-nodetype"
value="nt:unstructured" />
- </properties>
- </initializer>
- <cache enabled="true"
class="org.exoplatform.services.jcr.impl.dataflow.persistent.LinkedWorkspaceStorageCacheImpl">
- <properties>
- <property name="max-size" value="10k"
/>
- <property name="live-time" value="1h"
/>
- </properties>
- </cache>
- <query-handler
class="org.exoplatform.services.jcr.impl.core.query.lucene.SearchIndex">
- <properties>
- <property name="index-dir"
value="../temp/jcrlucenedb/production" />
- </properties>
- </query-handler>
- <lock-manager>
- <time-out>15m</time-out>
- <persister
class="org.exoplatform.services.jcr.impl.core.lock.FileSystemLockPersister">
- <properties>
- <property name="path"
value="../temp/lock/system" />
- </properties>
- </persister>
- </lock-manager>
- </workspace>
- <workspace name="backup">
- <container
class="org.exoplatform.services.jcr.impl.storage.jdbc.optimisation.CQJDBCWorkspaceDataContainer">
- <properties>
- <property name="source-name"
value="jdbcjcr" />
- <property name="multi-db" value="false"
/>
- <property name="update-storage"
value="false" />
- <property name="max-buffer-size"
value="200k" />
- <property name="swap-directory"
value="../temp/swap/backup" />
- </properties>
- <value-storages>
- <value-storage id="draft"
class="org.exoplatform.services.jcr.impl.storage.value.fs.TreeFileValueStorage">
- <properties>
- <property name="path"
value="../temp/values/backup" />
- </properties>
- <filters>
- <filter property-type="Binary" />
- </filters>
- </value-storage>
- </value-storages>
- </container>
- <initializer
class="org.exoplatform.services.jcr.impl.core.ScratchWorkspaceInitializer">
- <properties>
- <property name="root-nodetype"
value="nt:unstructured" />
- </properties>
- </initializer>
- <cache enabled="true"
class="org.exoplatform.services.jcr.impl.dataflow.persistent.LinkedWorkspaceStorageCacheImpl">
- <properties>
- <property name="max-size" value="10k"
/>
- <property name="live-time" value="1h"
/>
- </properties>
- </cache>
- <query-handler
class="org.exoplatform.services.jcr.impl.core.query.lucene.SearchIndex">
- <properties>
- <property name="index-dir"
value="../temp/jcrlucenedb/backup" />
- </properties>
- </query-handler>
- </workspace>
- </workspaces>
- </repository>
- </repositories>
-</repository-service>
-</programlisting>
+<!-- <programlistingco>
+ <areaspec units="linecolumn">
+ <areaset id="repository-service" coords="">
+ <area coords="1 10"
id="Reference_Guide-Portal_and_Standalone_configuration-Repository_service_configuration-default-repository"/>
+ <area coords="2"
id="Reference_Guide-Portal_and_Standalone_configuration-Repository_service_configuration-repositories"/>
+ <area coords="3"
id="Reference_Guide-Portal_and_Standalone_configuration-Repository_service_configuration-name"/>
+ <area coords="4"
id="Reference_Guide-Portal_and_Standalone_configuration-Repository_service_configuration-default-workspace"/>
+ </areaset>
+ </areaspec> -->
+
+<programlisting language="XML"
role="XML"><![CDATA[<repository-service
default-repository="repository">
+ <repositories>
+ <repository name="db1" system-workspace="ws"
default-workspace="ws">
+ <security-domain>exo-domain</security-domain>
+ <access-control>optional</access-control>
+ <session-max-age>1h</session-max-age>
+
<authentication-policy>org.exoplatform.services.jcr.impl.core.access.JAASAuthenticator</authentication-policy>
+ <workspaces>
+ <workspace name="production">
+ <!-- for system storage -->
+ <container
class="org.exoplatform.services.jcr.impl.storage.jdbc.optimisation.CQJDBCWorkspaceDataContainer">
+ <properties>
+ <property name="source-name" value="jdbcjcr"
/>
+ <property name="multi-db" value="false"
/>
+ <property name="update-storage" value="false"
/>
+ <property name="max-buffer-size" value="200k"
/>
+ <property name="swap-directory"
value="../temp/swap/production" />
+ </properties>
+ <value-storages>
+ <value-storage id="system"
class="org.exoplatform.services.jcr.impl.storage.value.fs.TreeFileValueStorage">
+ <properties>
+ <property name="path"
value="../temp/values/production" />
+ </properties>
+ <filters>
+ <filter property-type="Binary" />
+ </filters>
+ </value-storage>
+ </value-storages>
+ </container>
+ <initializer
class="org.exoplatform.services.jcr.impl.core.ScratchWorkspaceInitializer">
+ <properties>
+ <property name="root-nodetype"
value="nt:unstructured" />
+ </properties>
+ </initializer>
+ <cache enabled="true"
class="org.exoplatform.services.jcr.impl.dataflow.persistent.LinkedWorkspaceStorageCacheImpl">
+ <properties>
+ <property name="max-size" value="10k" />
+ <property name="live-time" value="1h" />
+ </properties>
+ </cache>
+ <query-handler
class="org.exoplatform.services.jcr.impl.core.query.lucene.SearchIndex">
+ <properties>
+ <property name="index-dir"
value="../temp/jcrlucenedb/production" />
+ </properties>
+ </query-handler>
+ <lock-manager>
+ <time-out>15m</time-out>
+ <persister
class="org.exoplatform.services.jcr.impl.core.lock.FileSystemLockPersister">
+ <properties>
+ <property name="path"
value="../temp/lock/system" />
+ </properties>
+ </persister>
+ </lock-manager>
+ </workspace>
+
+ <workspace name="backup">
+ <container
class="org.exoplatform.services.jcr.impl.storage.jdbc.optimisation.CQJDBCWorkspaceDataContainer">
+ <properties>
+ <property name="source-name" value="jdbcjcr"
/>
+ <property name="multi-db" value="false"
/>
+ <property name="update-storage" value="false"
/>
+ <property name="max-buffer-size" value="200k"
/>
+ <property name="swap-directory"
value="../temp/swap/backup" />
+ </properties>
+ <value-storages>
+ <value-storage id="draft"
class="org.exoplatform.services.jcr.impl.storage.value.fs.TreeFileValueStorage">
+ <properties>
+ <property name="path"
value="../temp/values/backup" />
+ </properties>
+ <filters>
+ <filter property-type="Binary" />
+ </filters>
+ </value-storage>
+ </value-storages>
+ </container>
+ <initializer
class="org.exoplatform.services.jcr.impl.core.ScratchWorkspaceInitializer">
+ <properties>
+ <property name="root-nodetype"
value="nt:unstructured" />
+ </properties>
+ </initializer>
+ <cache enabled="true"
class="org.exoplatform.services.jcr.impl.dataflow.persistent.LinkedWorkspaceStorageCacheImpl">
+ <properties>
+ <property name="max-size" value="10k" />
+ <property name="live-time" value="1h" />
+ </properties>
+ </cache>
+ <query-handler
class="org.exoplatform.services.jcr.impl.core.query.lucene.SearchIndex">
+ <properties>
+ <property name="index-dir"
value="../temp/jcrlucenedb/backup" />
+ </properties>
+ </query-handler>
+ </workspace>
+ </workspaces>
+ </repository>
+ </repositories>
+</repository-service>]]></programlisting>
+
+<!-- <calloutlist>
+ <callout
arearefs="Reference_Guide-Portal_and_Standalone_configuration-Repository_service_configuration-default-repository">
+ <para>
+ The name of a default repository (one returned by
RepositoryService.getRepository())
+ </para>
+ </callout>
+ <callout
arearefs="Reference_Guide-Portal_and_Standalone_configuration-Repository_service_configuration-repositories">
+ <para>
+ The list of repositories is configured within the <repositories>
wrapper.
+ </para>
+ </callout>
+ <callout
arearefs="Reference_Guide-Portal_and_Standalone_configuration-Repository_service_configuration-name">
+ <para>
+ The name of the repository being configured.
+ </para>
+ </callout>
+ <callout
arearefs="Reference_Guide-Portal_and_Standalone_configuration-Repository_service_configuration-default-workspace">
+ <para>
+ The name of a workspace. This can be obtained using Session's
<literal>login()</literal> or
<literal>login(Credentials)</literal> methods for workspaces without an
explicit name.
+ </para>
+ </callout>
+ </calloutlist>
+ </programlistingco> -->
+
<variablelist>
<title>Repository Service configuration:</title>
<varlistentry>
@@ -248,11 +386,12 @@
</para>
</listitem>
</varlistentry>
+
<varlistentry>
<term>default-workspace</term>
<listitem>
<para>
- The name of a workspace obtained using Session's login() or login(Credentials)
methods (ones without an explicit workspace name).
+
</para>
</listitem>
</varlistentry>
@@ -513,12 +652,12 @@
</listitem>
</varlistentry>
</variablelist>
-<!-- <para>
- LinkedWorkspaceStorageCacheImpl supports additional optional parameters TODO
- </para> -->
+ <para>
+ TODO LinkedWorkspaceStorageCacheImpl supports additional optional parameters
+ </para>
</listitem>
</varlistentry>
- </variablelist>
+ </variablelist>
<variablelist>
<title>Query Handler configuration:</title>
Modified:
portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US/modules/Advanced/JCR/intro.xml
===================================================================
---
portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US/modules/Advanced/JCR/intro.xml 2010-05-16
17:02:45 UTC (rev 3099)
+++
portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US/modules/Advanced/JCR/intro.xml 2010-05-16
23:22:28 UTC (rev 3100)
@@ -6,7 +6,7 @@
<section id="sect-Reference_Guide-Introduction">
<title>Introduction</title>
<para>
- The Java Content Repository(JCR) API was created within the Java Community Process
<ulink type="http"
url="http://jcp.org/">http://jcp.org/</ulink>) as a collaboration
between an expert group and the Java community.
+ The Java Content Repository (JCR) API was created within the Java Community Process
<ulink type="http"
url="http://jcp.org/">http://jcp.org/</ulink>) as a collaboration
between an expert group and the Java community.
</para>
<para>
Within the JCP, JCR is known as Java Specification Request-170 (JSR-170) <ulink
type="http"
url="http://www.jcp.org/en/jsr/detail?id=170">http://www.jcp...;.
Modified:
portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US/modules/WSRP.xml
===================================================================
---
portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US/modules/WSRP.xml 2010-05-16
17:02:45 UTC (rev 3099)
+++
portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US/modules/WSRP.xml 2010-05-16
23:22:28 UTC (rev 3100)
@@ -32,7 +32,7 @@
More information on WSRP can be found on the official <ulink
url="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp...;.
</para>
<para>
- We suggest reading the <ulink
url="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp...
for a comprehensive overview of WSRP.
+ The <ulink
url="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp...
is suggested reading for a comprehensive overview of WSRP.
</para>
</section>
@@ -42,20 +42,20 @@
The WSRP Technical Committee defined <ulink
url="http://www.oasis-open.org/committees/download.php/3073">... Use
Profiles</ulink> to help with WSRP interoperability. Terms defined in that document
will be used in this section.
</para>
<para>
- &PRODUCT_NAME; provides a <emphasis>Simple</emphasis> level of support
for our WSRP Producer except that out-of-band registration is not currently handled. We
support in-band registration and persistent local state (which are defined at the
<emphasis>Complex</emphasis> level).
+ &PRODUCT_NAME; provides a <emphasis>Simple</emphasis> level of support
for our WSRP Producer except that out-of-band registration is not currently handled. The
WSRP component supports in-band registration and persistent local state (which are defined
at the <emphasis>Complex</emphasis> level).
</para>
<para>
- On the Consumer side, &PRODUCT_NAME; provides a
<emphasis>Medium</emphasis> level of support for WSRP, except that we only
handle HTML markup (as &PRODUCT_NAME; itself doesn't handle other markup types).
We do support explicit portlet cloning and we fully support the
<literal>PortletManagement</literal> interface.
+ On the Consumer side, &PRODUCT_NAME; provides a
<emphasis>Medium</emphasis> level of support for WSRP, except that it only
handles HTML markup (as &PRODUCT_NAME; itself doesn't handle other markup types).
The WSRP component does support explicit portlet cloning and the
<literal>PortletManagement</literal> interface.
</para>
<para>
- We has Level 1 Producer and Consumer caching. Cookie handling is supported properly on
the Consumer and our Producer requires initialization of cookies (this improves
interoperabilty with some consumers).
+ The WSRP component has Level 1 Producer and Consumer caching. Cookie handling is
supported properly on the Consumer and our Producer requires initialization of cookies
(this improves interoperabilty with some consumers).
</para>
<para>
- We don't support custom window states or modes, as Portal doesn't either. We
do, however, support CSS on both the Producer (though it's more a function of the
portlets than inherent Producer capability) and Consumer.
+ The WSRP component does not support custom window states or modes, as Portal
doesn't either. The WSRP component does, however, support CSS on both the Producer
(though it is more a function of the portlets than an inherent Producer capability) and
Consumer.
</para>
- <para>
- While we provide a complete implementation of WSRP 1.0, we do need to go through the
<ulink
url="http://www.oasis-open.org/committees/download.php/6018">...
statements</ulink> and perform more interoperability testing (an area that needs to
be better supported by the WSRP Technical Committee and Community at large).
- </para>
+<!-- <para>
+ While &PRODUCT; provides a complete implementation of WSRP 1.0, do need to go
through the <ulink
url="http://www.oasis-open.org/committees/download.php/6018">...
statements</ulink> and perform more interoperability testing (an area that needs to
be better supported by the WSRP Technical Committee and Community at large).
+ </para> -->
<note>
<para>
As of version &PRODUCT_VERSION; of &PRODUCT_NAME;, WSRP is only activated and
supported when &PRODUCT_NAME; is deployed on JBoss Application Server.
@@ -64,7 +64,7 @@
<warning>
<title>DOC TODO</title>
<para>
- Who or What is the <emphasis role="bold">WE</emphasis> referred
to in these paragraphs? Red Hat, &PRODUCT; or the developers of WSRP?
+ Replaced all references to <emphasis role="bold">we</emphasis>
in this file with either references to WSRP component or EPP. Does this break the
meaning?
</para>
</warning>
</section>
@@ -247,50 +247,67 @@
</para>
<!-- Mark -->
<para>
- In the example above, the <varname>RemotelyExposedPortlet</varname>
inherits the remotable status defined at the <code>portlet-app</code> level
since it does not specify a value for the<code>org.gatein.pc.remotable
container-runtime-option</code>.
The<varname>NotRemotelyExposedPortlet</varname>, however, overrides the
default behavior and is not remotely exposed. Note that in the absence of a top-level
<code>org.gatein.pc.remotable container-runtime-option</code> value set
to<code>true</code>, portlets are NOT remotely exposed.
+ In the example above, the <varname>RemotelyExposedPortlet</varname>
inherits the remotable status defined at the <code>portlet-app</code> level
since it does not specify a value for the<code>org.gatein.pc.remotable
container-runtime-option</code>.
</para>
+ <para>
+ The<varname>NotRemotelyExposedPortlet</varname>, however, overrides the
default behavior and is not remotely exposed.
+ </para>
+ <note>
+ <para>
+ Portlets are not remotely exposed if no top-level <code>org.gatein.pc.remotable
container-runtime-option</code> value is set to <code>true</code>.
+ </para>
+ </note>
</section>
<section
id="sect-Reference_Guide-Web_Services_for_Remote_Portlets_WSRP-Consuming_PRODUCT_NAMEs_WSRP_portlets_from_a_remote_Consumer">
<title>Consuming &PRODUCT_NAME;'s WSRP portlets from a remote
Consumer</title>
<para>
- WSRP Consumers vary a lot as far as how they are configured. Most of them require that
you specify the URL for the Producer's WSDL definition. Please refer to your
Consumer's documentation for specific instructions. For instructions on how to do so
in &PRODUCT_NAME;, please refer to <xref
linkend="sect-Reference_Guide-Web_Services_for_Remote_Portlets_WSRP-Consuming_remote_WSRP_portlets_in_PRODUCT_NAME"
/>.
+ Configuration is extremely variable between different WSRP Consumers. Most, however,
require a specification of the URL for the Producer's WSDL definition.
</para>
<para>
- &PRODUCT_NAME;'s Producer is automatically set up when you deploy a portal
instance with the WSRP service. You can access the WSDL file at
<filename>http://{hostname}:{port}/wsrp-producer/MarkupService?wsdl</filename>.
The default hostname is <literal>localhost</literal> and the default port is
8080.
+ For instructions on how to specify this URL in &PRODUCT_NAME;, please refer to
<xref
linkend="sect-Reference_Guide-Web_Services_for_Remote_Portlets_WSRP-Consuming_remote_WSRP_portlets_in_PRODUCT_NAME"
/>.
</para>
+ <para>
+ &PRODUCT_NAME;'s Producer is automatically set up when a portal instance is
deployed with the WSRP service.
+ </para>
+ <para>
+ The WSDL file can be accessed at
<filename>http://<replaceable>{hostname}</replaceable>:<replaceable>{port}</replaceable>/wsrp-producer/MarkupService?wsdl</filename>.
The default hostname is <literal>localhost</literal> and the default port is
8080.
+ </para>
</section>
<section
id="sect-Reference_Guide-Web_Services_for_Remote_Portlets_WSRP-Consuming_remote_WSRP_portlets_in_PRODUCT_NAME">
<title>Consuming remote WSRP portlets in &PRODUCT_NAME;</title>
<section
id="sect-Reference_Guide-Consuming_remote_WSRP_portlets_in_PRODUCT_NAME-Overview"><title>Overview</title>
<para>
- To be able to consume WSRP portlets exposed by a remote producer,
&PRODUCT_NAME;'s WSRP consumer needs to know how to access that remote producer.
One can configure access to a remote producer using WSRP Producer descriptors.
Alternatively, a portlet is provided to configure remote producers.
+ To be able to consume WSRP portlets exposed by a remote producer,
&PRODUCT_NAME;'s WSRP consumer needs to know how to access that remote producer.
</para>
<para>
+ Access to a remote producer can be configured using WSRP Producer descriptors.
Alternatively, a portlet is provided to configure remote producers.
+ </para>
+ <para>
Once a remote producer has been configured, the portlets that it exposes are then
available in the Application Registry to be added to categories and then to pages.
</para>
<para>
- As a way to test the WSRP producer service and to check that the portlets that you
want to expose remotely are correctly published via WSRP, a default consumer named
<literal>self</literal>, that consumes the portlets exposed by
&PRODUCT_NAME;'s producer, has been configured.
+ A default consumer named <literal>self</literal>, that consumes the
portlets exposed by &PRODUCT_NAME;'s producer, has been configured as a way to
test the WSRP producer service and to check that portlets are correctly published via
WSRP.
</para>
</section>
- <section
id="sect-Reference_Guide-Consuming_remote_WSRP_portlets_in_PRODUCT_NAME-Configuring_a_remote_producer_walk_through">
- <title>Configuring a remote producer walk-through</title>
+ <section
id="sect-Reference_Guide-Consuming_remote_WSRP_portlets_in_PRODUCT_NAME-Configuring_a_remote_producer">
+ <title>Configuring a remote producer</title>
<para>
- Let's work through the steps of defining access to a remote producer so that its
portlets can be consumed within &PRODUCT_NAME;. We will configure access to
Oracle's public WSRP producer. We will first examine how to do so using the
configuration portlet. We will then show how the same result can be accomplished with a
producer descriptor, though it is far easier to do so via the configuration portlet.
+ Let's work through the steps of defining access to a remote producer so that its
portlets can be consumed within &PRODUCT_NAME;. the WSRP component will configure
access to Oracle's public WSRP producer. the WSRP component will first examine how to
do so using the configuration portlet. the WSRP component will then show how the same
result can be accomplished with a producer descriptor, though it is far easier to do so
via the configuration portlet.
</para>
<section
id="sect-Reference_Guide-Configuring_a_remote_producer_walk_through-Using_the_configuration_portlet">
<title>Using the configuration portlet</title>
<para>
- &PRODUCT_NAME; provides a portlet to configure access (among other functions)
to remote WSRP Producers grahically. It isn't, however, installed by default, so the
first thing we will need to do is to install the WSRP configuration portlet using the
Application Registry.
+ &PRODUCT_NAME; provides a portlet to configure access (among other functions)
to remote WSRP Producers grahically. It isn't, however, installed by default, so the
first thing the WSRP component will need to do is to install the WSRP configuration
portlet using the Application Registry.
</para>
<para>
Use the usual procedure to log in as a Portal administrator and go to the
Application Registry. With the default install, you can just go to <ulink
url="http://localhost:8080/portal/login?initialURI=%2Fportal%2Fprivate%2Fclassic%2Fadministration%2Fregistry&username=root&password=gtn">
http://localhost:8080/portal/login?initialURI=%2Fportal%2Fprivate%2Fclass...
</ulink> Add the WSRP Configuration portlet to the Administration category. If you
use the Import Applications functionality, the WSRP Configuration portlet will be
automatically added to the Administration category.
</para>
<para>
- Now that the portlet is added to a category, it can be added to a page and used.
We recommend adding it to the same page as the Application Registry as operations relating
to WSRP and adding portlets to categories are somewhat related as we will see. Go ahead
and add the WSRP Configuration portlet to the page using the standard procedure.
+ Now that the portlet is added to a category, it can be added to a page and used.
the WSRP component recommend adding it to the same page as the Application Registry as
operations relating to WSRP and adding portlets to categories are somewhat related as the
WSRP component will see. Go ahead and add the WSRP Configuration portlet to the page
using the standard procedure.
</para>
<para>
If all went well, you should see something similar to this:
@@ -304,7 +321,7 @@
This screen presents all the configured producers associated with their status
and possible actions on them. A Consumer can be active or inactive. Activating a Consumer
means that it is ready to act as a portlet provider. Note also that a Consumer can be
marked as requiring refresh meaning that the information held about it might not be up to
date and refreshing it from the remote Producer might be a good idea. This can happen for
several reasons: the service description for that remote Producer has not been fetched
yet, the cached version has expired or modifications have been made to the configuration
that could potentially invalidate it, thus requiring re-validation of the information.
</para>
<para>
- Next, we create a new Consumer which we will
call<literal>oracle</literal>. Type "<literal>
oracle</literal>" in the "Create a consumer named:" field then click
on "Create consumer":
+ Next, the WSRP component create a new Consumer which the WSRP component will
call<literal>oracle</literal>. Type "<literal>
oracle</literal>" in the "Create a consumer named:" field then click
on "Create consumer":
</para>
<mediaobject>
<imageobject>
@@ -355,7 +372,7 @@
<section
id="sect-Reference_Guide-Configuring_a_remote_producer_walk_through-Using_XML">
<title>Using XML</title>
<para>
- While we recommend you use the WSRP Configuration portlet to configure Consumers,
we provide an alternative way to configure consumers by editing the XML file located at
<filename>$GATEIN_HOME/lib/wsrp-consumer-$WSRP_VERSION.jar/conf/wsrp-consumers-config.xml</filename>.
+ While the WSRP component recommend you use the WSRP Configuration portlet to
configure Consumers, the WSRP component provide an alternative way to configure consumers
by editing the XML file located at
<filename>$GATEIN_HOME/lib/wsrp-consumer-$WSRP_VERSION.jar/conf/wsrp-consumers-config.xml</filename>.
</para>
<programlisting role="XML">
@@ -387,14 +404,14 @@
The file as shown above specifies access to two producers:
<literal>self</literal>, which consumes &PRODUCT_NAME;'s own WSRP
producer albeit in a version that assumes that the producer requires a value for an
<literal>email</literal> registration property, and
<literal>oracle</literal>, which consumes Oracle's public producer, both
in configurations as shown in the walk-through above.
</para>
<para>
- We will look at the details of the meaning of elements later on.
+ the WSRP component will look at the details of the meaning of elements later
on.
</para>
</section>
<section
id="sect-Reference_Guide-Configuring_a_remote_producer_walk_through-Configuring_access_to_a_remote_portlet">
<title>Configuring access to a remote portlet</title>
<para>
- If we go back to the Application Registry and examine the available portlets by
clicking on the Portlet link, you will now be able to see the remote portlets if you click
on the REMOTE tab in the left column:
+ If the WSRP component go back to the Application Registry and examine the
available portlets by clicking on the Portlet link, you will now be able to see the remote
portlets if you click on the REMOTE tab in the left column:
</para>
<mediaobject>
<imageobject>
@@ -418,7 +435,7 @@
<section
id="sect-Reference_Guide-Consuming_remote_WSRP_portlets_in_PRODUCT_NAME-Configuring_access_to_remote_producers_via_XML">
<title>Configuring access to remote producers via XML</title>
<para>
- While we recommend you use the WSRP Configuration portlet to configure Consumers,
we provide an alternative way to configure consumers by editing the XML file located at
<filename>$GATEIN_HOME/lib/wsrp-consumer-$WSRP_VERSION.jar/conf/wsrp-consumers-config.xml</filename>.
+ While the WSRP component recommend you use the WSRP Configuration portlet to
configure Consumers, the WSRP component provide an alternative way to configure consumers
by editing the XML file located at
<filename>$GATEIN_HOME/lib/wsrp-consumer-$WSRP_VERSION.jar/conf/wsrp-consumers-config.xml</filename>.
</para>
<note>
<para>
@@ -427,7 +444,7 @@
</note>
<note>
<para>
- It is important to note how the XML consumers configuration file is processed. It
is read the first time the WSRP service starts and the associated information is then put
under control of JCR (Java Content Repository). Subsequent launches of the WSRP service
will use the JCR-stored information for all producers are already known to
&PRODUCT_NAME;. More specifically,
<filename>wsrp-consumers-config.xml</filename> file is scanned for producer
identifiers. Any identifier that is already known will be bypassed and the JCR information
associated with this remote producer will be used. The information defined at the XML
level is only processed for producer definition for which no information is already
present in JCR. Therefore, if you wish to delete a producer configuration, you need to
delete the associated information in the database (this can be accomplished using the
configuration portlet as we saw in <xref
linkend="sect-Reference_Guide-Configuring_a_remote_producer_!
walk_through-Using_the_configuration_portlet" />)
<emphasis>AND</emphasis> remove the associated information in
<filename>wsrp-consumers-config.xml</filename> (if such information exists) as
the producer will be re-created the next time the WSRP is launched if that information is
not removed.
+ It is important to note how the XML consumers configuration file is processed. It
is read the first time the WSRP service starts and the associated information is then put
under control of JCR (Java Content Repository). Subsequent launches of the WSRP service
will use the JCR-stored information for all producers are already known to
&PRODUCT_NAME;. More specifically,
<filename>wsrp-consumers-config.xml</filename> file is scanned for producer
identifiers. Any identifier that is already known will be bypassed and the JCR information
associated with this remote producer will be used. The information defined at the XML
level is only processed for producer definition for which no information is already
present in JCR. Therefore, if you wish to delete a producer configuration, you need to
delete the associated information in the database (this can be accomplished using the
configuration portlet as the WSRP component saw in <xref
linkend="sect-Reference_Guide-Configuring_a!
_remote_producer_walk_through-Using_the_configuration_portlet" />)
<emphasis>AND</emphasis> remove the associated information in
<filename>wsrp-consumers-config.xml</filename> (if such information exists) as
the producer will be re-created the next time the WSRP is launched if that information is
not removed.
</para>
</note>
@@ -437,7 +454,7 @@
Let's now look at which information needs to be provided to configure access
to a remote producer.
</para>
<para>
- First, we need to provide an identifier for the producer we are configuring so
that we can refer to it afterwards. This is accomplished via the mandatory
<literal>id</literal> attribute of the
<literal><wsrp-producer></literal> element.
+ First, the WSRP component need to provide an identifier for the producer the WSRP
component are configuring so that the WSRP component can refer to it afterwards. This is
accomplished via the mandatory <literal>id</literal> attribute of the
<literal><wsrp-producer></literal> element.
</para>
<para>
&PRODUCT_NAME; also needs to learn about the remote producer's endpoints
to be able to connect to the remote web services and perform WSRP invocations. This is
accomplished by specifying the URL for the WSDL description for the remote WSRP service,
using the <literal><endpoint-wsdl-url></literal> element.
@@ -453,7 +470,7 @@
It is also possible to provide addtional configuration, which, in some cases,
might be important to establish a proper connection to the remote producer.
</para>
<para>
- One such optional configuration concerns caching. To prevent useless roundtrips
between the local consumer and the remote producer, it is possible to cache some of the
information sent by the producer (such as the list of offered portlets) for a given
duration. The rate at which the information is refreshed is defined by the
<literal>expiration-cache</literal> attribute of the
<literal><wsrp-producer></literal> element which specifies the
refreshing period in seconds. For example, providing a value of 120 for expiration-cache
means that the producer information will not be refreshed for 2 minutes after it has been
somehow accessed. If no value is provided, &PRODUCT_NAME; will always access the
remote producer regardless of whether the remote information has changed or not. Since, in
most instances, the information provided by the producer does not change often, we
recommend that you use this caching facility to minimize bandwidth usage.
+ One such optional configuration concerns caching. To prevent useless roundtrips
between the local consumer and the remote producer, it is possible to cache some of the
information sent by the producer (such as the list of offered portlets) for a given
duration. The rate at which the information is refreshed is defined by the
<literal>expiration-cache</literal> attribute of the
<literal><wsrp-producer></literal> element which specifies the
refreshing period in seconds. For example, providing a value of 120 for expiration-cache
means that the producer information will not be refreshed for 2 minutes after it has been
somehow accessed. If no value is provided, &PRODUCT_NAME; will always access the
remote producer regardless of whether the remote information has changed or not. Since, in
most instances, the information provided by the producer does not change often, the WSRP
component recommend that you use this caching facility to minimize bandwidth usage.
</para>
<para>
It is also possible to define a timeout after which WS operations are considered
as failed. This is helpful to avoid blocking the WSRP service, waiting forever on the
service that doesn't answer. Use the <literal>ws-timeout</literal>
attribute of the <literal><wsrp-producer></literal> element to
specify how many milliseconds the WSRP service will wait for a response from the remote
producer before timing out and giving up.
@@ -537,10 +554,10 @@
There might also be cases where you just want to update the registration
information because it has changed. For example, the producer required you to provide a
valid email and the previously email address is not valid anymore and needs to be
updated.
</para>
<para>
- It is therefore sometimes necessary to modify the registration that concretizes
the service agreement between a consumer and a producer. Let's take the example of the
producer requiring an email we configured in <xref
linkend="sect-Reference_Guide-Configuring_a_remote_producer_walk_through-Using_the_configuration_portlet"
/>. If you recall, the producer was requiring registration and required a value to be
provided for the <literal>email</literal> property.
+ It is therefore sometimes necessary to modify the registration that concretizes
the service agreement between a consumer and a producer. Let's take the example of the
producer requiring an email the WSRP component configured in <xref
linkend="sect-Reference_Guide-Configuring_a_remote_producer_walk_through-Using_the_configuration_portlet"
/>. If you recall, the producer was requiring registration and required a value to be
provided for the <literal>email</literal> property.
</para>
<para>
- Suppose now that we would like to update the email address that we provided to
the remote producer. We will need to tell the producer that our registration data has been
modified. Let's see how to do this. Assuming you have configured access to the
producer as previously described, please go to the configuration screen for the
<literal>self</literal> producer and modify the value of
<literal>email</literal> to <literal>foo(a)example.com</literal>
instead of<literal>example(a)example.com</literal>:
+ Suppose now that the WSRP component would like to update the email address that
the WSRP component provided to the remote producer. the WSRP component will need to tell
the producer that our registration data has been modified. Let's see how to do this.
Assuming you have configured access to the producer as previously described, please go to
the configuration screen for the <literal>self</literal> producer and modify
the value of <literal>email</literal> to
<literal>foo(a)example.com</literal> instead
of<literal>example(a)example.com</literal>:
</para>
<mediaobject>
<imageobject>
@@ -568,7 +585,7 @@
<section
id="sect-Reference_Guide-Modifying_a_currently_held_registration-Registration_modification_on_producer_error">
<title>Registration modification on producer error</title>
<para>
- It can also happen that a producer administrator decided to change its
requirement forregistered consumers. In this case, invoking operations on the producer
will fail with an <exceptionname>OperationFailedFault</exceptionname>.
&PRODUCT_NAME; will attempt to help you in this situation. Let's walk through an
example using the <literal>self</literal> producer. Let's assume that
registration is requiring a valid value for an <literal>email</literal>
registration property (as we have seen so far). If you go to the configuration screen for
this producer, you should see:
+ It can also happen that a producer administrator decided to change its
requirement forregistered consumers. In this case, invoking operations on the producer
will fail with an <exceptionname>OperationFailedFault</exceptionname>.
&PRODUCT_NAME; will attempt to help you in this situation. Let's walk through an
example using the <literal>self</literal> producer. Let's assume that
registration is requiring a valid value for an <literal>email</literal>
registration property (as the WSRP component have seen so far). If you go to the
configuration screen for this producer, you should see:
</para>
<mediaobject>
<imageobject>
@@ -576,7 +593,7 @@
</imageobject>
</mediaobject>
<para>
- Now suppose that the administrator of the producer now additionaly requires a
value to be provided for a <literal>name</literal> registration property. We
will actually see how to do perform this operation in &PRODUCT_NAME; when we examine
how to configure &PRODUCT_NAME;'s producer in <xref
linkend="sect-Reference_Guide-Web_Services_for_Remote_Portlets_WSRP-Configuring_PRODUCT_NAMEs_WSRP_Producer"
/>. Operations with this producer will now fail. If you suspect that a registration
modification is required, you should go to the configuration screen for this remote
producer and refresh the information held by the consumer by pressing "Refresh
& Save":
+ Now suppose that the administrator of the producer now additionaly requires a
value to be provided for a <literal>name</literal> registration property. the
WSRP component will actually see how to do perform this operation in &PRODUCT_NAME;
when the WSRP component examine how to configure &PRODUCT_NAME;'s producer in
<xref
linkend="sect-Reference_Guide-Web_Services_for_Remote_Portlets_WSRP-Configuring_PRODUCT_NAMEs_WSRP_Producer"
/>. Operations with this producer will now fail. If you suspect that a registration
modification is required, you should go to the configuration screen for this remote
producer and refresh the information held by the consumer by pressing "Refresh
& Save":
</para>
<mediaobject>
<imageobject>
@@ -679,7 +696,7 @@
<section
id="sect-Reference_Guide-Configuring_PRODUCT_NAMEs_WSRP_Producer-Default_configuration">
<title>Default configuration</title>
<para>
- The default producer configuration is to require that consumers register with it
before providing access its services but does not require any specific registration
properties (apart from what is mandated by the WSRP standard). It does, however, require
consumers to be registered before sending them a full service description. This means that
our WSRP producer will not provide the list of offered portlets and other capabilities to
unregistered consumers. The producer also uses the default
<classname>RegistrationPolicy</classname> paired with the default
<classname>RegistrationPropertyValidator</classname>. We will look into
property validators in greater detail later in<xref
linkend="sect-Reference_Guide-Configuring_PRODUCT_NAMEs_WSRP_Producer-Registration_configuration"
/>. Suffice to say for now that this allows users to customize how Portal's WSRP
Producer decides whether a given registration property is valid or not.
+ The default producer configuration is to require that consumers register with it
before providing access its services but does not require any specific registration
properties (apart from what is mandated by the WSRP standard). It does, however, require
consumers to be registered before sending them a full service description. This means that
our WSRP producer will not provide the list of offered portlets and other capabilities to
unregistered consumers. The producer also uses the default
<classname>RegistrationPolicy</classname> paired with the default
<classname>RegistrationPropertyValidator</classname>. the WSRP component will
look into property validators in greater detail later in<xref
linkend="sect-Reference_Guide-Configuring_PRODUCT_NAMEs_WSRP_Producer-Registration_configuration"
/>. Suffice to say for now that this allows users to customize how Portal's WSRP
Producer decides whether a given registration property is valid or not.
</para>
<para>
&PRODUCT_NAME; provides a web interface to configure the producer's
behavior. You can access it by clicking on the "Producer Configuration" tab of
the "WSRP" page of the "admin" portal. Here's what you should see
with the default configuration:
@@ -705,7 +722,7 @@
</imageobject>
</mediaobject>
<para>
- We will allow unregistered consumers to see the list of offered portlets so we
leave the first checkbox ("Access to full service description requires consumers to
be registered.") unchecked. We will, however, specify that consumers will need to be
registered to be able to interact with our producer. Check the second checkbox
("Requires registration. Modifying this information will trigger invalidation of
consumer registrations."). The screen should now refresh and display:
+ the WSRP component will allow unregistered consumers to see the list of offered
portlets so the WSRP component leave the first checkbox ("Access to full service
description requires consumers to be registered.") unchecked. the WSRP component
will, however, specify that consumers will need to be registered to be able to interact
with our producer. Check the second checkbox ("Requires registration. Modifying this
information will trigger invalidation of consumer registrations."). The screen should
now refresh and display:
</para>
<mediaobject>
<imageobject>
@@ -713,7 +730,7 @@
</imageobject>
</mediaobject>
<para>
- You can specify the fully-qualified name for your
<classname>RegistrationPolicy</classname> and
<classname>RegistrationPropertyValidator</classname> there. We will keep the
default value. See <xref
linkend="sect-Reference_Guide-Registration_configuration-Customization_of_Registration_handling_behavior"
/> for more details. Let's add, however, a registration property called
<literal>email</literal>. Click "Add property" and enter the
appropriate information in the fields, providing a description for the registration
property that can be used by consumers to figure out its purpose:
+ You can specify the fully-qualified name for your
<classname>RegistrationPolicy</classname> and
<classname>RegistrationPropertyValidator</classname> there. the WSRP component
will keep the default value. See <xref
linkend="sect-Reference_Guide-Registration_configuration-Customization_of_Registration_handling_behavior"
/> for more details. Let's add, however, a registration property called
<literal>email</literal>. Click "Add property" and enter the
appropriate information in the fields, providing a description for the registration
property that can be used by consumers to figure out its purpose:
</para>
<mediaobject>
<imageobject>
@@ -730,7 +747,7 @@
</note>
<note>
<para>
- If consumers are already registered with the producer, modifying the
configuration of required registration information will trigger the invalidation of held
registrations, requiring consumers to modify their registration before being able to
access the producer again. We saw the consumer side of that process in <xref
linkend="sect-Reference_Guide-Modifying_a_currently_held_registration-Registration_modification_on_producer_error"
/>.
+ If consumers are already registered with the producer, modifying the
configuration of required registration information will trigger the invalidation of held
registrations, requiring consumers to modify their registration before being able to
access the producer again. the WSRP component saw the consumer side of that process in
<xref
linkend="sect-Reference_Guide-Modifying_a_currently_held_registration-Registration_modification_on_producer_error"
/>.
</para>
</note>
<section
id="sect-Reference_Guide-Registration_configuration-Customization_of_Registration_handling_behavior">
@@ -745,7 +762,7 @@
Please refer to the <trademark
class="trade">Javadoc</trademark> for
<classname>org.jboss.portal.registration.RegistrationPolicy</classname> and
<classname>org.jboss.portal.Registration.policies.RegistrationPropertyValidator</classname>
for more details on what is expected of each method.
</para>
<para>
- Defining a registration policy is required for the producer to be correctly
configured. This is accomplished by specifying the qualified class name of the
registration policy. Since we anticipate that most users will use the default registration
policy, it is possible to provide the class name of your custom property validator instead
to customize the default registration policy behavior. Note that property validators are
only used by the default policy.
+ Defining a registration policy is required for the producer to be correctly
configured. This is accomplished by specifying the qualified class name of the
registration policy. Since the WSRP component anticipate that most users will use the
default registration policy, it is possible to provide the class name of your custom
property validator instead to customize the default registration policy behavior. Note
that property validators are only used by the default policy.
</para>
<note>
<para>
@@ -758,7 +775,7 @@
<section
id="sect-Reference_Guide-Configuring_PRODUCT_NAMEs_WSRP_Producer-WSRP_validation_mode">
<title>WSRP validation mode</title>
<para>
- The lack of conformance kit and the wording of the WSRP specification leaves room
for differing interpretations, resulting in interoperability issues. It is therefore
possible to encounter issues when using consumers from different vendors. We have
experienced such issues and have introduced a way to relax the validation that our WSRP
producer performs on the data provided by consumers to help with interoperability by
accepting data that would normally be invalid. Note that we only relax our validation
algorithm on aspects of the specification that are deemed harmless such as invalid
language codes.
+ The lack of conformance kit and the wording of the WSRP specification leaves room
for differing interpretations, resulting in interoperability issues. It is therefore
possible to encounter issues when using consumers from different vendors. the WSRP
component have experienced such issues and have introduced a way to relax the validation
that our WSRP producer performs on the data provided by consumers to help with
interoperability by accepting data that would normally be invalid. Note that the WSRP
component only relax our validation algorithm on aspects of the specification that are
deemed harmless such as invalid language codes.
</para>
<para>
By default, the WSRP producer is configured in strict mode. If you experience
issues with a given consumer, you might want to try to relax the validation mode. This is
accomplished by unchecking the "Use strict WSRP compliance." checkbox on the
Producer configuration screen.