Author: smumford
Date: 2011-09-27 00:38:00 -0400 (Tue, 27 Sep 2011)
New Revision: 7508
Removed:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/core.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/core/
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/ws.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/ws/
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/Book_Info.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/Reference_Guide.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/faq/jcr-faq.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr-with-gtn/how-to-extend-my-gatein-instance.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/concepts/jcr-exo-implementation.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/configuration/configuration-persister.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/configuration/jdbc-data-container-config.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/jbosscache-configuration-templates.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/jca.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/other/binary-values-processing.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/performance-tuning-guide.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/query-handler-config.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/repository-creation-service.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/transaction-manager-lookup.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/cache.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/rpc-service.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/service-configuration-for-beginners.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/service-configuration-in-detail.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/transaction-service.xml
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/publican.cfg
Log:
Removed references to standalone mode and Infinispan. Removed eXo Core and eXo WS
sections
Modified: epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/Book_Info.xml
===================================================================
--- epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/Book_Info.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++ epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/Book_Info.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -3,8 +3,8 @@
<!ENTITY % BOOK_ENTITIES SYSTEM "Reference_Guide.ent">
%BOOK_ENTITIES;
]>
-<bookinfo id="book-Reference_Guide-Reference_Guide">
- <title>Reference Guide</title>
+<bookinfo id="book-Reference_Guide-Reference_Guide_eXo_JCR_1.14">
+ <title>Reference Guide eXo JCR 1.14</title>
<subtitle>An in-depth guide to Enterprise Portal Platform
&VZ;</subtitle>
<productname>JBoss Enterprise Portal Platform</productname>
<productnumber>5.2</productnumber>
@@ -25,7 +25,7 @@
</inlinemediaobject>
</corpauthor>
- <!-- FOR PUBLICAN --> <xi:include
href="Common_Content/Legal_Notice.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"> <!-- FOR JDOCBOOK: -->
<xi:fallback
xmlns:xi="http://www.w3.org/2001/XInclude"> <xi:include
href="fallback_content/Legal_Notice.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <!-- FOR PUBLICAN --> <xi:include
href="Common_Content/Legal_Notice.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"> <!-- FOR JDOCBOOK: -->
<xi:fallback
xmlns:xi="http://www.w3.org/2001/XInclude"> <xi:include
href="fallback_content/Legal_Notice.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
</xi:fallback>
</xi:include>
<xi:include href="Author_Group.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
Modified: epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/Reference_Guide.xml
===================================================================
--- epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/Reference_Guide.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++ epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/Reference_Guide.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -4,14 +4,15 @@
%BOOK_ENTITIES;
]>
<book>
- <xi:include href="Book_Info.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Preface.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="modules/Introduction.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="modules/PortalDevelopment.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="modules/PortletDevelopment.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <!-- <xi:include href="modules/GadgetDevelopment.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" /> --> <xi:include
href="modules/AuthenticationAndIdentity.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="modules/WSRP.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="modules/Advanced.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Revision_History.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Book_Info.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Preface.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="modules/Introduction.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="modules/PortalDevelopment.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="modules/PortletDevelopment.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <!-- <xi:include href="modules/GadgetDevelopment.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" /> -->
+ <xi:include href="modules/AuthenticationAndIdentity.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="modules/WSRP.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="modules/Advanced.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Revision_History.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
</book>
Deleted:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/core.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/core.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/core.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -1,23 +0,0 @@
-<?xml version='1.0' encoding='utf-8' ?>
-<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % BOOK_ENTITIES SYSTEM "Reference_Guide.ent">
-%BOOK_ENTITIES;
-]>
-<section id="sect-Reference_Guide-eXoCore">
- <title>eXoCore</title>
- <xi:include href="core/core.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="core/db-creator-service.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="core/security-service.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="core/spring-security-integration.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="core/organization-service.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="core/organization-service-initalizer.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="core/organization-service-listener.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="core/conversationstate-when-membership-changed.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="core/db-schema-creator-service.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="core/db-configuration-hibernate.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="core/ldap-configuration.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="core/tika-document-reader-service.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="core/digest-auth.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
-</section>
-
-
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/faq/jcr-faq.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/faq/jcr-faq.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/faq/jcr-faq.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -4,181 +4,181 @@
%BOOK_ENTITIES;
]>
<section id="sect-Reference_Guide-JCR_FAQ">
- <title>JCR FAQ</title>
- <para>
- It's the draft for a future FAQ of JCR usage.
- </para>
- <section id="sect-Reference_Guide-JCR_FAQ-Kernel">
- <title>Kernel</title>
- <section
id="sect-Reference_Guide-Kernel-What_is_the_best_standardized_way_to_get_the_instance_of_a_service_">
- <title>What is the best, standardized way to get the instance of a service
?</title>
-
+ <title>JCR FAQ</title>
+ <para>
+ It's the draft for a future FAQ of JCR usage.
+ </para>
+ <section id="sect-Reference_Guide-JCR_FAQ-Kernel">
+ <title>Kernel</title>
+ <section
id="sect-Reference_Guide-Kernel-What_is_the_best_standardized_way_to_get_the_instance_of_a_service_">
+ <title>What is the best, standardized way to get the instance of a
service ?</title>
+
<programlisting language="Java"
role="Java">container.getComponentInstanceOfType(ServiceName.class);</programlisting>
- </section>
-
+ </section>
+
- </section>
-
- <section id="sect-Reference_Guide-JCR_FAQ-JCR">
- <title>JCR</title>
- <section id="sect-Reference_Guide-JCR-JCR_core">
- <title>JCR core</title>
- <section
id="sect-Reference_Guide-JCR_core-Is_it_better_to_use_Session.getNodeByUUID_or_Session.getItem">
- <title>Is it better to use Session.getNodeByUUID or
Session.getItem?</title>
- <para>
- Session.getNodeByUUID() about 2.5 times faster of Session.getItem(String) and only
25% faster of Node.getNode(String). See the daily tests results for such comparisons,
e.g.
- </para>
- <para>
- <ulink
url="http://tests.exoplatform.org/JCR/1.12.2-GA/rev.2442/daily-perfo...
- </para>
+ </section>
+
+ <section id="sect-Reference_Guide-JCR_FAQ-JCR">
+ <title>JCR</title>
+ <section id="sect-Reference_Guide-JCR-JCR_core">
+ <title>JCR core</title>
+ <section
id="sect-Reference_Guide-JCR_core-Is_it_better_to_use_Session.getNodeByUUID_or_Session.getItem">
+ <title>Is it better to use Session.getNodeByUUID or
Session.getItem?</title>
+ <para>
+ Session.getNodeByUUID() about 2.5 times faster of
Session.getItem(String) and only 25% faster of Node.getNode(String). See the daily tests
results for such comparisons, e.g.
+ </para>
+ <para>
+ <ulink
url="http://tests.exoplatform.org/JCR/1.12.2-GA/rev.2442/daily-perfo...
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_core-Does_it_make_sense_to_have_all_the_node_referencable_to_use_getNodeByUUID_all_the_time">
- <title>Does it make sense to have all the node referencable to use
getNodeByUUID all the time?</title>
- <para>
- Until it's applicable for a business logic it can be. But take in account the
paths are human readable and lets you think in hierarchy. If it's important a location
based approach is preferable.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_core-Does_it_make_sense_to_have_all_the_node_referencable_to_use_getNodeByUUID_all_the_time">
+ <title>Does it make sense to have all the node referencable to use
getNodeByUUID all the time?</title>
+ <para>
+ Until it's applicable for a business logic it can be. But take in
account the paths are human readable and lets you think in hierarchy. If it's
important a location based approach is preferable.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_core-What_should_I_use_to_check_if_an_Item_exists_before_getting_the_Value">
- <title>What should I use to check if an Item exists before getting the
Value?</title>
- <para>
- Use Session.itemExists(String absPath), Node.hasNode(String relPath) or
Property.hasProperty(String name). It's also is possible to check Node.hasNodes() and
Node.hasProprties().
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_core-What_should_I_use_to_check_if_an_Item_exists_before_getting_the_Value">
+ <title>What should I use to check if an Item exists before getting
the Value?</title>
+ <para>
+ Use Session.itemExists(String absPath), Node.hasNode(String relPath)
or Property.hasProperty(String name). It's also is possible to check Node.hasNodes()
and Node.hasProprties().
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_core-How_to_use_Observation_properly">
- <title>How to use Observation properly?</title>
- <para>
- JCR Observation's a way to listen on persistence changes of a Repository. It
provides several options to configure the listener for an interesting only changes. To use
properly, it's important to understand concept of events filtering for a registered
EventListener (8.3.3 Observation Manager). An often confusing part, it's the
<emphasis role="bold">absPath</emphasis>, it's an associated
parent of a location you want to observe events on. I.e. it's a parent of child
node(s) or this parent property(ies); if <emphasis
role="bold">isDeep</emphasis> is true then you'll get events of all
the subtree of child nodes also. The same actual for <emphasis
role="bold">uuid</emphasis> and <emphasis
role="bold">nodeTypeName</emphasis> parameters of
ObservationManager.addEventListener() method.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_core-How_to_use_Observation_properly">
+ <title>How to use Observation properly?</title>
+ <para>
+ JCR Observation's a way to listen on persistence changes of a
Repository. It provides several options to configure the listener for an interesting only
changes. To use properly, it's important to understand concept of events filtering for
a registered EventListener (8.3.3 Observation Manager). An often confusing part, it's
the <emphasis role="bold">absPath</emphasis>, it's an associated
parent of a location you want to observe events on. I.e. it's a parent of child
node(s) or this parent property(ies); if <emphasis
role="bold">isDeep</emphasis> is true then you'll get events of all
the subtree of child nodes also. The same actual for <emphasis
role="bold">uuid</emphasis> and <emphasis
role="bold">nodeTypeName</emphasis> parameters of
ObservationManager.addEventListener() method.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_core-Is_it_better_to_use_queries_that_to_access_the_data_by_the_JCR_API">
- <title>Is it better to use queries that to access the data by the JCR
API?</title>
- <para>
- No, direct access to items via JCR API is more efficient. Search will consume
additional resources for index querying and only then return the items.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_core-Is_it_better_to_use_queries_that_to_access_the_data_by_the_JCR_API">
+ <title>Is it better to use queries that to access the data by the
JCR API?</title>
+ <para>
+ No, direct access to items via JCR API is more efficient. Search will
consume additional resources for index querying and only then return the items.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_core-What_is_default_query_ordering">
- <title>What is default query ordering?</title>
- <para>
- By default (if query do not contains any ordering statements) result nodes is sorted
by document order.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_core-What_is_default_query_ordering">
+ <title>What is default query ordering?</title>
+ <para>
+ By default (if query do not contains any ordering statements) result
nodes is sorted by document order.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_core-Is_ordering_by_jcrpath_or_Item_name_supported">
- <title>Is ordering by jcr:path or Item name supported?</title>
- <para>
- No, it does not supported. There is two ways to ordering results, when path may be
used as criteria:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Order by property with value type NAME or PATH (jcr supports it).
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_core-Is_ordering_by_jcrpath_or_Item_name_supported">
+ <title>Is ordering by jcr:path or Item name
supported?</title>
+ <para>
+ No, it does not supported. There is two ways to ordering results,
when path may be used as criteria:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Order by property with value type NAME or PATH (jcr supports
it).
+ </para>
- </listitem>
- <listitem>
- <para>
- Order by jcr:path - sort by exact path of node (jcr do not supports it).
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Order by jcr:path - sort by exact path of node (jcr do not
supports it).
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- Order by jcr:path
- </para>
- <para>
- If no order specification is supplied in the query statement, implementations may
support document order on the result nodes (see 6.6.4.2 Document Order). And it is sorted
by order number.
- </para>
- <para>
- By default, (if query do not contains any ordering statements) result nodes is
sorted by document order.
- </para>
-
+ </itemizedlist>
+ <para>
+ Order by jcr:path
+ </para>
+ <para>
+ If no order specification is supplied in the query statement,
implementations may support document order on the result nodes (see 6.6.4.2 Document
Order). And it is sorted by order number.
+ </para>
+ <para>
+ By default, (if query do not contains any ordering statements) result
nodes is sorted by document order.
+ </para>
+
<programlisting>SELECT * FROM nt:unstructured WHERE jcr:path LIKE
'testRoot/%'</programlisting>
- <para>
- For specified jcr:path ordering there is different proceeding in XPath and SQL:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- SQL no matter ascending or descending - query returns result nodes in random
order: {code}SELECT * FROM nt:unstructured WHERE jcr:path LIKE 'testRoot/%' ORDER
BY jcr:path{code}
- </para>
+ <para>
+ For specified jcr:path ordering there is different proceeding in
XPath and SQL:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ SQL no matter ascending or descending - query returns result
nodes in random order: {code}SELECT * FROM nt:unstructured WHERE jcr:path LIKE
'testRoot/%' ORDER BY jcr:path{code}
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- XPath - jcr:path order construction is ignored (so result is not sorted according
path); {code}/testRoot/* <ulink
url="@jcr:primaryType='nt:unstructured'">@jcr:primaryType='nt:unstructured'</ulink>
order by jcr:path{code}
- </para>
+ </itemizedlist>
+ <itemizedlist>
+ <listitem>
+ <para>
+ XPath - jcr:path order construction is ignored (so result is
not sorted according path); {code}/testRoot/* <ulink
url="@jcr:primaryType='nt:unstructured'">@jcr:primaryType='nt:unstructured'</ulink>
order by jcr:path{code}
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_core-How_eXo_JCR_indexer_uses_content_encoding">
- <title>How eXo JCR indexer uses content encoding?</title>
- <para>
- 1. Indexer uses jcr:encoding property of nt:resource node (used as jcr:content child
node of nt:file) 2. if no jcr:encoding property set the Document Service will use the one
configured in the service (defaultEncoding) 3. if nothing is configured a JVM, the default
encoding will be used
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_core-How_eXo_JCR_indexer_uses_content_encoding">
+ <title>How eXo JCR indexer uses content encoding?</title>
+ <para>
+ 1. Indexer uses jcr:encoding property of nt:resource node (used as
jcr:content child node of nt:file) 2. if no jcr:encoding property set the Document Service
will use the one configured in the service (defaultEncoding) 3. if nothing is configured a
JVM, the default encoding will be used
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_core-Which_database_server_is_better_for_eXo_JCR">
- <title>Which database server is better for eXo JCR?</title>
- <para>
- If the question is a performance, it's difficult question, as each database can
be configured to be more (and more) faster for each special case. MySQL with MyISAM engine
will be faster. But MySQL has limitations for indexes for multilingual columns (Item names
actually). So, with long Item names (larger ofOracle or PostgreSQL also are good for
performance. DB2 and MSSQL are slower in default configurations. Default configuration of
Sybase leader of slowness. But in this question, take the database server maintenance in
account. MySQL and PostgreSQL are simple in installation and can work even on limited
hardware. Oracle, DB2, MSSQL or Sybase need more efforts. The same actual for maintenance
during the work. Note for Sybase: "check-sns-new-connection" data container
configuration parameter should be set to "true". For testing purpose, embedded
database such as HSQLDB is the best choice. Apache Derby and H2 also supported. But H2
surprisingly needs "beta" feature enabl!
ed - MVCC=TRUE in JDBC url.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_core-Which_database_server_is_better_for_eXo_JCR">
+ <title>Which database server is better for eXo JCR?</title>
+ <para>
+ If the question is a performance, it's difficult question, as
each database can be configured to be more (and more) faster for each special case. MySQL
with MyISAM engine will be faster. But MySQL has limitations for indexes for multilingual
columns (Item names actually). So, with long Item names (larger ofOracle or PostgreSQL
also are good for performance. DB2 and MSSQL are slower in default configurations. Default
configuration of Sybase leader of slowness. But in this question, take the database server
maintenance in account. MySQL and PostgreSQL are simple in installation and can work even
on limited hardware. Oracle, DB2, MSSQL or Sybase need more efforts. The same actual for
maintenance during the work. Note for Sybase: "check-sns-new-connection" data
container configuration parameter should be set to "true". For testing purpose,
embedded database such as HSQLDB is the best choice. Apache Derby and H2 also supported.
But H2 surprisingly needs "beta!
" feature enabled - MVCC=TRUE in JDBC url.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_core-How_to_setup_eXo_JCR_for_mutilingial_content_on_MySQL">
- <title>How to setup eXo JCR for mutilingial content on MySQL?</title>
- <para>
- To allow multiple character sets to be sent from the client, the UTF-8 encoding
should be used, either by configuring utf8 as the default server character set, or by
configuring the JDBC driver to use UTF-8 through the characterEncoding property. MySQL
database should be created in single-byte encoding, e.g. "latin1":
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_core-How_to_setup_eXo_JCR_for_mutilingial_content_on_MySQL">
+ <title>How to setup eXo JCR for mutilingial content on
MySQL?</title>
+ <para>
+ To allow multiple character sets to be sent from the client, the
UTF-8 encoding should be used, either by configuring utf8 as the default server character
set, or by configuring the JDBC driver to use UTF-8 through the characterEncoding
property. MySQL database should be created in single-byte encoding, e.g.
"latin1":
+ </para>
+
<programlisting>CREATE DATABASE db1 CHARACTER SET latin1 COLLATE
latin1_general_cs;</programlisting>
- <para>
- eXo JCR application (e.g. GateIn) should use JCR dialect "MySQL-UTF8".
- </para>
- <para>
- In other words: MySQL database default encoding and JCR dialect cannot be UTF8 both.
Use single-byte encoding (e.g. "latin1") for database and "mysql-utf8"
dialect for eXo JCR.
- </para>
- <para>
- Notice: "MySQL-UTF8" dialect cannot be auto-detected, it should be set
explicitly in configuration.
- </para>
+ <para>
+ eXo JCR application (e.g. GateIn) should use JCR dialect
"MySQL-UTF8".
+ </para>
+ <para>
+ In other words: MySQL database default encoding and JCR dialect
cannot be UTF8 both. Use single-byte encoding (e.g. "latin1") for database and
"mysql-utf8" dialect for eXo JCR.
+ </para>
+ <para>
+ Notice: "MySQL-UTF8" dialect cannot be auto-detected, it
should be set explicitly in configuration.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_core-Does_MySQL_have_limitation_affecting_on_eXo_JCR_features">
- <title>Does MySQL have limitation affecting on eXo JCR features?</title>
- <para>
- Index's key length of JCR_SITEM (JCR_MITEM) table for mysql-utf8 dialect is
reduced to 765 bytes (or 255 chars).
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_core-Does_MySQL_have_limitation_affecting_on_eXo_JCR_features">
+ <title>Does MySQL have limitation affecting on eXo JCR
features?</title>
+ <para>
+ Index's key length of JCR_SITEM (JCR_MITEM) table for mysql-utf8
dialect is reduced to 765 bytes (or 255 chars).
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_core-Does_use_of_Sybase_database_need_special_options_in_eXo_JCR_configuration">
- <title>Does use of Sybase database need special options in eXo JCR
configuration?</title>
- <para>
- To enable JCR working properly with Sybase, a property
'check-sns-new-connection' with 'false' value is required for each
workspace data container:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_core-Does_use_of_Sybase_database_need_special_options_in_eXo_JCR_configuration">
+ <title>Does use of Sybase database need special options in eXo JCR
configuration?</title>
+ <para>
+ To enable JCR working properly with Sybase, a property
'check-sns-new-connection' with 'false' value is required for each
workspace data container:
+ </para>
+
<programlisting language="XML" role="XML"><container
class="org.exoplatform.services.jcr.impl.storage.jdbc.optimisation.CQJDBCWorkspaceDataContainer">
<properties>
<property name="source-name" value="jdbcjcr" />
@@ -191,11 +191,11 @@
<property name="check-sns-new-connection" value="false"
/>
</properties></programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_core-How_to_open_and_close_a_session_properly_to_avoid_memory_leaks">
- <title>How to open and close a session properly to avoid memory
leaks?</title>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_core-How_to_open_and_close_a_session_properly_to_avoid_memory_leaks">
+ <title>How to open and close a session properly to avoid memory
leaks?</title>
+
<programlisting language="Java" role="Java">Session session =
repository.login(credentials);
try
{
@@ -206,257 +206,41 @@
session.logout();
}</programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_core-Can_I_use_Session_after_loging_out">
- <title>Can I use Session after loging out?</title>
- <para>
- No. Any instance of Session or Node (acquired through session) shouldn't be used
after loging out anymore. At least, it is highly recommended not to use.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_core-Can_I_use_Session_after_loging_out">
+ <title>Can I use Session after loging out?</title>
+ <para>
+ No. Any instance of Session or Node (acquired through session)
shouldn't be used after loging out anymore. At least, it is highly recommended not to
use.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_core-How_to_configure_jcr_for_cluster_">
- <title>How to configure jcr for cluster ?</title>
- <para>
- So we have configured JCR in standalone mode and want to reconfigure it for
clustered environment. First of all, let's check whether all requirements are
satisfied:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Dedicated RDBMS anyone like MySQL, Postges, Oracle and, etc but just not HSSQL;
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_core-Is_JCR_suitable_for_remote_sites_synchronization">
+ <title>Is JCR suitable for remote sites\*
synchronization?</title>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Remote sites can be visualized as different buildings
seperated by a WAN network.
+ </para>
- </listitem>
- <listitem>
- <para>
- Shared storage. The simplest thing is to use shared FS like NFS or SMB mounted in
operation system, but they are rather slow. The best thing is to use SAN (Storage Area
Network);
- </para>
+ </listitem>
- </listitem>
- <listitem>
- <para>
- Fast network between JCR nodes.
- </para>
+ </itemizedlist>
- </listitem>
-
- </itemizedlist>
- <para>
- So now, need to configure Container a bit. Check exo-configuration.xml to be sure
that you are using JBossTS Transaction Service and JBossCache Transaction Manager, as
shown below.
- </para>
-
-<programlisting language="XML"
role="XML"><component>
-
<key>org.jboss.cache.transaction.TransactionManagerLookup</key>
-
<type>org.jboss.cache.GenericTransactionManagerLookup</type>
-</component>
-
-<component>
-
<key>org.exoplatform.services.transaction.TransactionService</key>
-
<type>org.exoplatform.services.transaction.jbosscache.JBossTransactionsService</type>
- <init-params>
- <value-param>
- <name>timeout</name>
- <value>300</value>
- </value-param>
- </init-params>
-</component></programlisting>
- <para>
- Next stage is actually the JCR configuration. We need JBossCache configuration
templates for : data-cache, indexer-cache and lock-manager-cache. Later they will be used
to configure JCR's core components. There are pre-bundled templates in EAR or JAR in
conf/standalone/cluster. They can be used as is or re-written if needed. And now,
re-configure a bit each workspace. Actually, a few parameters need changing, e.g.
<cache>, <query-handler> and <lock-manager>.
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <cache> configuration should look like this:
- </para>
-
-<programlisting language="XML" role="XML"><cache
enabled="true"
-
class="org.exoplatform.services.jcr.impl.dataflow.persistent.jbosscache.JBossCacheWorkspaceStorageCache">
- <properties>
- <property name="jbosscache-configuration"
value="test-jbosscache-data.xml" />
- <property name="jgroups-configuration"
value="udp-mux.xml" />
- <property name="jgroups-multiplexer-stack"
value="true" />
- <property name="jbosscache-cluster-name"
value="JCR-cluster-db1-ws" />
- </properties>
-</cache></programlisting>
- <itemizedlist>
- <listitem>
- <para>
- "jbosscache-configuration" is the path to configuration template;
- </para>
-
- </listitem>
- <listitem>
- <para>
- "jgroups-configuration" is path to JGroups configuration that is
multiplexer stack is used (default). This file is also pre-bundled with templates and is
recommended for use;
- </para>
-
- </listitem>
- <listitem>
- <para>
- "jgroups-multiplexer-stack" just simply "true". Strongly
recommended;
- </para>
-
- </listitem>
- <listitem>
- <para>
- "jbosscache-cluster-name" is the name of cluster group. It should be
different for each workspace and each workspace component. I.e.:
<repository_name>-<ws_name>-<component(cache\|lock\|index)>
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </listitem>
-
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- <query-handler> configuration
- </para>
- <itemizedlist>
- <listitem>
- <para>
- You must replace or add in <query-handler> block the
"changesfilter-class" parameter equals with:
- </para>
-
-<programlisting language="XML" role="XML"><property
name="changesfilter-class"
value="org.exoplatform.services.jcr.impl.core.query.jbosscache.JBossCacheIndexChangesFilter"/></programlisting>
-
- </listitem>
- <listitem>
- <para>
- add JBossCache-oriented configuration:
- </para>
-
-<programlisting language="XML" role="XML"><property
name="jbosscache-configuration" value="test-jbosscache-indexer.xml"
/>
-<property name="jgroups-configuration" value="udp-mux.xml"
/>
-<property name="jgroups-multiplexer-stack" value="true"
/>
-<property name="jbosscache-cluster-name"
value="JCR-cluster-indexer-db1-ws" />
-<property name="max-volatile-time" value="60"
/></programlisting>
-
- </listitem>
-
- </itemizedlist>
-
- </listitem>
-
- </itemizedlist>
- <para>
- Those properties have the same meaning and restrictions as in the previous block.
The last property "max-volatile-time" is not mandatory but recommended. This
notifies that the latest changes in index will be visible for each cluster node not later
than in 60s.
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <lock-manager> configuration
- </para>
- <para>
- Maybe this is the hardest element to configure, because we have to define access
to DB where locks will be stored. Replace exsiting lock-manager configuration with shown
below.
- </para>
-
-<programlisting language="XML" role="XML">
-<lock-manager
class="org.exoplatform.services.jcr.impl.core.lock.jbosscache.CacheableLockManagerImpl">
- <properties>
- <property name="time-out" value="15m" />
- <property name="jbosscache-configuration"
value="test-jbosscache-lock.xml" />
- <property name="jgroups-configuration"
value="udp-mux.xml" />
- <property name="jgroups-multiplexer-stack" value="true"
/>
- <property name="jbosscache-cluster-name"
value="JCR-cluster-locks-db1-ws" />
- <property name="jbosscache-cl-cache.jdbc.table.name"
value="jcrlocks_db1_ws" />
- <property name="jbosscache-cl-cache.jdbc.table.create"
value="true" />
- <property name="jbosscache-cl-cache.jdbc.table.drop"
value="false" />
- <property name="jbosscache-cl-cache.jdbc.table.primarykey"
value="jcrlocks_db1_ws_pk" />
- <property name="jbosscache-cl-cache.jdbc.fqn.column"
value="fqn" />
- <property name="jbosscache-cl-cache.jdbc.node.column"
value="node" />
- <property name="jbosscache-cl-cache.jdbc.parent.column"
value="parent" />
- <property name="jbosscache-cl-cache.jdbc.datasource"
value="jdbcjcr" />
- </properties>
-</lock-manager>
-
-</programlisting>
- <para>
- First few properties are the same as in the previous components, but here you can
see some strange "jbosscache-cl-cache.jdbc.*" properties. They define access
parameters for database where lock are persisted.
- </para>
- <itemizedlist>
- <listitem>
- <para>
- "jbosscache-cl-cache.jdbc.table.create" - whether to create it or not.
Usually "true";
- </para>
-
- </listitem>
- <listitem>
- <para>
- "jbosscache-cl-cache.jdbc.table.drop" - whether to drop on a start or
not. Use "false";
- </para>
-
- </listitem>
- <listitem>
- <para>
- "jbosscache-cl-cache.jdbc.table.primarykey" - the name of column with
pk;
- </para>
-
- </listitem>
- <listitem>
- <para>
- "jbosscache-cl-cache.jdbc.fqn.column" - the name of one more column.
If you are not sure how to use, follow the example above (if much interested, please refer
to JBossCache JDBCCacheLoader documentation)
- </para>
-
- </listitem>
- <listitem>
- <para>
- "jbosscache-cl-cache.jdbc.node.column" - the name of one more column.
If you are not sure how to use, follow the example above (if much interested, please refer
to JBossCache JDBCCacheLoader documentation)
- </para>
-
- </listitem>
- <listitem>
- <para>
- "jbosscache-cl-cache.jdbc.parent.column" - name of one more column. If
you are not sure how to use, follow the example above if you are not sure (if much
interested, please refer to JBossCache JDBCCacheLoader documentation)
- </para>
-
- </listitem>
- <listitem>
- <para>
- "jbosscache-cl-cache.jdbc.datasource" - name of configured in
Container datasource, where you want to store locks. The best idea is to use the same as
for workspace.
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </listitem>
-
- </itemizedlist>
- <para>
- That's all. JCR is ready for running in a cluster.
- </para>
-
- </section>
-
- <section
id="sect-Reference_Guide-JCR_core-Is_JCR_suitable_for_remote_sites_synchronization">
- <title>Is JCR suitable for remote sites\* synchronization?</title>
- <itemizedlist>
- <listitem>
- <para>
- Remote sites can be visualized as different buildings seperated by a WAN network.
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </section>
-
- <section
id="sect-Reference_Guide-JCR_core-How_to_use_lucene_spellchecker">
- <title>How to use lucene spellchecker?</title>
- <para>
- There is few steps:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Enable lucene spellchecker in jcr QueryHandler configuration:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_core-How_to_use_lucene_spellchecker">
+ <title>How to use lucene spellchecker?</title>
+ <para>
+ There is few steps:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Enable lucene spellchecker in jcr QueryHandler
configuration:
+ </para>
+
<programlisting language="XML" role="XML"><query-handler
class="org.exoplatform.services.jcr.impl.core.query.lucene.SearchIndex">
<properties>
...
@@ -465,56 +249,56 @@
</properties>
</query-handler></programlisting>
- </listitem>
+ </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- Execute query with rep:spellcheck function and word that is checked:
- </para>
-
+ </itemizedlist>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Execute query with rep:spellcheck function and word that is
checked:
+ </para>
+
<programlisting language="Java" role="Java">Query query =
qm.createQuery("select rep:spellcheck() from nt:base where " + "jcr:path =
'/' and spellcheck('word that is checked')", Query.SQL);
RowIterator rows = query.execute().getRows();</programlisting>
- </listitem>
+ </listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem>
- <para>
- Fetch a result:
- </para>
-
+ </itemizedlist>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Fetch a result:
+ </para>
+
<programlisting language="Java" role="Java">Row r =
rows.nextRow();
Value v = r.getValue("rep:spellcheck()");</programlisting>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- If there is no any results, that means there is no suggestion, so word is correct or
spellcheckers dictionary do not contain any words like the checked word.
- </para>
+ </itemizedlist>
+ <para>
+ If there is no any results, that means there is no suggestion, so
word is correct or spellcheckers dictionary do not contain any words like the checked
word.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_core-How_can_I_affect_to_spellchecker_results">
- <title>How can I affect to spellchecker results?</title>
- <para>
- There is two parameters in jcr QueryHandler configuration:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Minimal distance between checked word and proposed suggestion;
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_core-How_can_I_affect_to_spellchecker_results">
+ <title>How can I affect to spellchecker results?</title>
+ <para>
+ There is two parameters in jcr QueryHandler configuration:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Minimal distance between checked word and proposed
suggestion;
+ </para>
- </listitem>
- <listitem>
- <para>
- Search for more popular suggestions;
- </para>
-
+ </listitem>
+ <listitem>
+ <para>
+ Search for more popular suggestions;
+ </para>
+
<programlisting language="XML" role="XML"><query-handler
class="org.exoplatform.services.jcr.impl.core.query.lucene.SearchIndex">
<properties>
...
@@ -525,134 +309,134 @@
</properties>
</query-handler></programlisting>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- Minimal distance is counted as Levenshtein distance between checked word and
spellchecker suggestion.
- </para>
- <para>
- MorePopular paramter affects in next way: If "morePopular" disabled:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- If the proposed word exists in the directory - no suggestion given;
- </para>
+ </itemizedlist>
+ <para>
+ Minimal distance is counted as Levenshtein distance between checked
word and spellchecker suggestion.
+ </para>
+ <para>
+ MorePopular paramter affects in next way: If "morePopular"
disabled:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ If the proposed word exists in the directory - no suggestion
given;
+ </para>
- </listitem>
- <listitem>
- <para>
- If the proposed word doesn't exist in the directory - propose the closed
word;
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ If the proposed word doesn't exist in the directory -
propose the closed word;
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- If "morePopular" enabled:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- No matter word exists or not, checker will propose the closed word that is more
popular than the checked word.
- </para>
+ </itemizedlist>
+ <para>
+ If "morePopular" enabled:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ No matter word exists or not, checker will propose the closed
word that is more popular than the checked word.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
- </section>
-
+ </section>
+
- </section>
-
- <section id="sect-Reference_Guide-JCR-JCR_extensions">
- <title>JCR extensions</title>
- <section
id="sect-Reference_Guide-JCR_extensions-How_to_restore_repository_to_existing_repository_">
- <title>How to restore repository to existing repository ?</title>
- <orderedlist>
- <listitem>
- <para>
- Remove existing repository, use:
- </para>
-
+ </section>
+
+ <section id="sect-Reference_Guide-JCR-JCR_extensions">
+ <title>JCR extensions</title>
+ <section
id="sect-Reference_Guide-JCR_extensions-How_to_restore_repository_to_existing_repository_">
+ <title>How to restore repository to existing repository
?</title>
+ <orderedlist>
+ <listitem>
+ <para>
+ Remove existing repository, use:
+ </para>
+
<programlisting language="Java"
role="Java">RepositoryService.removeRepository(String
repositoryName)</programlisting>
- </listitem>
- <listitem>
- <para>
- Restore repository, use
- </para>
-
+ </listitem>
+ <listitem>
+ <para>
+ Restore repository, use
+ </para>
+
<programlisting language="Java"
role="Java">BackupManager.restore(RepositoryBackupChainLog log,
RepositoryEntry repositoryEntry, boolean asynchronous)</programlisting>
- </listitem>
+ </listitem>
- </orderedlist>
+ </orderedlist>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_extensions-How_to_restore_workspace_to_existing_worksapce">
- <title>How to restore workspace to existing worksapce?</title>
- <orderedlist>
- <listitem>
- <para>
- Remove existing workspace, use:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_extensions-How_to_restore_workspace_to_existing_worksapce">
+ <title>How to restore workspace to existing
worksapce?</title>
+ <orderedlist>
+ <listitem>
+ <para>
+ Remove existing workspace, use:
+ </para>
+
<programlisting language="Java"
role="Java">ManageableRepository.removeWorkspace(String
workspaceName)</programlisting>
- </listitem>
- <listitem>
- <para>
- Restore workspace, use:
- </para>
-
+ </listitem>
+ <listitem>
+ <para>
+ Restore workspace, use:
+ </para>
+
<programlisting language="Java"
role="Java">BackupManager.restore(BackupChainLog log, String repositoryName,
WorkspaceEntry workspaceEntry, boolean asynchronous)</programlisting>
- </listitem>
+ </listitem>
- </orderedlist>
+ </orderedlist>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_extensions-Does_JCR_support_hot_backup">
- <title>Does JCR support hot backup?</title>
- <para>
- Yes, JCR is support hot backup. Will use
org.exoplatform.services.jcr.ext.backup.BackupManager.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_extensions-Does_JCR_support_hot_backup">
+ <title>Does JCR support hot backup?</title>
+ <para>
+ Yes, JCR is support hot backup. Will use
org.exoplatform.services.jcr.ext.backup.BackupManager.
+ </para>
- </section>
-
+ </section>
+
- </section>
-
- <section id="sect-Reference_Guide-JCR-WebDAV">
- <title>WebDAV</title>
- <section
id="sect-Reference_Guide-WebDAV-I_uploaded_a_file_to_WebDAV_server_using_Mac_OS_Finder_but_the_file_size_is_0_what_is_wrong_">
- <title>I uploaded a file to WebDAV server using Mac OS Finder, but the file
size is '0', what is wrong ?</title>
- <para>
- This is known as a finder bug started from Mac OS v.10.5.3 and not yet fixed, .
- </para>
- <para>
- For more details follow:&nbsp; <ulink
url="http://discussions.apple.com/thread.jspa?threadID=1538882&a...
Disscussion thread.</ulink>
- </para>
+ </section>
+
+ <section id="sect-Reference_Guide-JCR-WebDAV">
+ <title>WebDAV</title>
+ <section
id="sect-Reference_Guide-WebDAV-I_uploaded_a_file_to_WebDAV_server_using_Mac_OS_Finder_but_the_file_size_is_0_what_is_wrong_">
+ <title>I uploaded a file to WebDAV server using Mac OS Finder, but
the file size is '0', what is wrong ?</title>
+ <para>
+ This is known as a finder bug started from Mac OS v.10.5.3 and not
yet fixed, .
+ </para>
+ <para>
+ For more details follow:&nbsp; <ulink
url="http://discussions.apple.com/thread.jspa?threadID=1538882&a...
Disscussion thread.</ulink>
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-WebDAV-Can_I_manage_cache_control_value_for_different_media_types_from_server_configuration_">
- <title>Can I manage 'cache-control' value for different media-types
from server configuration ?</title>
- <para>
- Use "cache-control" configuration parameter.
- </para>
- <para>
- The value of this parameter must contain colon-separated pairs
"MediaType:cache-control value"
- </para>
- <para>
- For example, if you need to cache all text/xml and text/plain files for 5 minutes
(300 sec.) and other text/\* files for 10 minutes (600 sec.), use the next configuration:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-WebDAV-Can_I_manage_cache_control_value_for_different_media_types_from_server_configuration_">
+ <title>Can I manage 'cache-control' value for different
media-types from server configuration ?</title>
+ <para>
+ Use "cache-control" configuration parameter.
+ </para>
+ <para>
+ The value of this parameter must contain colon-separated pairs
"MediaType:cache-control value"
+ </para>
+ <para>
+ For example, if you need to cache all text/xml and text/plain files
for 5 minutes (300 sec.) and other text/\* files for 10 minutes (600 sec.), use the next
configuration:
+ </para>
+
<programlisting language="XML"
role="XML"><component>
<type>org.exoplatform.services.jcr.webdav.WebDavServiceImpl</type>
<init-params>
@@ -664,79 +448,79 @@
<component>
</programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-WebDAV-How_to_perform_WebDAV_requests_using_curl_">
- <title>How to perform WebDAV requests using curl ?</title>
- <para>
- Simple Requests
- </para>
- <para>
- For simple request such as: GET, HEAD, MKCOL, COPY, MOVE, DELETE, CHECKIN, CHECKOUT,
UNCHECKOUT, LOCK, UNLOCK, VERSIONCONTROL, OPTIONS
- </para>
- <para>
- perform:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-WebDAV-How_to_perform_WebDAV_requests_using_curl_">
+ <title>How to perform WebDAV requests using curl ?</title>
+ <para>
+ Simple Requests
+ </para>
+ <para>
+ For simple request such as: GET, HEAD, MKCOL, COPY, MOVE, DELETE,
CHECKIN, CHECKOUT, UNCHECKOUT, LOCK, UNLOCK, VERSIONCONTROL, OPTIONS
+ </para>
+ <para>
+ perform:
+ </para>
+
<programlisting>curl -i -u 'user:pass' -X 'METHOD_NAME'
'resource_url'</programlisting>
- <para>
- for example to create a folder named test perform:
- </para>
-
+ <para>
+ for example to create a folder named test perform:
+ </para>
+
<programlisting>curl -i -u 'root:exo' -X MKCOL
'http://localhost:8080/rest/jcr/repository/production/test</programlisting>
- <para>
- to PUT a test.txt file from your current folder to "test "folder on server
perform:
- </para>
-
+ <para>
+ to PUT a test.txt file from your current folder to "test
"folder on server perform:
+ </para>
+
<programlisting>curl -i -u 'root:exo' -X PUT
'http://localhost:8080/rest/jcr/repository/production/test/test.txt' -d
@test.txt</programlisting>
- <para>
- Requests with XML body
- </para>
- <para>
- For requests which contains xml body such as: ORDER, PROPFIND, PROPPATCH, REPORT,
SEARCH
- </para>
- <para>
- add <emphasis role="bold">-d 'xml_body
text'</emphasis> or <emphasis role="bold">-d
@body.xml</emphasis>
- </para>
- <para>
- (body.xml must contain a valid xml request bidy.) to you curl-command:
- </para>
-
+ <para>
+ Requests with XML body
+ </para>
+ <para>
+ For requests which contains xml body such as: ORDER, PROPFIND,
PROPPATCH, REPORT, SEARCH
+ </para>
+ <para>
+ add <emphasis role="bold">-d 'xml_body
text'</emphasis> or <emphasis role="bold">-d
@body.xml</emphasis>
+ </para>
+ <para>
+ (body.xml must contain a valid xml request bidy.) to you
curl-command:
+ </para>
+
<programlisting>curl -i -u 'user:pass' -X 'METHOD_NAME' -H
'Headers' 'resource_url' -d 'xml_body
text'</programlisting>
- <para>
- For example about finding all files containing "test" perform:
- </para>
-
+ <para>
+ For example about finding all files containing "test"
perform:
+ </para>
+
<programlisting>curl -i -u "root:exo" -X "SEARCH"
"http://192.168.0.7:8080/rest/jcr/repository/production/" -d
"<?xml version='1.0' encoding='UTF-8' ?>
<D:searchrequest xmlns:D='DAV:'>
<D:sql>SELECT * FROM nt:base WHERE contains(*,
'text')</D:sql>
</D:searchrequest>"</programlisting>
- <para>
- If you need to add some headers to your request, use \-H key.
- </para>
- <para>
- To have more information about methods parameters, you can find in <ulink
url="http://www.ietf.org/rfc/rfc2518.txt">HTTP Extensions for Distributed
Authoring</ulink> specification.
- </para>
+ <para>
+ If you need to add some headers to your request, use \-H key.
+ </para>
+ <para>
+ To have more information about methods parameters, you can find in
<ulink
url="http://www.ietf.org/rfc/rfc2518.txt">HTTP Extensions for
Distributed Authoring</ulink> specification.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-WebDAV-How_eXo_JCR_WebDAV_server_treats_content_encoding">
- <title>How eXo JCR WebDAV server treats content encoding?</title>
- <para>
- OS client (Windows, Linux etc) doesn't set an encoding in a request. But eXo JCR
WebDAV server looks for an encoding in a Content-Type header and set it to jcr:encoding.
See <ulink
url="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html,"&g...
14.17 Content-Type. e.g. Content-Type: text/html; charset=ISO-8859-4 So, if a client will
set Content-Type header, e.g. JS code from a page, it will works for a text file as
expected.
- </para>
- <para>
- If WebDAV request doesn't contain a content encoding, it's possible to write
a dedicated action in a customer application. The action will set jcr:encoding using its
own logic, e.g. based on IP or user preferences.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-WebDAV-How_eXo_JCR_WebDAV_server_treats_content_encoding">
+ <title>How eXo JCR WebDAV server treats content
encoding?</title>
+ <para>
+ OS client (Windows, Linux etc) doesn't set an encoding in a
request. But eXo JCR WebDAV server looks for an encoding in a Content-Type header and set
it to jcr:encoding. See <ulink
url="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html,"&g...
14.17 Content-Type. e.g. Content-Type: text/html; charset=ISO-8859-4 So, if a client will
set Content-Type header, e.g. JS code from a page, it will works for a text file as
expected.
+ </para>
+ <para>
+ If WebDAV request doesn't contain a content encoding, it's
possible to write a dedicated action in a customer application. The action will set
jcr:encoding using its own logic, e.g. based on IP or user preferences.
+ </para>
- </section>
-
+ </section>
+
- </section>
-
+ </section>
+
- </section>
+ </section>
</section>
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/concepts/jcr-exo-implementation.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/concepts/jcr-exo-implementation.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/concepts/jcr-exo-implementation.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -4,67 +4,83 @@
%BOOK_ENTITIES;
]>
<section id="sect-Reference_Guide-Implementation">
- <!-- This document was created with Syntext Serna Free. -->
<title>Implementation</title>
+ <!-- This document was created with Syntext Serna Free. -->
+ <title>Implementation</title>
<section id="sect-Reference_Guide-Implementation-How_it_works">
<title>How it works</title>
<para>
- eXo Repository Service is a standard eXo service and is a registered IoC
component, i.e. can be deployed in some eXo Containers (see <xref
linkend="sect-Reference_Guide-JCR_configuration" /> for details). The
relationships between components are shown in the picture below:
+ The relationships between the eXo Repository Service components are shown in
the picture below:
</para>
<mediaobject>
<imageobject>
<imagedata fileref="images/eXoJCR/concepts/exojcr.gif"
/>
</imageobject>
-
</mediaobject>
+ <variablelist>
+ <title>Definitions</title>
+ <varlistentry>
+ <term>eXo Container:</term>
+ <listitem>
+ <para>
+ A subclasses of
<parameter>org.exoplatform.container.ExoContainer</parameter>
(<parameter>org.exoplatform.container.PortalContainer</parameter>) holds a
reference to the Repository Service.
+ </para>
+ <variablelist>
+ <title></title>
+ <varlistentry>
+ <term>Repository Service</term>
+ <listitem>
+ <para>
+ This contains information about repositories.
eXo JCR is able to manage many Repositories.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Repository:</term>
+ <listitem>
+ <para>
+ An implementation of
<literal>javax.jcr.Repository</literal>. It holds references to one or more
Workspace(s).
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Workspace:</term>
+ <listitem>
+ <para>
+ Container of a single rooted tree of Items.
+ </para>
+ <note>
+ <title>Note:</title>
+ <para>
+ That here it is not exactly the same
as <literal>javax.jcr.Workspace</literal> as it is not a per Session object.
+ </para>
+ </note>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </listitem>
+ </varlistentry>
+ </variablelist>
<para>
- <keycap>eXo Container: </keycap>some subclasses of
org.exoplatform.container.ExoContainer (usually
org.exoplatform.container.StandaloneContainer or
org.exoplatform.container.PortalContainer) that holds a reference to Repository Service.
+ The usual JCR application usecase includes two initial steps:
</para>
- <itemizedlist>
- <listitem>
+ <procedure>
+ <step>
<para>
- <emphasis role="bold">Repository
Service:</emphasis> contains information about repositories. eXo JCR is able to
manage many Repositories.
+ Obtaining Repository object by getting <emphasis
role="bold">Repository Service</emphasis> via JNDI lookup if eXo
repository is bound to the naming context using (see <xref
linkend="sect-Reference_Guide-JCR_configuration" /> for details).
</para>
-
- </listitem>
- <listitem>
+ </step>
+ <step>
<para>
- <emphasis role="bold">Repository:</emphasis>
Implementation of javax.jcr.Repository. It holds references to one or more Workspace(s).
+ Creating a <parameter>javax.jcr.Session
object</parameter> that calls
<parameter>Repository.login(..)</parameter>.
</para>
-
- </listitem>
- <listitem>
- <para>
- <keycap>Workspace:</keycap> Container of a single rooted
tree of Items. (Note that here it is not exactly the same as javax.jcr.Workspace as it is
not a per Session object).
- </para>
-
- </listitem>
-
- </itemizedlist>
- <para>
- Usual JCR application use case includes two initial steps:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Obtaining Repository object by getting <emphasis
role="bold">Repository Service</emphasis> from the current eXo
Container (eXo "native" way) or via JNDI lookup if eXo repository is bound to
the naming context using (see <xref
linkend="sect-Reference_Guide-JCR_configuration" /> for details).
- </para>
-
- </listitem>
- <listitem>
- <para>
- Creating javax.jcr.Session object that calls Repository.login(..).
- </para>
-
- </listitem>
-
- </itemizedlist>
-
+ </step>
+ </procedure>
</section>
<section
id="sect-Reference_Guide-Implementation-Workspace_Data_Model">
<title>Workspace Data Model</title>
<para>
- The following diagram explains which components of eXo JCR implementation are
used in a data flow to perform operations specified in JCR API
+ The following diagram explains which components of a eXo JCR implementation
are used in a data flow to perform operations specified in the JCR API.
</para>
<mediaobject>
<imageobject>
@@ -73,7 +89,7 @@
</mediaobject>
<para>
- The Workspace Data Model can be split into 4 levels by data isolation and
value from the JCR model point of view.
+ The Workspace Data Model can be split into four levels by data isolation and
value from the JCR model point of view.
</para>
<itemizedlist>
<listitem>
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/configuration/configuration-persister.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/configuration/configuration-persister.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/configuration/configuration-persister.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -4,13 +4,12 @@
%BOOK_ENTITIES;
]>
<section id="sect-Reference_Guide-JCR_Configuration_persister">
- <title>JCR Configuration persister</title>
- <section id="sect-Reference_Guide-JCR_Configuration_persister-Idea">
- <title>Idea</title>
- <para>
- JCR Repository Service uses
<classname>org.exoplatform.services.jcr.config.RepositoryServiceConfiguration</classname>
component to read its configuration.
- </para>
-
+ <title>JCR Configuration persister</title>
+ <section
id="sect-Reference_Guide-JCR_Configuration_persister-Idea">
+ <title>Idea</title>
+ <para>
+ JCR Repository Service uses
<classname>org.exoplatform.services.jcr.config.RepositoryServiceConfiguration</classname>
component to read its configuration.
+ </para>
<programlisting language="XML"
role="XML"><component>
<key>org.exoplatform.services.jcr.config.RepositoryServiceConfiguration</key>
<type>org.exoplatform.services.jcr.impl.config.RepositoryServiceConfigurationImpl</type>
@@ -18,31 +17,30 @@
<value-param>
<name>conf-path</name>
<description>JCR configuration file</description>
- <value>/conf/standalone/exo-jcr-config.xml</value>
+
<value>war:/conf/jcr/repository-configuration.xml</value>
</value-param>
</init-params>
</component></programlisting>
- <para>
- In the example, Repository Service will read the configuration from the file
<filename>/conf/standalone/exo-jcr-config.xml</filename>.
- </para>
- <para>
- But in some cases, it's required to change the configuration on the fly. And know
that the new one will be used. Additionally we wish not to modify the original file.
- </para>
- <para>
- In this case, we have to use the configuration persister feature which allows to store
the configuration in different locations.
- </para>
+ <para>
+ In the example, Repository Service will read the configuration from the file
<filename>war:/conf/jcr/repository-configuration.xml</filename>.
+ </para>
+ <para>
+ But in some cases, it's required to change the configuration on the fly.
And know that the new one will be used. Additionally we wish not to modify the original
file.
+ </para>
+ <para>
+ In this case, we have to use the configuration persister feature which allows
to store the configuration in different locations.
+ </para>
- </section>
-
- <section id="sect-Reference_Guide-JCR_Configuration_persister-Usage">
- <title>Usage</title>
- <para>
- On startup <classname>RepositoryServiceConfiguration</classname> component
checks if a configuration persister was configured. In that case, it uses the provided
<classname>ConfigurationPersister</classname> implementation class to
instantiate the persister object.
- </para>
- <para>
- Configuration with persister:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_Configuration_persister-Usage">
+ <title>Usage</title>
+ <para>
+ On startup <classname>RepositoryServiceConfiguration</classname>
component checks if a configuration persister was configured. In that case, it uses the
provided <classname>ConfigurationPersister</classname> implementation class to
instantiate the persister object.
+ </para>
+ <para>
+ Configuration with persister:
+ </para>
<programlisting language="XML"
role="XML"><component>
<key>org.exoplatform.services.jcr.config.RepositoryServiceConfiguration</key>
<type>org.exoplatform.services.jcr.impl.config.RepositoryServiceConfigurationImpl</type>
@@ -50,7 +48,7 @@
<value-param>
<name>conf-path</name>
<description>JCR configuration file</description>
- <value>/conf/standalone/exo-jcr-config.xml</value>
+
<value>war:/conf/jcr/repository-configuration.xml</value>
</value-param>
<properties-param>
<name>working-conf</name>
@@ -62,34 +60,34 @@
</init-params>
</component>
</programlisting>
- <para>
- Where:
- <itemizedlist>
- <listitem>
- <para>
- <parameter>source-name</parameter>: JNDI source name configured in
<classname>InitialContextInitializer</classname> component.
(<parameter>sourceName</parameter> prior v.1.9.) Find more in <xref
linkend="sect-Reference_Guide-JDBC_Data_Container_Config" />.
- </para>
+ <para>
+ Where:
+ <itemizedlist>
+ <listitem>
+ <para>
+ <parameter>source-name</parameter>: JNDI source name
configured in <classname>InitialContextInitializer</classname> component.
(<parameter>sourceName</parameter> prior v.1.9.) Find more in <xref
linkend="sect-Reference_Guide-JDBC_Data_Container_Config" />.
+ </para>
- </listitem>
- <listitem>
- <para>
- <parameter>dialect</parameter>: SQL dialect which will be used with
database from <parameter>source-name</parameter>. Find more in <xref
linkend="sect-Reference_Guide-JDBC_Data_Container_Config" />.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <parameter>dialect</parameter>: SQL dialect which
will be used with database from <parameter>source-name</parameter>. Find more
in <xref linkend="sect-Reference_Guide-JDBC_Data_Container_Config" />.
+ </para>
- </listitem>
- <listitem>
- <para>
- <parameter>persister-class-name</parameter> - class name of
<classname>ConfigurationPersister</classname> interface implementation.
(<parameter>persisterClassName</parameter> prior v.1.9.)
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <parameter>persister-class-name</parameter> - class
name of <classname>ConfigurationPersister</classname> interface
implementation. (<parameter>persisterClassName</parameter> prior v.1.9.)
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- </para>
- <para>
- ConfigurationPersister interface:
- </para>
-
+ </itemizedlist>
+ </para>
+ <para>
+ ConfigurationPersister interface:
+ </para>
+
<programlisting language="Java" role="Java">/**
* Init persister.
* Used by RepositoryServiceConfiguration on init.
@@ -115,17 +113,17 @@
*/
boolean hasConfig() throws RepositoryConfigurationException;
</programlisting>
- <para>
- JCR Core implementation contains a persister which stores the repository configuration
in the relational database using JDBC calls -
<classname>org.exoplatform.services.jcr.impl.config.JDBCConfigurationPersister</classname>.
- </para>
- <para>
- The implementation will crate and use table JCR_CONFIG in the provided database.
- </para>
- <para>
- But the developer can implement his own persister for his particular usecase.
- </para>
+ <para>
+ JCR Core implementation contains a persister which stores the repository
configuration in the relational database using JDBC calls -
<classname>org.exoplatform.services.jcr.impl.config.JDBCConfigurationPersister</classname>.
+ </para>
+ <para>
+ The implementation will crate and use table JCR_CONFIG in the provided
database.
+ </para>
+ <para>
+ But the developer can implement his own persister for his particular
usecase.
+ </para>
- </section>
+ </section>
</section>
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/configuration/jdbc-data-container-config.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/configuration/jdbc-data-container-config.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/configuration/jdbc-data-container-config.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -4,308 +4,289 @@
%BOOK_ENTITIES;
]>
<section id="sect-Reference_Guide-JDBC_Data_Container_Config">
- <title>JDBC Data Container Config</title>
- <section
id="sect-Reference_Guide-JDBC_Data_Container_Config-Introduction">
- <title>Introduction</title>
- <para>
- eXo JCR persistent data container can work in two configuration modes:
- <itemizedlist>
- <listitem>
- <para>
- <phrase>Multi-database</phrase>: One database for each workspace (used
in standalone eXo JCR service mode)
- </para>
+ <title>JDBC Data Container Config</title>
+ <section
id="sect-Reference_Guide-JDBC_Data_Container_Config-Introduction">
+ <title>Introduction</title>
+ <para>
+ The data container uses the JDBC driver to communicate with the actual
database software, i.e. any JDBC-enabled data storage can be used with eXo JCR
implementation.
+ </para>
+ <para>
+ Currently the data container is tested with the following RDBMS:
+ <itemizedlist>
+ <listitem>
+ <para>
+ MySQL 5.1 MYSQL Connector/J 5.1.8
+ </para>
- </listitem>
- <listitem>
- <para>
- <phrase>Single-database</phrase>: All workspaces persisted in one
database (used in embedded eXo JCR service mode, e.g. in eXo portal)
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ PostgresSQL 8.3.7 JDBC4 Driver, Version 8.3-605
+ </para>
- </listitem>
+ </listitem>
+ <listitem>
+ <para>
+ Oracle DB 11g (11.0.1.6), JDBC Driver Oracle 11g R1 (11.1.0.6.0)
+ </para>
- </itemizedlist>
- </para>
- <para>
- The data container uses the JDBC driver to communicate with the actual database
software, i.e. any JDBC-enabled data storage can be used with eXo JCR implementation.
- </para>
- <para>
- Currently the data container is tested with the following RDBMS:
- <itemizedlist>
- <listitem>
- <para>
- MySQL 5.1 MYSQL Connector/J 5.1.8
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ DB2 9,7 IBM Data Server Driver for JDBC and SQLJ (JCC Driver)
v.9.1 (fixpack 3a)
+ </para>
- </listitem>
- <listitem>
- <para>
- PostgresSQL 8.3.7 JDBC4 Driver, Version 8.3-605
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ MS SQL Server 2005 SP3 JDBC Driver 2.0
+ </para>
- </listitem>
- <listitem>
- <para>
- Oracle DB 11g (11.0.1.6), JDBC Driver Oracle 11g R1 (11.1.0.6.0)
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Sybase 15.0.3 Driver: Sybase jConnect JDBC driver v7 (Build
26502)
+ </para>
- </listitem>
- <listitem>
- <para>
- DB2 9,7 IBM Data Server Driver for JDBC and SQLJ (JCC Driver) v.9.1 (fixpack 3a)
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ HSQLDB (2.0.0)
+ </para>
- </listitem>
- <listitem>
- <para>
- MS SQL Server 2005 SP3 JDBC Driver 2.0
- </para>
+ </listitem>
- </listitem>
- <listitem>
- <para>
- Sybase 15.0.3 Driver: Sybase jConnect JDBC driver v7 (Build 26502)
- </para>
+ </itemizedlist>
+ </para>
+ <para>
+ <note>
+ <para>
+ Please note, that JCR requires at least READ_COMMITED isolation level
and other RDBMS configurations can cause some side-effects and issues. So, please, make
sure proper isolation level is configured on database server side.
+ </para>
- </listitem>
- <listitem>
- <para>
- HSQLDB (2.0.0)
- </para>
+ </note>
+ Each database software supports ANSI SQL standards but also has its own
specifics. So, each database has its own configuration in eXo JCR as a database dialect
parameter. If you need a more detailed configuration of the database, it's possible to
do that by editing the metadata SQL-script files.
+ </para>
+ <para>
+ SQL-scripts you can obtain from jar-file
exo.jcr.component.core-XXX.XXX.jar:conf/storage/. They also can be found at SVN <ulink
url="https://anonsvn.jboss.org/repos/exo-jcr/jcr/trunk/exo.jcr.compo...
+ </para>
+ <para>
+ In the next two tables correspondence between the scripts and databases is
shown.
+ </para>
+ <table id="tabl-Reference_Guide-Introduction-Single_database">
+ <title>Single-database</title>
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>
+ Database
+ </entry>
+ <entry>
+ Script
+ </entry>
- </listitem>
+ </row>
- </itemizedlist>
- </para>
- <para>
- <note>
- <para>
- Please note, that JCR requires at least READ_COMMITED isolation level and other
RDBMS configurations can cause some side-effects and issues. So, please, make sure proper
isolation level is configured on database server side.
- </para>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+ MySQL DB
+ </entry>
+ <entry>
+ jcr-sjdbc.mysql.sql
+ </entry>
- </note>
- Each database software supports ANSI SQL standards but also has its own specifics. So,
each database has its own configuration in eXo JCR as a database dialect parameter. If you
need a more detailed configuration of the database, it's possible to do that by
editing the metadata SQL-script files.
- </para>
- <para>
- SQL-scripts you can obtain from jar-file
exo.jcr.component.core-XXX.XXX.jar:conf/storage/. They also can be found at SVN <ulink
url="https://anonsvn.jboss.org/repos/exo-jcr/jcr/trunk/exo.jcr.compo...
- </para>
- <para>
- In the next two tables correspondence between the scripts and databases is shown.
- </para>
- <table id="tabl-Reference_Guide-Introduction-Single_database">
- <title>Single-database</title>
- <tgroup cols="2">
- <thead>
- <row>
- <entry>
- Database
- </entry>
- <entry>
- Script
- </entry>
+ </row>
+ <row>
+ <entry>
+ MySQL DB with utf-8
+ </entry>
+ <entry>
+ jcr-sjdbc.mysql-utf8.sql
+ </entry>
- </row>
+ </row>
+ <row>
+ <entry>
+ PostgresSQL
+ </entry>
+ <entry>
+ jcr-sjdbc.pqsql.sql
+ </entry>
- </thead>
- <tbody>
- <row>
- <entry>
- MySQL DB
- </entry>
- <entry>
- jcr-sjdbc.mysql.sql
- </entry>
+ </row>
+ <row>
+ <entry>
+ Oracle DB
+ </entry>
+ <entry>
+ jcr-sjdbc.ora.sql
+ </entry>
- </row>
- <row>
- <entry>
- MySQL DB with utf-8
- </entry>
- <entry>
- jcr-sjdbc.mysql-utf8.sql
- </entry>
+ </row>
+ <row>
+ <entry>
+ DB2 9.7
+ </entry>
+ <entry>
+ jcr-sjdbc.db2.sql
+ </entry>
- </row>
- <row>
- <entry>
- PostgresSQL
- </entry>
- <entry>
- jcr-sjdbc.pqsql.sql
- </entry>
+ </row>
+ <row>
+ <entry>
+ MS SQL Server
+ </entry>
+ <entry>
+ jcr-sjdbc.mssql.sql
+ </entry>
- </row>
- <row>
- <entry>
- Oracle DB
- </entry>
- <entry>
- jcr-sjdbc.ora.sql
- </entry>
+ </row>
+ <row>
+ <entry>
+ Sybase
+ </entry>
+ <entry>
+ jcr-sjdbc.sybase.sql
+ </entry>
- </row>
- <row>
- <entry>
- DB2 9.7
- </entry>
- <entry>
- jcr-sjdbc.db2.sql
- </entry>
+ </row>
+ <row>
+ <entry>
+ HSQLDB
+ </entry>
+ <entry>
+ jcr-sjdbc.sql
+ </entry>
- </row>
- <row>
- <entry>
- MS SQL Server
- </entry>
- <entry>
- jcr-sjdbc.mssql.sql
- </entry>
+ </row>
- </row>
- <row>
- <entry>
- Sybase
- </entry>
- <entry>
- jcr-sjdbc.sybase.sql
- </entry>
+ </tbody>
- </row>
- <row>
- <entry>
- HSQLDB
- </entry>
- <entry>
- jcr-sjdbc.sql
- </entry>
+ </tgroup>
- </row>
+ </table>
+ <table id="tabl-Reference_Guide-Introduction-Multi_database">
+ <title>Multi-database</title>
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>
+ Database
+ </entry>
+ <entry>
+ Script
+ </entry>
- </tbody>
+ </row>
- </tgroup>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+ MySQL DB
+ </entry>
+ <entry>
+ jcr-mjdbc.mysql.sql
+ </entry>
- </table>
- <table id="tabl-Reference_Guide-Introduction-Multi_database">
- <title>Multi-database</title>
- <tgroup cols="2">
- <thead>
- <row>
- <entry>
- Database
- </entry>
- <entry>
- Script
- </entry>
+ </row>
+ <row>
+ <entry>
+ MySQL DB with utf-8
+ </entry>
+ <entry>
+ jcr-mjdbc.mysql-utf8.sql
+ </entry>
- </row>
+ </row>
+ <row>
+ <entry>
+ PostgresSQL
+ </entry>
+ <entry>
+ jcr-mjdbc.pqsql.sql
+ </entry>
- </thead>
- <tbody>
- <row>
- <entry>
- MySQL DB
- </entry>
- <entry>
- jcr-mjdbc.mysql.sql
- </entry>
+ </row>
+ <row>
+ <entry>
+ Oracle DB
+ </entry>
+ <entry>
+ jcr-mjdbc.ora.sql
+ </entry>
- </row>
- <row>
- <entry>
- MySQL DB with utf-8
- </entry>
- <entry>
- jcr-mjdbc.mysql-utf8.sql
- </entry>
+ </row>
+ <row>
+ <entry>
+ DB2 9.7
+ </entry>
+ <entry>
+ jcr-mjdbc.db2.sql
+ </entry>
- </row>
- <row>
- <entry>
- PostgresSQL
- </entry>
- <entry>
- jcr-mjdbc.pqsql.sql
- </entry>
+ </row>
+ <row>
+ <entry>
+ MS SQL Server
+ </entry>
+ <entry>
+ jcr-mjdbc.mssql.sql
+ </entry>
- </row>
- <row>
- <entry>
- Oracle DB
- </entry>
- <entry>
- jcr-mjdbc.ora.sql
- </entry>
+ </row>
+ <row>
+ <entry>
+ Sybase
+ </entry>
+ <entry>
+ jcr-mjdbc.sybase.sql
+ </entry>
- </row>
- <row>
- <entry>
- DB2 9.7
- </entry>
- <entry>
- jcr-mjdbc.db2.sql
- </entry>
+ </row>
+ <row>
+ <entry>
+ HSQLDB
+ </entry>
+ <entry>
+ jcr-mjdbc.sql
+ </entry>
- </row>
- <row>
- <entry>
- MS SQL Server
- </entry>
- <entry>
- jcr-mjdbc.mssql.sql
- </entry>
+ </row>
- </row>
- <row>
- <entry>
- Sybase
- </entry>
- <entry>
- jcr-mjdbc.sybase.sql
- </entry>
+ </tbody>
- </row>
- <row>
- <entry>
- HSQLDB
- </entry>
- <entry>
- jcr-mjdbc.sql
- </entry>
+ </tgroup>
- </row>
+ </table>
+ <para>
+ In case the non-ANSI node name is used, it's necessary to use a database
with MultiLanguage support[TODO link to MultiLanguage]. Some JDBC drivers need additional
parameters for establishing a Unicode friendly connection. E.g. under mysql it's
necessary to add an additional parameter for the JDBC driver at the end of JDBC URL. For
instance:
<
code>jdbc:mysql://exoua.dnsalias.net/portal?characterEncoding=utf8<...
+ </para>
+ <para>
+ There are preconfigured configuration files for HSQLDB. Look for these files
in the source-distribution of eXo JCR implementation.
+ </para>
+ <para>
+ By default, the configuration files are located in service jars
<filename>/conf/portal/configuration.xml</filename> (eXo services including
JCR Repository Service) and <filename>exo-jcr-config.xml</filename>
(repositories configuration). In eXo portal product, JCR is configured in portal web
application <filename>portal/WEB-INF/conf/jcr/jcr-configuration.xml</filename>
(JCR Repository Service and related serivces) and repository-configuration.xml
(repositories configuration).
+ </para>
+ <para>
+ Read more about <xref
linkend="sect-Reference_Guide-JCR_configuration" />.
+ </para>
- </tbody>
-
- </tgroup>
-
- </table>
- <para>
- In case the non-ANSI node name is used, it's necessary to use a database with
MultiLanguage support[TODO link to MultiLanguage]. Some JDBC drivers need additional
parameters for establishing a Unicode friendly connection. E.g. under mysql it's
necessary to add an additional parameter for the JDBC driver at the end of JDBC URL. For
instance:
<
code>jdbc:mysql://exoua.dnsalias.net/portal?characterEncoding=utf8<...
- </para>
- <para>
- There are preconfigured configuration files for HSQLDB. Look for these files in
/conf/portal and /conf/standalone folders of the jar-file
<package>exo.jcr.component.core-XXX.XXX.jar</package> or source-distribution
of eXo JCR implementation.
- </para>
- <para>
- By default, the configuration files are located in service jars
<filename>/conf/portal/configuration.xml</filename> (eXo services including
JCR Repository Service) and <filename>exo-jcr-config.xml</filename>
(repositories configuration). In eXo portal product, JCR is configured in portal web
application <filename>portal/WEB-INF/conf/jcr/jcr-configuration.xml</filename>
(JCR Repository Service and related serivces) and repository-configuration.xml
(repositories configuration).
- </para>
- <para>
- Read more about <xref linkend="sect-Reference_Guide-JCR_configuration"
/>.
- </para>
-
- </section>
-
- <section
id="sect-Reference_Guide-JDBC_Data_Container_Config-Multi_database_Configuration">
- <title>Multi-database Configuration</title>
- <para>
- You need to configure each workspace in a repository. You may have each one on
different remote servers as far as you need.
- </para>
- <para>
- First of all configure the data containers in the
<classname>org.exoplatform.services.naming.InitialContextInitializer</classname>
service. It's the JNDI context initializer which registers (binds) naming resources
(DataSources) for data containers.
- </para>
- <para>
- For example (standalone mode, two data containers
<parameter>jdbcjcr</parameter> - local HSQLDB,
<parameter>jdbcjcr1</parameter> - remote MySQL):
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-JDBC_Data_Container_Config-Multi_database_Configuration">
+ <title>Multi-database Configuration</title>
+ <para>
+ You need to configure each workspace in a repository. You may have each one
on different remote servers as far as you need.
+ </para>
+ <para>
+ First of all configure the data containers in the
<classname>org.exoplatform.services.naming.InitialContextInitializer</classname>
service. It's the JNDI context initializer which registers (binds) naming resources
(DataSources) for data containers.
+ </para>
+ <para>
+ For example (two data containers <parameter>jdbcjcr</parameter> -
local HSQLDB, <parameter>jdbcjcr1</parameter> - remote MySQL):
+ </para>
<programlisting language="XML"
role="XML"><component>
<key>org.exoplatform.services.naming.InitialContextInitializer</key>
<type>org.exoplatform.services.naming.InitialContextInitializer</type>
@@ -376,73 +357,73 @@
</init-params>
</component>
</programlisting>
- <para>
- We configure the database connection parameters:
- <itemizedlist>
- <listitem>
- <para>
- <parameter>driverClassName</parameter>, e.g.
"org.hsqldb.jdbcDriver", "com.mysql.jdbc.Driver",
"org.postgresql.Driver"
- </para>
+ <para>
+ We configure the database connection parameters:
+ <itemizedlist>
+ <listitem>
+ <para>
+ <parameter>driverClassName</parameter>, e.g.
"org.hsqldb.jdbcDriver", "com.mysql.jdbc.Driver",
"org.postgresql.Driver"
+ </para>
- </listitem>
- <listitem>
- <para>
- <parameter>url</parameter>, e.g.
"jdbc:hsqldb:file:target/temp/data/portal",
"jdbc:mysql://exoua.dnsalias.net/jcr"
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <parameter>url</parameter>, e.g.
"jdbc:hsqldb:file:target/temp/data/portal",
"jdbc:mysql://exoua.dnsalias.net/jcr"
+ </para>
- </listitem>
- <listitem>
- <para>
- <parameter>username</parameter>, e.g. "sa",
"exoadmin"
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <parameter>username</parameter>, e.g. "sa",
"exoadmin"
+ </para>
- </listitem>
- <listitem>
- <para>
- <parameter>password</parameter>, e.g. "",
"exo12321"
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <parameter>password</parameter>, e.g. "",
"exo12321"
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- </para>
- <para>
- There can be connection pool configuration parameters
(org.apache.commons.dbcp.BasicDataSourceFactory):
- <itemizedlist>
- <listitem>
- <para>
- <parameter>maxActive</parameter>, e.g. 50
- </para>
+ </itemizedlist>
+ </para>
+ <para>
+ There can be connection pool configuration parameters
(org.apache.commons.dbcp.BasicDataSourceFactory):
+ <itemizedlist>
+ <listitem>
+ <para>
+ <parameter>maxActive</parameter>, e.g. 50
+ </para>
- </listitem>
- <listitem>
- <para>
- <parameter>maxIdle</parameter>, e.g. 5
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <parameter>maxIdle</parameter>, e.g. 5
+ </para>
- </listitem>
- <listitem>
- <para>
- <parameter>initialSize</parameter>, e.g. 5
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <parameter>initialSize</parameter>, e.g. 5
+ </para>
- </listitem>
- <listitem>
- <para>
- and other according to <ulink
url="http://jakarta.apache.org/commons/dbcp/configuration.html"... DBCP
configuration</ulink>
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ and other according to <ulink
url="http://jakarta.apache.org/commons/dbcp/configuration.html"... DBCP
configuration</ulink>
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- </para>
- <para>
- When the data container configuration is done, we can configure the repository
service. Each workspace will be configured for its own data container.
- </para>
- <para>
- For example (two workspaces <parameter>ws</parameter> - jdbcjcr,
<parameter>ws1</parameter> - jdbcjcr1):
- </para>
-
+ </itemizedlist>
+ </para>
+ <para>
+ When the data container configuration is done, we can configure the
repository service. Each workspace will be configured for its own data container.
+ </para>
+ <para>
+ For example (two workspaces <parameter>ws</parameter> - jdbcjcr,
<parameter>ws1</parameter> - jdbcjcr1):
+ </para>
+
<programlisting language="XML"
role="XML"><workspaces>
<workspace name="ws"
auto-init-root-nodetype="nt:unstructured">
<container
class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer">
@@ -506,60 +487,60 @@
</workspace>
</workspaces>
</programlisting>
- <itemizedlist>
- <listitem>
- <para>
- <parameter>source-name</parameter>: A javax.sql.DataSource name
configured in InitialContextInitializer component (was
<parameter>sourceName</parameter> prior JCR 1.9);
- </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <parameter>source-name</parameter>: A
javax.sql.DataSource name configured in InitialContextInitializer component (was
<parameter>sourceName</parameter> prior JCR 1.9);
+ </para>
- </listitem>
- <listitem>
- <para>
- <parameter>dialect</parameter>: A database dialect, one of
"hsqldb", "mysql", "mysql-utf8", "pgsql",
"oracle", "oracle-oci", "mssql", "sybase",
"derby", "db2", "db2v8" or "auto" for dialect
autodetection;
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <parameter>dialect</parameter>: A database dialect, one
of "hsqldb", "mysql", "mysql-utf8", "pgsql",
"oracle", "oracle-oci", "mssql", "sybase",
"derby", "db2", "db2v8" or "auto" for dialect
autodetection;
+ </para>
- </listitem>
- <listitem>
- <para>
- <parameter>multi-db</parameter>: Enable multi-database container with
this parameter (set value "true");
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <parameter>multi-db</parameter>: Enable multi-database
container with this parameter (set value "true");
+ </para>
- </listitem>
- <listitem>
- <para>
- <parameter>max-buffer-size: A</parameter> a threshold (in bytes) after
which a javax.jcr.Value content will be swapped to a file in a temporary storage. I.e.
swap for pending changes.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <parameter>max-buffer-size: A</parameter> a threshold (in
bytes) after which a javax.jcr.Value content will be swapped to a file in a temporary
storage. I.e. swap for pending changes.
+ </para>
- </listitem>
- <listitem>
- <para>
- <parameter>swap-directory</parameter>: A path in the file system used to
swap the pending changes.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <parameter>swap-directory</parameter>: A path in the file
system used to swap the pending changes.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- In this way, we have configured two workspace which will be persisted in two different
databases (ws in HSQLDB, ws1 in MySQL).
- </para>
- <note>
- <para>
- Starting from v.1.9 <xref
linkend="sect-Reference_Guide-JCR_configuration" /> parameters supports
human-readable formats of values (e.g. 200K - 200 Kbytes, 30m - 30 minutes etc)
- </para>
+ </itemizedlist>
+ <para>
+ In this way, we have configured two workspace which will be persisted in two
different databases (ws in HSQLDB, ws1 in MySQL).
+ </para>
+ <note>
+ <para>
+ Starting from v.1.9 <xref
linkend="sect-Reference_Guide-JCR_configuration" /> parameters supports
human-readable formats of values (e.g. 200K - 200 Kbytes, 30m - 30 minutes etc)
+ </para>
- </note>
+ </note>
- </section>
-
- <section
id="sect-Reference_Guide-JDBC_Data_Container_Config-Single_database_configuration">
- <title>Single-database configuration</title>
- <para>
- It's more simple to configure a single-database data container. We have to
configure one naming resource.
- </para>
- <para>
- For example (embedded mode for <parameter>jdbcjcr</parameter> data
container):
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-JDBC_Data_Container_Config-Single_database_configuration">
+ <title>Single-database configuration</title>
+ <para>
+ It's more simple to configure a single-database data container. We have
to configure one naming resource.
+ </para>
+ <para>
+ For example (embedded mode for <parameter>jdbcjcr</parameter>
data container):
+ </para>
+
<programlisting language="XML"
role="XML"><external-component-plugins>
<target-component>org.exoplatform.services.naming.InitialContextInitializer</target-component>
<component-plugin>
@@ -594,13 +575,13 @@
</component-plugin>
</external-component-plugins>
</programlisting>
- <para>
- And configure repository workspaces in repositories configuration with this one
database. Parameter "multi-db" must be switched off (set value
"false").
- </para>
- <para>
- For example (two workspaces <parameter>ws</parameter> - jdbcjcr,
<parameter>ws1</parameter> - jdbcjcr):
- </para>
-
+ <para>
+ And configure repository workspaces in repositories configuration with this
one database. Parameter "multi-db" must be switched off (set value
"false").
+ </para>
+ <para>
+ For example (two workspaces <parameter>ws</parameter> - jdbcjcr,
<parameter>ws1</parameter> - jdbcjcr):
+ </para>
+
<programlisting language="XML"
role="XML"><workspaces>
<workspace name="ws"
auto-init-root-nodetype="nt:unstructured">
<container
class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer">
@@ -659,39 +640,39 @@
</workspace>
</workspaces>
</programlisting>
- <para>
- In this way, we have configured two workspaces which will be persisted in one database
(PostgreSQL).
- </para>
- <section
id="sect-Reference_Guide-Single_database_configuration-Configuration_without_DataSource">
- <title>Configuration without DataSource</title>
- <para>
- Repository configuration without using of the
<classname>javax.sql.DataSource</classname> bounded in JNDI.
- </para>
- <para>
- This case may be usable if you have a dedicated JDBC driver implementation with
special features like XA transactions, statements/connections pooling etc:
- <itemizedlist>
- <listitem>
- <para>
- You have to remove the configuration in
<classname>InitialContextInitializer</classname> for your database and
configure a new one directly in the workspace container.
- </para>
+ <para>
+ In this way, we have configured two workspaces which will be persisted in one
database (PostgreSQL).
+ </para>
+ <section
id="sect-Reference_Guide-Single_database_configuration-Configuration_without_DataSource">
+ <title>Configuration without DataSource</title>
+ <para>
+ Repository configuration without using of the
<classname>javax.sql.DataSource</classname> bounded in JNDI.
+ </para>
+ <para>
+ This case may be usable if you have a dedicated JDBC driver
implementation with special features like XA transactions, statements/connections pooling
etc:
+ <itemizedlist>
+ <listitem>
+ <para>
+ You have to remove the configuration in
<classname>InitialContextInitializer</classname> for your database and
configure a new one directly in the workspace container.
+ </para>
- </listitem>
- <listitem>
- <para>
- Remove parameter "source-name" and add next lines instead. Describe your
values for a JDBC driver, database url and username.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Remove parameter "source-name" and add next lines
instead. Describe your values for a JDBC driver, database url and username.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- </para>
- <note>
- <para>
- But be careful in this case JDBC driver should implement and provide connection
pooling. Connection pooling is very recommended for use with JCR to prevent a database
overload.
- </para>
+ </itemizedlist>
+ </para>
+ <note>
+ <para>
+ But be careful in this case JDBC driver should implement and provide
connection pooling. Connection pooling is very recommended for use with JCR to prevent a
database overload.
+ </para>
- </note>
-
+ </note>
+
<programlisting language="XML" role="XML"><workspace
name="ws" auto-init-root-nodetype="nt:unstructured">
<container
class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer">
<properties>
@@ -702,46 +683,46 @@
<property name="password" value=""/>
......</programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-Single_database_configuration-Dynamic_Workspace_Creation">
- <title>Dynamic Workspace Creation</title>
- <para>
- Workspaces can be added dynamically during runtime.
- </para>
- <para>
- This can be performed in two steps:
- <itemizedlist>
- <listitem>
- <para>
- Firstly, <classname>ManageableRepository.configWorkspace(WorkspaceEntry
wsConfig)</classname> - register a new configuration in RepositoryContainer and
create a WorkspaceContainer.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Single_database_configuration-Dynamic_Workspace_Creation">
+ <title>Dynamic Workspace Creation</title>
+ <para>
+ Workspaces can be added dynamically during runtime.
+ </para>
+ <para>
+ This can be performed in two steps:
+ <itemizedlist>
+ <listitem>
+ <para>
+ Firstly,
<classname>ManageableRepository.configWorkspace(WorkspaceEntry
wsConfig)</classname> - register a new configuration in RepositoryContainer and
create a WorkspaceContainer.
+ </para>
- </listitem>
- <listitem>
- <para>
- Secondly, the main step,
<classname>ManageableRepository.createWorkspace(String
workspaceName)</classname> - creation of a new workspace.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Secondly, the main step,
<classname>ManageableRepository.createWorkspace(String
workspaceName)</classname> - creation of a new workspace.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- </para>
+ </itemizedlist>
+ </para>
- </section>
-
+ </section>
+
- </section>
-
- <section
id="sect-Reference_Guide-JDBC_Data_Container_Config-Simple_and_Complex_queries">
- <title>Simple and Complex queries</title>
- <para>
- eXo JCR provides two ways for interact with Database -
<classname>JDBCStorageConnection</classname> that uses simple queries and
<classname>CQJDBCStorageConection</classname> that uses complex queries for
reducing amount of database callings.
- </para>
- <para>
- Simple queries will be used if you chose
<classname>org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer</classname>:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-JDBC_Data_Container_Config-Simple_and_Complex_queries">
+ <title>Simple and Complex queries</title>
+ <para>
+ eXo JCR provides two ways for interact with Database -
<classname>JDBCStorageConnection</classname> that uses simple queries and
<classname>CQJDBCStorageConection</classname> that uses complex queries for
reducing amount of database callings.
+ </para>
+ <para>
+ Simple queries will be used if you chose
<classname>org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer</classname>:
+ </para>
+
<programlisting language="XML"
role="XML"><workspaces>
<workspace name="ws"
auto-init-root-nodetype="nt:unstructured">
<container
class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer">
@@ -749,90 +730,90 @@
</workspace>
</worksapces>
</programlisting>
- <para>
- Complex queries will be used if you chose
<classname>org.exoplatform.services.jcr.impl.storage.jdbc.optimisation.CQJDBCWorkspaceDataContainer</classname>:
- </para>
-
+ <para>
+ Complex queries will be used if you chose
<classname>org.exoplatform.services.jcr.impl.storage.jdbc.optimisation.CQJDBCWorkspaceDataContainer</classname>:
+ </para>
+
<programlisting language="XML"
role="XML"><workspaces>
<workspace name="ws"
auto-init-root-nodetype="nt:unstructured">
<container
class="org.exoplatform.services.jcr.impl.storage.jdbc.optimisation.CQJDBCWorkspaceDataContainer">
...
</workspace>
</worksapces></programlisting>
- <para>
- Why we should use a Complex Queries?
- <simplelist>
- <member>They are optimised to reduce amount of requests to
database.</member>
+ <para>
+ Why we should use a Complex Queries?
+ <simplelist>
+ <member>They are optimised to reduce amount of requests to
database.</member>
- </simplelist>
- Why we should use a Simple Queries?
- <simplelist>
- <member>Simple queries implemented in way to support as many database dialects
as possible.</member>
- <member>Simple queries do not use sub queries, left or right
joins.</member>
+ </simplelist>
+ Why we should use a Simple Queries?
+ <simplelist>
+ <member>Simple queries implemented in way to support as many
database dialects as possible.</member>
+ <member>Simple queries do not use sub queries, left or right
joins.</member>
- </simplelist>
- </para>
+ </simplelist>
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-JDBC_Data_Container_Config-Forse_Query_Hints">
- <title>Forse Query Hints</title>
- <para>
- Some databases supports hints to increase query performance (like Oracle, MySQL, etc).
eXo JCR have separate Complex Query implementation for Orcale dialect, that uses query
hints to increase performance for few important queries.
- </para>
- <para>
- To enable this option put next configuration property:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-JDBC_Data_Container_Config-Forse_Query_Hints">
+ <title>Forse Query Hints</title>
+ <para>
+ Some databases supports hints to increase query performance (like Oracle,
MySQL, etc). eXo JCR have separate Complex Query implementation for Orcale dialect, that
uses query hints to increase performance for few important queries.
+ </para>
+ <para>
+ To enable this option put next configuration property:
+ </para>
+
<programlisting language="XML" role="XML"><workspace
name="ws" auto-init-root-nodetype="nt:unstructured">
<container
class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer">
<properties>
<property name="dialect" value="oracle"/>
<property name="force.query.hints" value="true"
/>
......</programlisting>
- <para>
- Query hints enabled by default.
- </para>
- <para>
- eXo JCR uses query hints only for Complex Query Oracle dialect. For all other dialects
this parameter is ignored.
- </para>
+ <para>
+ Query hints enabled by default.
+ </para>
+ <para>
+ eXo JCR uses query hints only for Complex Query Oracle dialect. For all other
dialects this parameter is ignored.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-JDBC_Data_Container_Config-Notes_for_Microsoft_Windows_users">
- <title>Notes for Microsoft Windows users</title>
- <para>
- The current configuration of eXo JCR uses <ulink
url="http://commons.apache.org/dbcp/">Apache DBCP</ulink> connection
pool (<classname>org.apache.commons.dbcp.BasicDataSourceFactory</classname>).
It's possible to set a big value for maxActive parameter in
<filename>configuration.xml</filename>. That means usage of lots of TCP/IP
ports from a client machine inside the pool (i.e. JDBC driver). As a result, the data
container can throw exceptions like "Address already in use". To solve this
problem, you have to configure the client's machine networking software for the usage
of shorter timeouts for opened TCP/IP ports.
- </para>
- <para>
- Microsoft Windows has <parameter>MaxUserPort</parameter>,
<parameter>TcpTimedWaitDelay</parameter> registry keys in the node
<parameter>HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters</parameter>,
by default these keys are unset, set each one with values like these:
- <itemizedlist>
- <listitem>
- <para>
- "TcpTimedWaitDelay"=dword:0000001e, sets TIME_WAIT parameter to 30
seconds, default is 240.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-JDBC_Data_Container_Config-Notes_for_Microsoft_Windows_users">
+ <title>Notes for Microsoft Windows users</title>
+ <para>
+ The current configuration of eXo JCR uses <ulink
url="http://commons.apache.org/dbcp/">Apache DBCP</ulink> connection
pool (<classname>org.apache.commons.dbcp.BasicDataSourceFactory</classname>).
It's possible to set a big value for maxActive parameter in
<filename>configuration.xml</filename>. That means usage of lots of TCP/IP
ports from a client machine inside the pool (i.e. JDBC driver). As a result, the data
container can throw exceptions like "Address already in use". To solve this
problem, you have to configure the client's machine networking software for the usage
of shorter timeouts for opened TCP/IP ports.
+ </para>
+ <para>
+ Microsoft Windows has <parameter>MaxUserPort</parameter>,
<parameter>TcpTimedWaitDelay</parameter> registry keys in the node
<parameter>HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters</parameter>,
by default these keys are unset, set each one with values like these:
+ <itemizedlist>
+ <listitem>
+ <para>
+ "TcpTimedWaitDelay"=dword:0000001e, sets TIME_WAIT
parameter to 30 seconds, default is 240.
+ </para>
- </listitem>
- <listitem>
- <para>
- "MaxUserPort"=dword:00001b58, sets the maximum of open ports to 7000 or
higher, default is 5000.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ "MaxUserPort"=dword:00001b58, sets the maximum of open
ports to 7000 or higher, default is 5000.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- </para>
- <para>
- A sample registry file is below:
- </para>
-
+ </itemizedlist>
+ </para>
+ <para>
+ A sample registry file is below:
+ </para>
+
<programlisting>Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"MaxUserPort"=dword:00001b58
"TcpTimedWaitDelay"=dword:0000001e</programlisting>
- </section>
+ </section>
</section>
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/jbosscache-configuration-templates.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/jbosscache-configuration-templates.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/jbosscache-configuration-templates.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -4,76 +4,76 @@
%BOOK_ENTITIES;
]>
<section id="sect-Reference_Guide-JBoss_Cache_configuration">
- <title>JBoss Cache configuration</title>
- <section
id="sect-Reference_Guide-JBoss_Cache_configuration-JBoss_cache_configuration_for_indexer_lock_manager_and_data_container">
- <title>JBoss cache configuration for indexer, lock manager and data
container</title>
- <para>
- Each mentioned components uses instances of JBoss Cache product for caching in
clustered environment. So every element has it's own transport and has to be
configured in a proper way. As usual, workspaces have similar configuration but with
different cluster-names and may-be some other parameters. The simplest way to configure
them is to define their own configuration files for each component in each workspace:
- </para>
-
-<programlisting language="XML" role="XML"><property
name="jbosscache-configuration"
value="conf/standalone/test-jbosscache-lock-db1-ws1.xml"
/></programlisting>
- <para>
- But if there are few workspaces, configuring them in such a way can be painful and
hard-manageable. eXo JCR offers a template-based configuration for JBoss Cache instances.
You can have one template for Lock Manager, one for Indexer and one for data container and
use them in all the workspaces, defining the map of substitution parameters in a main
configuration file. Just simply define ${jbosscache-<parameter name>} inside
xml-template and list correct value in JCR configuration file just below
"jbosscache-configuration", as shown:
- </para>
- <para>
- Template:
- </para>
-
+ <title>JBoss Cache configuration</title>
+ <section
id="sect-Reference_Guide-JBoss_Cache_configuration-JBoss_cache_configuration_for_indexer_lock_manager_and_data_container">
+ <title>JBoss cache configuration for indexer, lock manager and data
container</title>
+ <para>
+ Each mentioned components uses instances of JBoss Cache product for caching
in clustered environment. So every element has it's own transport and has to be
configured in a proper way. As usual, workspaces have similar configuration but with
different cluster-names and may-be some other parameters. The simplest way to configure
them is to define their own configuration files for each component in each workspace:
+ </para>
+
+<programlisting language="XML" role="XML"><property
name="jbosscache-configuration"
value="conf/<remark>standalone</remark>/test-jbosscache-lock-db1-ws1.xml"
/></programlisting>
+ <para>
+ But if there are few workspaces, configuring them in such a way can be
painful and hard-manageable. eXo JCR offers a template-based configuration for JBoss Cache
instances. You can have one template for Lock Manager, one for Indexer and one for data
container and use them in all the workspaces, defining the map of substitution parameters
in a main configuration file. Just simply define ${jbosscache-<parameter
name>} inside xml-template and list correct value in JCR configuration file just
below "jbosscache-configuration", as shown:
+ </para>
+ <para>
+ Template:
+ </para>
+
<programlisting language="XML" role="XML">...
<clustering mode="replication"
clusterName="${jbosscache-cluster-name}">
<stateRetrieval timeout="20000" fetchInMemoryState="false"
/>
...</programlisting>
- <para>
- and JCR configuration file:
- </para>
-
+ <para>
+ and JCR configuration file:
+ </para>
+
<programlisting language="XML" role="XML">...
<property name="jbosscache-configuration"
value="jar:/conf/portal/jbosscache-lock.xml" />
<property name="jbosscache-cluster-name"
value="JCR-cluster-locks-db1-ws" />
...</programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-JBoss_Cache_configuration-JGroups_configuration">
- <title>JGroups configuration</title>
- <para>
- JGroups is used by JBoss Cache for network communications and transport in a clustered
environment. If property "jgroups-configuration" is defined in component
configuration, it will be injected into the JBoss Cache instance on startup.
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-JBoss_Cache_configuration-JGroups_configuration">
+ <title>JGroups configuration</title>
+ <para>
+ JGroups is used by JBoss Cache for network communications and transport in a
clustered environment. If property "jgroups-configuration" is defined in
component configuration, it will be injected into the JBoss Cache instance on startup.
+ </para>
+
<programlisting language="XML" role="XML"><property
name="jgroups-configuration" value="your/path/to/modified-udp.xml"
/></programlisting>
- <para>
- As mentioned above, each component (lock manager, data container and query handler)
for each workspace requires its own clustered environment. In other words, they have their
own clusters with unique names. By default, each cluster should perform multi-casts on a
separate port. This configuration leads to much unnecessary overhead on cluster.
That's why JGroups offers multiplexer feature, providing ability to use one single
channel for set of clusters. This feature reduces network overheads and increase
performance and stability of application. To enable multiplexer stack, you should define
appropriate configuration file (upd-mux.xml is pre-shipped one with eXo JCR) and set
"jgroups-multiplexer-stack" into "true".
- </para>
-
+ <para>
+ As mentioned above, each component (lock manager, data container and query
handler) for each workspace requires its own clustered environment. In other words, they
have their own clusters with unique names. By default, each cluster should perform
multi-casts on a separate port. This configuration leads to much unnecessary overhead on
cluster. That's why JGroups offers multiplexer feature, providing ability to use one
single channel for set of clusters. This feature reduces network overheads and increase
performance and stability of application. To enable multiplexer stack, you should define
appropriate configuration file (upd-mux.xml is pre-shipped one with eXo JCR) and set
"jgroups-multiplexer-stack" into "true".
+ </para>
+
<programlisting language="XML" role="XML"><property
name="jgroups-configuration" value="jar:/conf/portal/udp-mux.xml"
/>
<property name="jgroups-multiplexer-stack" value="true"
/></programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-JBoss_Cache_configuration-Allow_to_share_JBoss_Cache_instances">
- <title>Allow to share JBoss Cache instances</title>
- <para>
- A JBoss Cache instance is quite resource consuming and by default we will have 3 JBoss
Cache instances (one instance for the indexer, one for the lock manager and one for the
data container) for each workspace, so if you intend to have a lot of workspaces it could
make sense to decide to share one JBoss Cache instance with several cache instances of the
same type (i.e. indexer, lock manager or data container). This feature is disabled by
default and can be enabled at component configuration level (i.e. indexer configuration,
lock manager configuration and/or data container configuration) by setting the property
"jbosscache-shareable" to true as below:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-JBoss_Cache_configuration-Allow_to_share_JBoss_Cache_instances">
+ <title>Allow to share JBoss Cache instances</title>
+ <para>
+ A JBoss Cache instance is quite resource consuming and by default we will
have 3 JBoss Cache instances (one instance for the indexer, one for the lock manager and
one for the data container) for each workspace, so if you intend to have a lot of
workspaces it could make sense to decide to share one JBoss Cache instance with several
cache instances of the same type (i.e. indexer, lock manager or data container). This
feature is disabled by default and can be enabled at component configuration level (i.e.
indexer configuration, lock manager configuration and/or data container configuration) by
setting the property "jbosscache-shareable" to true as below:
+ </para>
+
<programlisting language="XML" role="XML"><property
name="jbosscache-shareable" value="true"
/></programlisting>
- <para>
- Once enabled this feature will allow the JBoss Cache instance used by the component to
be re-used by another components of the same type (i.e. indexer, lock manager or data
container) with the exact same JBoss Cache configuration (except the eviction
configuration that cans be different), which means that all the parameters of type
${jbosscache-<parameter name>} must be identical between the components of
same type of different workspaces. In other words, if we use the same values for the
parameters of type ${jbosscache-<parameter name>} in each workspace, we will
have only 3 JBoss Cache instances (one instance for the indexer, one for the lock manager
and one for the data container) used whatever the total amount of workspaces defined.
- </para>
+ <para>
+ Once enabled this feature will allow the JBoss Cache instance used by the
component to be re-used by another components of the same type (i.e. indexer, lock manager
or data container) with the exact same JBoss Cache configuration (except the eviction
configuration that cans be different), which means that all the parameters of type
${jbosscache-<parameter name>} must be identical between the components of
same type of different workspaces. In other words, if we use the same values for the
parameters of type ${jbosscache-<parameter name>} in each workspace, we will
have only 3 JBoss Cache instances (one instance for the indexer, one for the lock manager
and one for the data container) used whatever the total amount of workspaces defined.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-JBoss_Cache_configuration-Shipped_JBoss_Cache_configuration_templates">
- <title>Shipped JBoss Cache configuration templates</title>
- <para>
- eXo JCR implementation is shipped with ready-to-use JBoss Cache configuration
templates for JCR's components. They are situated in application package in
/conf/porta/ folder.
- </para>
- <section
id="sect-Reference_Guide-Shipped_JBoss_Cache_configuration_templates-Data_container_template">
- <title>Data container template</title>
- <para>
- Data container template is "jbosscache-data.xml":
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-JBoss_Cache_configuration-Shipped_JBoss_Cache_configuration_templates">
+ <title>Shipped JBoss Cache configuration templates</title>
+ <para>
+ eXo JCR implementation is shipped with ready-to-use JBoss Cache configuration
templates for JCR's components. They are situated in application package in
/conf/porta/ folder.
+ </para>
+ <section
id="sect-Reference_Guide-Shipped_JBoss_Cache_configuration_templates-Data_container_template">
+ <title>Data container template</title>
+ <para>
+ Data container template is "jbosscache-data.xml":
+ </para>
+
<programlisting language="XML" role="XML"><?xml
version="1.0" encoding="UTF-8"?>
<jbosscache
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:jboss:jbosscache-core:config:3.1">
@@ -96,42 +96,42 @@
</default>
</eviction>
</jbosscache></programlisting>
- <table
id="tabl-Reference_Guide-Data_container_template-Template_variables">
- <title>Template variables</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry align="center">
- Variable
- </entry>
+ <table
id="tabl-Reference_Guide-Data_container_template-Template_variables">
+ <title>Template variables</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry align="center">
+ Variable
+ </entry>
- </row>
+ </row>
- </thead>
- <tbody>
- <row>
- <entry>
- jbosscache-cluster-name
- </entry>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+ jbosscache-cluster-name
+ </entry>
- </row>
+ </row>
- </tbody>
+ </tbody>
- </tgroup>
+ </tgroup>
- </table>
- <para>
- </para>
+ </table>
+ <para>
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Shipped_JBoss_Cache_configuration_templates-Lock_manager_template">
- <title>Lock manager template</title>
- <para>
- It's template name is "jbosscache-lock.xml"
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-Shipped_JBoss_Cache_configuration_templates-Lock_manager_template">
+ <title>Lock manager template</title>
+ <para>
+ It's template name is "jbosscache-lock.xml"
+ </para>
+
<programlisting language="XML" role="XML"><?xml
version="1.0" encoding="UTF-8"?>
<jbosscache
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:jboss:jbosscache-core:config:3.1">
@@ -163,100 +163,100 @@
</loader>
</loaders>
</jbosscache></programlisting>
- <table
id="tabl-Reference_Guide-Lock_manager_template-Template_variables">
- <title>Template variables</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry align="center">
- Variable
- </entry>
+ <table
id="tabl-Reference_Guide-Lock_manager_template-Template_variables">
+ <title>Template variables</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry align="center">
+ Variable
+ </entry>
- </row>
+ </row>
- </thead>
- <tbody>
- <row>
- <entry>
- jbosscache-cluster-name
- </entry>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+ jbosscache-cluster-name
+ </entry>
- </row>
- <row>
- <entry>
- jbosscache-cl-cache.jdbc.table.name
- </entry>
+ </row>
+ <row>
+ <entry>
+ jbosscache-cl-cache.jdbc.table.name
+ </entry>
- </row>
- <row>
- <entry>
- jbosscache-cl-cache.jdbc.table.create
- </entry>
+ </row>
+ <row>
+ <entry>
+ jbosscache-cl-cache.jdbc.table.create
+ </entry>
- </row>
- <row>
- <entry>
- jbosscache-cl-cache.jdbc.table.drop
- </entry>
+ </row>
+ <row>
+ <entry>
+ jbosscache-cl-cache.jdbc.table.drop
+ </entry>
- </row>
- <row>
- <entry>
- jbosscache-cl-cache.jdbc.table.primarykey
- </entry>
+ </row>
+ <row>
+ <entry>
+ jbosscache-cl-cache.jdbc.table.primarykey
+ </entry>
- </row>
- <row>
- <entry>
- jbosscache-cl-cache.jdbc.fqn.column
- </entry>
+ </row>
+ <row>
+ <entry>
+ jbosscache-cl-cache.jdbc.fqn.column
+ </entry>
- </row>
- <row>
- <entry>
- jbosscache-cl-cache.jdbc.fqn.type
- </entry>
+ </row>
+ <row>
+ <entry>
+ jbosscache-cl-cache.jdbc.fqn.type
+ </entry>
- </row>
- <row>
- <entry>
- jbosscache-cl-cache.jdbc.node.column
- </entry>
+ </row>
+ <row>
+ <entry>
+ jbosscache-cl-cache.jdbc.node.column
+ </entry>
- </row>
- <row>
- <entry>
- jbosscache-cl-cache.jdbc.node.type
- </entry>
+ </row>
+ <row>
+ <entry>
+ jbosscache-cl-cache.jdbc.node.type
+ </entry>
- </row>
- <row>
- <entry>
- jbosscache-cl-cache.jdbc.parent.column
- </entry>
+ </row>
+ <row>
+ <entry>
+ jbosscache-cl-cache.jdbc.parent.column
+ </entry>
- </row>
- <row>
- <entry>
- jbosscache-cl-cache.jdbc.datasource
- </entry>
+ </row>
+ <row>
+ <entry>
+ jbosscache-cl-cache.jdbc.datasource
+ </entry>
- </row>
+ </row>
- </tbody>
+ </tbody>
- </tgroup>
+ </tgroup>
- </table>
+ </table>
- </section>
-
- <section
id="sect-Reference_Guide-Shipped_JBoss_Cache_configuration_templates-Query_handler_indexer_template">
- <title>Query handler (indexer) template</title>
- <para>
- Have a look at "jbosscache-indexer.xml"
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-Shipped_JBoss_Cache_configuration_templates-Query_handler_indexer_template">
+ <title>Query handler (indexer) template</title>
+ <para>
+ Have a look at "jbosscache-indexer.xml"
+ </para>
+
<programlisting language="XML" role="XML"><?xml
version="1.0" encoding="UTF-8"?>
<jbosscache
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:jboss:jbosscache-core:config:3.1">
<locking useLockStriping="false" concurrencyLevel="50000"
lockParentForChildInsertRemove="false"
@@ -274,36 +274,36 @@
</default>
</eviction>
</jbosscache></programlisting>
- <table
id="tabl-Reference_Guide-Query_handler_indexer_template-Template_variables">
- <title>Template variables</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry align="center">
- Variable
- </entry>
+ <table
id="tabl-Reference_Guide-Query_handler_indexer_template-Template_variables">
+ <title>Template variables</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry align="center">
+ Variable
+ </entry>
- </row>
+ </row>
- </thead>
- <tbody>
- <row>
- <entry>
- jbosscache-cluster-name
- </entry>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+ jbosscache-cluster-name
+ </entry>
- </row>
+ </row>
- </tbody>
+ </tbody>
- </tgroup>
+ </tgroup>
- </table>
+ </table>
- </section>
-
+ </section>
+
- </section>
+ </section>
</section>
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/jca.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/jca.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/jca.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -4,21 +4,21 @@
%BOOK_ENTITIES;
]>
<section id="sect-Reference_Guide-The_JCA_Resource_Adapter">
- <title>The <emphasis>JCA</emphasis> Resource Adapter</title>
- <section id="sect-Reference_Guide-The_JCA_Resource_Adapter-Overview">
- <title>Overview</title>
- <para>
- eXo JCR supports <emphasis>J2EE Connector Architecture</emphasis> 1.5,
thus If you would like to delegate the JCR Session lifecycle to your application server,
you can use the JCA Resource Adapter for eXo JCR if your application server supports JCA
1.5. This adapter only supports XA Transaction, in other words you cannot use it for local
transactions. Since the JCR Sessions have not been designed to be shareable, the session
pooling is simply not covered by the adapter.
- </para>
+ <title>The <emphasis>JCA</emphasis> Resource Adapter</title>
+ <section
id="sect-Reference_Guide-The_JCA_Resource_Adapter-Overview">
+ <title>Overview</title>
+ <para>
+ eXo JCR supports <emphasis>J2EE Connector Architecture</emphasis>
1.5, thus If you would like to delegate the JCR Session lifecycle to your application
server, you can use the JCA Resource Adapter for eXo JCR if your application server
supports JCA 1.5. This adapter only supports XA Transaction, in other words you cannot use
it for local transactions. Since the JCR Sessions have not been designed to be shareable,
the session pooling is simply not covered by the adapter.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-The_JCA_Resource_Adapter-The_SessionFactory">
- <title>The <emphasis>SessionFactory</emphasis></title>
- <para>
- The equivalent of the
<emphasis>javax.resource.cci.ConnectionFactory</emphasis> in JCA terminology
is <emphasis>org.exoplatform.connectors.jcr.adapter.SessionFactory</emphasis>
in the context of eXo JCR, the resource that you will get thanks to a JNDI lookup is of
type <emphasis>SessionFactory</emphasis> and provides the following methods:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-The_JCA_Resource_Adapter-The_SessionFactory">
+ <title>The <emphasis>SessionFactory</emphasis></title>
+ <para>
+ The equivalent of the
<emphasis>javax.resource.cci.ConnectionFactory</emphasis> in JCA terminology
is <emphasis>org.exoplatform.connectors.jcr.adapter.SessionFactory</emphasis>
in the context of eXo JCR, the resource that you will get thanks to a JNDI lookup is of
type <emphasis>SessionFactory</emphasis> and provides the following methods:
+ </para>
+
<programlisting> /**
* Get a JCR session corresponding to the repository
* defined in the configuration and the default workspace.
@@ -59,50 +59,50 @@
*/
Session getSession(String workspace, String userName, String password) throws
RepositoryException;</programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-The_JCA_Resource_Adapter-Configuration">
- <title>Configuration</title>
- <table
id="tabl-Reference_Guide-Configuration-Configuration_Properties">
- <title>Configuration Properties</title>
- <tgroup cols="2">
- <tbody>
- <row>
- <entry>
- <emphasis>PortalContainer</emphasis>
- </entry>
- <entry>
- In case of the portal mode, if no portal container can be found in the context of
the request, the adapter will use the value of this parameter to get the name of the
expected portal container to create the JCR sessions. In case of a standalone mode, this
parameter is not used. This parameter is optional, by default the default portal container
will be used.
- </entry>
+ </section>
+
+ <section
id="sect-Reference_Guide-The_JCA_Resource_Adapter-Configuration">
+ <title>Configuration</title>
+ <table
id="tabl-Reference_Guide-Configuration-Configuration_Properties">
+ <title>Configuration Properties</title>
+ <tgroup cols="2">
+ <tbody>
+ <row>
+ <entry>
+ <emphasis>PortalContainer</emphasis>
+ </entry>
+ <entry>
+ In case of the portal mode, if no portal container can be
found in the context of the request, the adapter will use the value of this parameter to
get the name of the expected portal container to create the JCR sessions. This parameter
is optional, by default the default portal container will be used.
+ </entry>
- </row>
- <row>
- <entry>
- <emphasis>Repository</emphasis>
- </entry>
- <entry>
- The repository name used to create JCR sessions. This parameter is optional, by
default the current repository will be used.
- </entry>
+ </row>
+ <row>
+ <entry>
+ <emphasis>Repository</emphasis>
+ </entry>
+ <entry>
+ The repository name used to create JCR sessions. This
parameter is optional, by default the current repository will be used.
+ </entry>
- </row>
+ </row>
- </tbody>
+ </tbody>
- </tgroup>
+ </tgroup>
- </table>
+ </table>
- </section>
-
- <section
id="sect-Reference_Guide-The_JCA_Resource_Adapter-Deployment">
- <title>Deployment</title>
- <para>
- In case of the standalone mode where the JCR and its dependencies are not provided,
you will need to deploy the whole ear file corresponding to the artifactId
<emphasis>exo.jcr.ear</emphasis> and groupId
<emphasis>org.exoplatform.jcr</emphasis>, the rar file is embedded into the
ear file. In case the JCR and its dependencies are provided like when you use it with
gateIn for example, you will need to deploy only the rar file corresponding to the
artifactId <emphasis>exo.jcr.connectors.jca</emphasis> and groupId
<emphasis>org.exoplatform.jcr</emphasis>.
- </para>
- <para>
- Then you will need to configure the connector itself, for example for JBoss AS, you
need to create in your deploy directory a file of type
<emphasis>*-ds.xml</emphasis> (jcr-ds.xml for example) with the following
content:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-The_JCA_Resource_Adapter-Deployment">
+ <title>Deployment</title>
+ <para>
+ As the JCR and its dependencies are provided when you use it with gateIn you
will need to deploy only the rar file corresponding to the artifactId
<emphasis>exo.jcr.connectors.jca</emphasis> and groupId
<emphasis>org.exoplatform.jcr</emphasis>.
+ </para>
+ <para>
+ Then you will need to configure the connector itself, for example for JBoss
AS, you need to create in your deploy directory a file of type
<emphasis>*-ds.xml</emphasis> (jcr-ds.xml for example) with the following
content:
+ </para>
+
<programlisting><connection-factories>
<tx-connection-factory>
<jndi-name>jcr/repository</jndi-name>
@@ -118,7 +118,7 @@
</tx-connection-factory>
</connection-factories></programlisting>
- </section>
+ </section>
</section>
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/other/binary-values-processing.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/other/binary-values-processing.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/other/binary-values-processing.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -4,42 +4,42 @@
%BOOK_ENTITIES;
]>
<section id="sect-Reference_Guide-Binary_Values_Processing">
- <title>Binary Values Processing</title>
- <section
id="sect-Reference_Guide-Binary_Values_Processing-Configuration">
- <title>Configuration</title>
- <para>
- Binary large object (BLOB) properties can be stored in two ways in the eXo JCR: in the
database with items information or in an external storage on host file system. These
options can be configured at workspace in the repository configuration file
(repository-configuration.xml in portal and exo-jcr-config.xml in standalone mode). The
database storage can't be completely disabled.
- </para>
- <para>
- The first case is optimal for most of cases which you do not use very large values
or/and do not have too many BLOBs. The configuration of the BLOBs size and BLOBs quantity
in a repository depend on your database features and hardware.
- </para>
- <para>
- The second case is to use an external values storage. The storage can be located on a
built-in hard disk or on an attached storage. But in any cases, you should access to the
storage as if it was a regular file(s). The external value storage is optional and can be
enabled in a database configuration.
- </para>
- <note>
- <para>
- eXo JCR Repository service configuration basics is discussed in <xref
linkend="sect-Reference_Guide-JCR_configuration" />
- </para>
- <para>
- Database and workspace persistence storage configuration is discussed in <xref
linkend="sect-Reference_Guide-JDBC_Data_Container_Config" />
- </para>
- <para>
- Configuration details for <xref
linkend="sect-Reference_Guide-External_Value_Storages" />.
- </para>
+ <title>Binary Values Processing</title>
+ <section
id="sect-Reference_Guide-Binary_Values_Processing-Configuration">
+ <title>Configuration</title>
+ <para>
+ Binary large object (BLOB) properties can be stored in two ways in the eXo
JCR: in the database with items information or in an external storage on host file system.
These options can be configured at workspace in the repository configuration file
(repository-configuration.xml). The database storage can't be completely disabled.
+ </para>
+ <para>
+ The first case is optimal for most of cases which you do not use very large
values or/and do not have too many BLOBs. The configuration of the BLOBs size and BLOBs
quantity in a repository depend on your database features and hardware.
+ </para>
+ <para>
+ The second case is to use an external values storage. The storage can be
located on a built-in hard disk or on an attached storage. But in any cases, you should
access to the storage as if it was a regular file(s). The external value storage is
optional and can be enabled in a database configuration.
+ </para>
+ <note>
+ <para>
+ eXo JCR Repository service configuration basics is discussed in <xref
linkend="sect-Reference_Guide-JCR_configuration" />
+ </para>
+ <para>
+ Database and workspace persistence storage configuration is discussed in
<xref linkend="sect-Reference_Guide-JDBC_Data_Container_Config" />
+ </para>
+ <para>
+ Configuration details for <xref
linkend="sect-Reference_Guide-External_Value_Storages" />.
+ </para>
- </note>
+ </note>
- </section>
-
- <section id="sect-Reference_Guide-Binary_Values_Processing-Usage">
- <title>Usage</title>
- <para>
- In both of the cases, a developer can set/update the binary Property via
Node.setProperty(String, InputStream), Property.setValue(InputStream) as described in the
spec JSR-170. Also, there is the setter with a ready Value object (obtainer from
ValueFactory.createValue(InputStream)).
- </para>
- <para>
- An example of a specification usage.
- </para>
-
+ </section>
+
+ <section id="sect-Reference_Guide-Binary_Values_Processing-Usage">
+ <title>Usage</title>
+ <para>
+ In both of the cases, a developer can set/update the binary Property via
Node.setProperty(String, InputStream), Property.setValue(InputStream) as described in the
spec JSR-170. Also, there is the setter with a ready Value object (obtainer from
ValueFactory.createValue(InputStream)).
+ </para>
+ <para>
+ An example of a specification usage.
+ </para>
+
<programlisting language="Java" role="Java">// Set the property
value with given stream content.
Property binProp = node.setProperty("BinData", myDataStream);
// Get the property value stream.
@@ -54,34 +54,34 @@
updatedBinProp.setValue(ValueFactory.createValue(newDataStream));
// Get the updated property value stream.
InputStream newStream = updatedBinProp.getStream();</programlisting>
- <para>
- But if you need to update the property sequentially and with partial content, you have
no choice but to edit the whole data stream outside and get it back to the repository each
time. In case of really large-sized data, the application will be stuck and the
productivity will decrease a lot. JCR stream setters will also check constraints and
perform common validation each time.
- </para>
- <para>
- There is a feature of the eXo JCR extension that can be used for binary values partial
writing without frequent session level calls. The main idea is to use a value object
obtained from the property as the storage of the property content while writing/reading
during runtime.
- </para>
- <para>
- According to the spec JSR-170, Value interface provides the state of property that
can't be changed (edited). The eXo JCR core provides ReadableBinaryValue and
EditableBinaryValue interfaces which themselves extend JCR Value. The interfaces allow the
user to partially read and change a value content.
- </para>
- <para>
- ReadableBinaryValue value can be casted from any value, i.e. String, Binary, Date
etc.
- </para>
-
+ <para>
+ But if you need to update the property sequentially and with partial content,
you have no choice but to edit the whole data stream outside and get it back to the
repository each time. In case of really large-sized data, the application will be stuck
and the productivity will decrease a lot. JCR stream setters will also check constraints
and perform common validation each time.
+ </para>
+ <para>
+ There is a feature of the eXo JCR extension that can be used for binary
values partial writing without frequent session level calls. The main idea is to use a
value object obtained from the property as the storage of the property content while
writing/reading during runtime.
+ </para>
+ <para>
+ According to the spec JSR-170, Value interface provides the state of property
that can't be changed (edited). The eXo JCR core provides ReadableBinaryValue and
EditableBinaryValue interfaces which themselves extend JCR Value. The interfaces allow the
user to partially read and change a value content.
+ </para>
+ <para>
+ ReadableBinaryValue value can be casted from any value, i.e. String, Binary,
Date etc.
+ </para>
+
<programlisting language="Java" role="Java">// get the property
value of type PropertyType.STRING
ReadableBinaryValue extValue = (ReadableBinaryValue)
node.getProperty("LargeText").getValue();
// read 200 bytes to a destStream from the position 1024 in the value content
OutputStream destStream = new FileOutputStream("MyTextFile.txt");
extValue.read(destStream, 200, 1024);</programlisting>
- <para>
- But EditableBinaryValue can be applied only to properties of type PropertyType.BINARY.
In other cases, a cast to EditableBinaryValue will fail.
- </para>
- <para>
- After the value has been edited, the EditableBinaryValue value can be applied to the
property using the standard setters (Property.setValue(Value), Property.setValues(Value),
Node.setProperty(String, Value) etc.). Only after the EditableBinaryValue has been set to
the property, it can be obtained in this session by getters (Property.getValue(),
Node.getProperty(String) etc.).
- </para>
- <para>
- The user can obtain an EditableBinaryValue instance and fill it with data in an
interaction manner (or any other appropriated to the targets) and return (set) the value
to the property after the content will be done.
- </para>
-
+ <para>
+ But EditableBinaryValue can be applied only to properties of type
PropertyType.BINARY. In other cases, a cast to EditableBinaryValue will fail.
+ </para>
+ <para>
+ After the value has been edited, the EditableBinaryValue value can be applied
to the property using the standard setters (Property.setValue(Value),
Property.setValues(Value), Node.setProperty(String, Value) etc.). Only after the
EditableBinaryValue has been set to the property, it can be obtained in this session by
getters (Property.getValue(), Node.getProperty(String) etc.).
+ </para>
+ <para>
+ The user can obtain an EditableBinaryValue instance and fill it with data in
an interaction manner (or any other appropriated to the targets) and return (set) the
value to the property after the content will be done.
+ </para>
+
<programlisting language="Java" role="Java">// get the property
value for PropertyType.BINARY Property
EditableBinaryValue extValue = (EditableBinaryValue)
node.getProperty("BinData").getValue();
@@ -93,10 +93,10 @@
// save the Property to persistence
node.save();</programlisting>
- <para>
- A practical example of the iterative usage. In this example, the value is updated with
data from the sequence of streams and after the update is done, the value will be applied
to the property and be visible during the session.
- </para>
-
+ <para>
+ A practical example of the iterative usage. In this example, the value is
updated with data from the sequence of streams and after the update is done, the value
will be applied to the property and be visible during the session.
+ </para>
+
<programlisting language="Java" role="Java">// update length
bytes from the stream starting from the particular
// position in the existing Value data
int dpos = 1024;
@@ -108,42 +108,42 @@
// apply the edited EditableBinaryValue to the Property
node.setProperty("BinData", extValue);</programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-Binary_Values_Processing-Value_implementations">
- <title>Value implementations</title>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/eXoJCR/other/binaryvalue.png"
width="444" />
- </imageobject>
+ </section>
+
+ <section
id="sect-Reference_Guide-Binary_Values_Processing-Value_implementations">
+ <title>Value implementations</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/eXoJCR/other/binaryvalue.png"
width="444" />
+ </imageobject>
- </mediaobject>
- <para>
- ReadableBinaryValue has one method to read Value.
- </para>
- <para>
- Read length bytes is counted from the binary value to the given position into the
stream.
- </para>
-
+ </mediaobject>
+ <para>
+ ReadableBinaryValue has one method to read Value.
+ </para>
+ <para>
+ Read length bytes is counted from the binary value to the given position into
the stream.
+ </para>
+
<programlisting language="Java" role="Java">long
read(OutputStream stream, long length, long position) throws IOException,
RepositoryException ;</programlisting>
- <para>
- EditableBinaryValue has two methods to edit value.
- </para>
- <para>
- Update with length bytes from the specified stream to this value data at a position.
If the position is lower than 0, the IOException exception will be thrown. If the position
is higher than the current Value length, the Value length will be increased at first to
the size of position and length bytes will be added after the position.
- </para>
-
+ <para>
+ EditableBinaryValue has two methods to edit value.
+ </para>
+ <para>
+ Update with length bytes from the specified stream to this value data at a
position. If the position is lower than 0, the IOException exception will be thrown. If
the position is higher than the current Value length, the Value length will be increased
at first to the size of position and length bytes will be added after the position.
+ </para>
+
<programlisting language="Java" role="Java">void
update(InputStream stream, long length, long position) throws
IOException;</programlisting>
- <para>
- Set the length of the Value in bytes to the specified size. If the size is lower than
0, the IOException exception will be thrown. This operation can be used to extend or
truncat the Value size. This method is used internally in the update operation in case of
extending the size to the given position.
- </para>
-
+ <para>
+ Set the length of the Value in bytes to the specified size. If the size is
lower than 0, the IOException exception will be thrown. This operation can be used to
extend or truncat the Value size. This method is used internally in the update operation
in case of extending the size to the given position.
+ </para>
+
<programlisting language="Java" role="Java">void setLength(long
size) throws IOException;</programlisting>
- <para>
- An application can perform JCR binary operations more flexibly and will have less I/O
and CPU usage using these methods.
- </para>
+ <para>
+ An application can perform JCR binary operations more flexibly and will have
less I/O and CPU usage using these methods.
+ </para>
- </section>
+ </section>
</section>
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/performance-tuning-guide.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/performance-tuning-guide.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/performance-tuning-guide.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -4,372 +4,372 @@
%BOOK_ENTITIES;
]>
<section id="sect-Reference_Guide-JCR_Performance_Tuning_Guide">
- <title>JCR Performance Tuning Guide</title>
- <section
id="sect-Reference_Guide-JCR_Performance_Tuning_Guide-Introduction">
- <title>Introduction</title>
- <para>
- This guide will show you possible ways of improving JCR performance.
- </para>
- <para>
- It is intended to GateIn Administrators and those who wants to use JCR features.
- </para>
+ <title>JCR Performance Tuning Guide</title>
+ <section
id="sect-Reference_Guide-JCR_Performance_Tuning_Guide-Introduction">
+ <title>Introduction</title>
+ <para>
+ This guide will show you possible ways of improving JCR performance.
+ </para>
+ <para>
+ It is intended to GateIn Administrators and those who wants to use JCR
features.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_Performance_Tuning_Guide-JCR_Performance_and_Scalability">
- <title>JCR Performance and Scalability</title>
- <section
id="sect-Reference_Guide-JCR_Performance_and_Scalability-Cluster_configuration">
- <title>Cluster configuration</title>
- <para>
- <citetitle>EC2 network</citetitle>: 1Gbit
- </para>
- <para>
- <citetitle>Servers hardware</citetitle>:
- <simplelist>
- <member>7.5 GB memory</member>
- <member>4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units
each)</member>
- <member>850 GB instance storage (2×420 GB plus 10 GB root
partition)</member>
- <member>64-bit platform</member>
- <member>I/O Performance: High</member>
- <member>API name: m1.large</member>
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_Performance_Tuning_Guide-JCR_Performance_and_Scalability">
+ <title>JCR Performance and Scalability</title>
+ <section
id="sect-Reference_Guide-JCR_Performance_and_Scalability-Cluster_configuration">
+ <title>Cluster configuration</title>
+ <para>
+ <citetitle>EC2 network</citetitle>: 1Gbit
+ </para>
+ <para>
+ <citetitle>Servers hardware</citetitle>:
+ <simplelist>
+ <member>7.5 GB memory</member>
+ <member>4 EC2 Compute Units (2 virtual cores with 2 EC2
Compute Units each)</member>
+ <member>850 GB instance storage (2×420 GB plus 10 GB root
partition)</member>
+ <member>64-bit platform</member>
+ <member>I/O Performance: High</member>
+ <member>API name: m1.large</member>
- </simplelist>
- </para>
- <note>
- <para>
- NFS and statistics (cacti snmp) server were located on one physical server.
- </para>
+ </simplelist>
+ </para>
+ <note>
+ <para>
+ NFS and statistics (cacti snmp) server were located on one physical
server.
+ </para>
- </note>
- <para>
- <citetitle>JBoss AS configuration</citetitle>
- </para>
- <para>
- <code>JAVA_OPTS: -Dprogram.name=run.sh -server -Xms4g -Xmx4g
-XX:MaxPermSize=512m -Dorg.jboss.resolver.warning=true
-Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000
-XX:+UseParallelGC -Djava.net.preferIPv4Stack=true</code>
- </para>
+ </note>
+ <para>
+ <citetitle>JBoss AS configuration</citetitle>
+ </para>
+ <para>
+ <code>JAVA_OPTS: -Dprogram.name=run.sh -server -Xms4g -Xmx4g
-XX:MaxPermSize=512m -Dorg.jboss.resolver.warning=true
-Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000
-XX:+UseParallelGC -Djava.net.preferIPv4Stack=true</code>
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-JCR_Performance_and_Scalability-JCR_Clustered_Performance">
- <title>JCR Clustered Performance</title>
- <para>
- Benchmark test using webdav (Complex read/write load test (benchmark)) with 20K same
file. To obtain per-operation results we have used custom output from the testscase
threads to CSV file.
- </para>
- <para>
- <citetitle>Read operation</citetitle>:
- <simplelist>
- <member>Warm-up iterations: 100</member>
- <member>Run iterations: 2000</member>
- <member>Background writing threads: 25</member>
- <member>Reading threads: 225</member>
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_Performance_and_Scalability-JCR_Clustered_Performance">
+ <title>JCR Clustered Performance</title>
+ <para>
+ Benchmark test using webdav (Complex read/write load test (benchmark))
with 20K same file. To obtain per-operation results we have used custom output from the
testscase threads to CSV file.
+ </para>
+ <para>
+ <citetitle>Read operation</citetitle>:
+ <simplelist>
+ <member>Warm-up iterations: 100</member>
+ <member>Run iterations: 2000</member>
+ <member>Background writing threads: 25</member>
+ <member>Reading threads: 225</member>
- </simplelist>
- </para>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/eXoJCR/perf_EC2_results.jpg" />
- </imageobject>
+ </simplelist>
+ </para>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/eXoJCR/perf_EC2_results.jpg"
/>
+ </imageobject>
- </mediaobject>
- <table>
- <title></title>
- <tgroup cols="4">
- <thead>
- <row>
- <entry>
- Nodes count
- </entry>
- <entry>
- tps
- </entry>
- <entry>
- Responses >2s
- </entry>
- <entry>
- Responses >4s
- </entry>
+ </mediaobject>
+ <table>
+ <title></title>
+ <tgroup cols="4">
+ <thead>
+ <row>
+ <entry>
+ Nodes count
+ </entry>
+ <entry>
+ tps
+ </entry>
+ <entry>
+ Responses >2s
+ </entry>
+ <entry>
+ Responses >4s
+ </entry>
- </row>
+ </row>
- </thead>
- <tbody>
- <row>
- <entry>
- 1
- </entry>
- <entry>
- 523
- </entry>
- <entry>
- 6.87%
- </entry>
- <entry>
- 1.27%
- </entry>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+ 1
+ </entry>
+ <entry>
+ 523
+ </entry>
+ <entry>
+ 6.87%
+ </entry>
+ <entry>
+ 1.27%
+ </entry>
- </row>
- <row>
- <entry>
- 2
- </entry>
- <entry>
- 1754
- </entry>
- <entry>
- 0.64%
- </entry>
- <entry>
- 0.08%
- </entry>
+ </row>
+ <row>
+ <entry>
+ 2
+ </entry>
+ <entry>
+ 1754
+ </entry>
+ <entry>
+ 0.64%
+ </entry>
+ <entry>
+ 0.08%
+ </entry>
- </row>
- <row>
- <entry>
- 3
- </entry>
- <entry>
- 2388
- </entry>
- <entry>
- 0.49%
- </entry>
- <entry>
- 0.09%
- </entry>
+ </row>
+ <row>
+ <entry>
+ 3
+ </entry>
+ <entry>
+ 2388
+ </entry>
+ <entry>
+ 0.49%
+ </entry>
+ <entry>
+ 0.09%
+ </entry>
- </row>
- <row>
- <entry>
- 4
- </entry>
- <entry>
- 2706
- </entry>
- <entry>
- 0.46%
- </entry>
- <entry>
- 0.1%
- </entry>
+ </row>
+ <row>
+ <entry>
+ 4
+ </entry>
+ <entry>
+ 2706
+ </entry>
+ <entry>
+ 0.46%
+ </entry>
+ <entry>
+ 0.1%
+ </entry>
- </row>
+ </row>
- </tbody>
+ </tbody>
- </tgroup>
+ </tgroup>
- </table>
- <para>
- <citetitle>Read operaion with more threads</citetitle>:
- </para>
- <simplelist>
- <member>Warm-up iterations: 100</member>
- <member>Run iterations: 2000</member>
- <member>Background writing threads: 50</member>
- <member>Reading threads: 450</member>
+ </table>
+ <para>
+ <citetitle>Read operaion with more threads</citetitle>:
+ </para>
+ <simplelist>
+ <member>Warm-up iterations: 100</member>
+ <member>Run iterations: 2000</member>
+ <member>Background writing threads: 50</member>
+ <member>Reading threads: 450</member>
- </simplelist>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/eXoJCR/perf_EC2_results_2.jpg" />
- </imageobject>
+ </simplelist>
+ <mediaobject>
+ <imageobject>
+ <imagedata
fileref="images/eXoJCR/perf_EC2_results_2.jpg" />
+ </imageobject>
- </mediaobject>
- <table>
- <title></title>
- <tgroup cols="4">
- <thead>
- <row>
- <entry>
- Nodes count
- </entry>
- <entry>
- tps
- </entry>
- <entry>
- Responses >2s
- </entry>
- <entry>
- Responses >4s
- </entry>
+ </mediaobject>
+ <table>
+ <title></title>
+ <tgroup cols="4">
+ <thead>
+ <row>
+ <entry>
+ Nodes count
+ </entry>
+ <entry>
+ tps
+ </entry>
+ <entry>
+ Responses >2s
+ </entry>
+ <entry>
+ Responses >4s
+ </entry>
- </row>
+ </row>
- </thead>
- <tbody>
- <row>
- <entry>
- 1
- </entry>
- <entry>
- 116
- </entry>
- <entry>
- ?
- </entry>
- <entry>
- ?
- </entry>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+ 1
+ </entry>
+ <entry>
+ 116
+ </entry>
+ <entry>
+ ?
+ </entry>
+ <entry>
+ ?
+ </entry>
- </row>
- <row>
- <entry>
- 2
- </entry>
- <entry>
- 1558
- </entry>
- <entry>
- 6.1%
- </entry>
- <entry>
- 0.6%
- </entry>
+ </row>
+ <row>
+ <entry>
+ 2
+ </entry>
+ <entry>
+ 1558
+ </entry>
+ <entry>
+ 6.1%
+ </entry>
+ <entry>
+ 0.6%
+ </entry>
- </row>
- <row>
- <entry>
- 3
- </entry>
- <entry>
- 2242
- </entry>
- <entry>
- 3.1%
- </entry>
- <entry>
- 0.38%
- </entry>
+ </row>
+ <row>
+ <entry>
+ 3
+ </entry>
+ <entry>
+ 2242
+ </entry>
+ <entry>
+ 3.1%
+ </entry>
+ <entry>
+ 0.38%
+ </entry>
- </row>
- <row>
- <entry>
- 4
- </entry>
- <entry>
- 2756
- </entry>
- <entry>
- 2.2%
- </entry>
- <entry>
- 0.41%
- </entry>
+ </row>
+ <row>
+ <entry>
+ 4
+ </entry>
+ <entry>
+ 2756
+ </entry>
+ <entry>
+ 2.2%
+ </entry>
+ <entry>
+ 0.41%
+ </entry>
- </row>
+ </row>
- </tbody>
+ </tbody>
- </tgroup>
+ </tgroup>
- </table>
+ </table>
- </section>
-
+ </section>
+
- </section>
-
- <section
id="sect-Reference_Guide-JCR_Performance_Tuning_Guide-Performance_Tuning_Guide">
- <title>Performance Tuning Guide</title>
- <section
id="sect-Reference_Guide-Performance_Tuning_Guide-JBoss_AS_Tuning">
- <title>JBoss AS Tuning</title>
- <para>
- You can use <parameter>maxThreads</parameter> parameter to increase
maximum amount of threads that can be launched in AS instance. This can improve
performance if you need a high level of concurrency. also you can use
<code>-XX:+UseParallelGC</code> java directory to use paralel garbage
collector.
- </para>
- <note>
- <title>Note</title>
- <para>
- Beware of setting <parameter>maxThreads</parameter> too big, this can
cause <exceptionname>OutOfMemoryError</exceptionname>. We've got it with
<code>maxThreads=1250</code> on such machine:
- </para>
- <simplelist>
- <member>7.5 GB memory</member>
- <member>4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units
each)</member>
- <member>850 GB instance storage (2×420 GB plus 10 GB root
partition)</member>
- <member>64-bit platform</member>
- <member>I/O Performance: High</member>
- <member>API name: m1.large</member>
- <member>java -Xmx 4g</member>
+ </section>
+
+ <section
id="sect-Reference_Guide-JCR_Performance_Tuning_Guide-Performance_Tuning_Guide">
+ <title>Performance Tuning Guide</title>
+ <section
id="sect-Reference_Guide-Performance_Tuning_Guide-JBoss_AS_Tuning">
+ <title>JBoss AS Tuning</title>
+ <para>
+ You can use <parameter>maxThreads</parameter> parameter to
increase maximum amount of threads that can be launched in AS instance. This can improve
performance if you need a high level of concurrency. also you can use
<code>-XX:+UseParallelGC</code> java directory to use paralel garbage
collector.
+ </para>
+ <note>
+ <title>Note</title>
+ <para>
+ Beware of setting <parameter>maxThreads</parameter> too
big, this can cause <exceptionname>OutOfMemoryError</exceptionname>. We've
got it with <code>maxThreads=1250</code> on such machine:
+ </para>
+ <simplelist>
+ <member>7.5 GB memory</member>
+ <member>4 EC2 Compute Units (2 virtual cores with 2 EC2
Compute Units each)</member>
+ <member>850 GB instance storage (2×420 GB plus 10 GB root
partition)</member>
+ <member>64-bit platform</member>
+ <member>I/O Performance: High</member>
+ <member>API name: m1.large</member>
+ <member>java -Xmx 4g</member>
- </simplelist>
+ </simplelist>
- </note>
+ </note>
- </section>
-
- <section
id="sect-Reference_Guide-Performance_Tuning_Guide-JCR_Cache_Tuning">
- <title>JCR Cache Tuning</title>
- <para>
- <citetitle>Cache size</citetitle>
- </para>
- <para>
- JCR-cluster implementation is built using JBoss Cache as distributed, replicated
cache. But there is one particularity related to remove action in it. Speed of this
operation depends on the actual size of cache. As many nodes are currently in cache as
much time is needed to remove one particular node (subtree) from it.
- </para>
- <para>
- <citetitle>Eviction</citetitle>
- </para>
- <para>
- Manipulations with eviction <parameter>wakeUpInterval</parameter> value
doestn't affect on performance. Performance results with values from 500 up to 3000
are approximately equal.
- </para>
- <para>
- <citetitle>Transaction Timeout</citetitle>
- </para>
- <para>
- Using short timeout for long transactions such as Export/Import, removing huge
subtree defined timeout may cause
<exceptionname>TransactionTimeoutException</exceptionname>. [TODO] put
recomended timeout value
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Performance_Tuning_Guide-JCR_Cache_Tuning">
+ <title>JCR Cache Tuning</title>
+ <para>
+ <citetitle>Cache size</citetitle>
+ </para>
+ <para>
+ JCR-cluster implementation is built using JBoss Cache as distributed,
replicated cache. But there is one particularity related to remove action in it. Speed of
this operation depends on the actual size of cache. As many nodes are currently in cache
as much time is needed to remove one particular node (subtree) from it.
+ </para>
+ <para>
+ <citetitle>Eviction</citetitle>
+ </para>
+ <para>
+ Manipulations with eviction
<parameter>wakeUpInterval</parameter> value doestn't affect on
performance. Performance results with values from 500 up to 3000 are approximately equal.
+ </para>
+ <para>
+ <citetitle>Transaction Timeout</citetitle>
+ </para>
+ <para>
+ Using short timeout for long transactions such as Export/Import, removing
huge subtree defined timeout may cause
<exceptionname>TransactionTimeoutException</exceptionname>. [TODO] put
recomended timeout value
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Performance_Tuning_Guide-Clustering">
- <title>Clustering</title>
- <para>
- For performance it is better to have loadbalacer, DB server and shared NFS on
different computers. If in some reasons you see that one node gets more load than others
you can decrease this load using load value in load balancer.
- </para>
- <para>
- <citetitle>JGroups configuration</citetitle>
- </para>
- <para>
- It's recommended to use "multiplexer stack" feature present in JGroups.
It is set by default in eXo JCR and offers higher performance in cluster, using less
network connections also. If there are two or more clusters in your network, please check
that they use different ports and different cluster names.
- </para>
- <para>
- <citetitle>Write performance in cluster</citetitle>
- </para>
- <para>
- Exo JCR implementation uses Lucene indexing engine to provide search capabilities.
But Lucene brings some limitations for write operations: it can perform indexing only in
one thread. Thats why write performance in cluster is not higher than in singleton
environment. Data is indexed on coordinator node, so increasing write-load on cluster may
lead to ReplicationTimeout exception. It occurs because writing threads queue in the
indexer and under high load timeout for replication to coordinator will be exceeded.
- </para>
- <para>
- Taking in consideration this fact, it is recommended to exceed
<parameter>replTimeout</parameter> value in cache configurations in case of
high write-load.
- </para>
- <para>
- <citetitle>Replication timeout</citetitle>
- </para>
- <para>
- Some operations may take too much time. So if you get
<exceptionname>ReplicationTimeoutException</exceptionname> try increasing
replication timeout:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-Performance_Tuning_Guide-Clustering">
+ <title>Clustering</title>
+ <para>
+ For performance it is better to have loadbalacer, DB server and shared
NFS on different computers. If in some reasons you see that one node gets more load than
others you can decrease this load using load value in load balancer.
+ </para>
+ <para>
+ <citetitle>JGroups configuration</citetitle>
+ </para>
+ <para>
+ It's recommended to use "multiplexer stack" feature present
in JGroups. It is set by default in eXo JCR and offers higher performance in cluster,
using less network connections also. If there are two or more clusters in your network,
please check that they use different ports and different cluster names.
+ </para>
+ <para>
+ <citetitle>Write performance in cluster</citetitle>
+ </para>
+ <para>
+ Exo JCR implementation uses Lucene indexing engine to provide search
capabilities. But Lucene brings some limitations for write operations: it can perform
indexing only in one thread. Thats why write performance in cluster is not higher than in
singleton environment. Data is indexed on coordinator node, so increasing write-load on
cluster may lead to ReplicationTimeout exception. It occurs because writing threads queue
in the indexer and under high load timeout for replication to coordinator will be
exceeded.
+ </para>
+ <para>
+ Taking in consideration this fact, it is recommended to exceed
<parameter>replTimeout</parameter> value in cache configurations in case of
high write-load.
+ </para>
+ <para>
+ <citetitle>Replication timeout</citetitle>
+ </para>
+ <para>
+ Some operations may take too much time. So if you get
<exceptionname>ReplicationTimeoutException</exceptionname> try increasing
replication timeout:
+ </para>
+
<programlisting language="XML" role="XML"> <clustering
mode="replication" clusterName="${jbosscache-cluster-name}">
...
<sync replTimeout="60000" />
</clustering>
</programlisting>
- <para>
- value is set in miliseconds.
- </para>
+ <para>
+ value is set in miliseconds.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Performance_Tuning_Guide-JVM_parameters">
- <title>JVM parameters</title>
- <para>
- <citetitle>PermGen space size</citetitle>
- </para>
- <para>
- If you intend to use Infinispan, you will have to increase the PermGen size to at
least 256 Mo due to the latest versions of JGroups that are needed by Infinispan (please
note that Infinspan is only dedicated to the community for now, no support will be
provided). In case, you intend to use JBoss Cache, you can keep on using JGroups 2.6.13.GA
which means that you don't need to increase the PermGen size.
- </para>
+ </section>
+
+ <!-- <section
id="sect-Reference_Guide-Performance_Tuning_Guide-JVM_parameters">
+ <title>JVM parameters</title>
+ <para>
+ <citetitle>PermGen space size</citetitle>
+ </para>
+ <para>
+ If you intend to use Infinispan, you will have to increase the PermGen
size to at least 256 Mo due to the latest versions of JGroups that are needed by
Infinispan (please note that Infinspan is only dedicated to the community for now, no
support will be provided). In case, you intend to use JBoss Cache, you can keep on using
JGroups 2.6.13.GA which means that you don't need to increase the PermGen size.
+ </para>
- </section>
-
+ </section>-->
+
- </section>
+ </section>
</section>
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/query-handler-config.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/query-handler-config.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/query-handler-config.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -4,62 +4,50 @@
%BOOK_ENTITIES;
]>
<section id="sect-Reference_Guide-QueryHandler_configuration">
- <title>QueryHandler configuration</title>
- <section
id="sect-Reference_Guide-QueryHandler_configuration-Indexing_in_clustered_environment">
- <title>Indexing in clustered environment</title>
- <para>
- JCR offers multiple indexing strategies. They include both for standalone and
clustered environments using the advantages of running in a single JVM or doing the best
to use all resources available in cluster. JCR uses Lucene library as underlying search
and indexing engine, but it has several limitations that greatly reduce possibilities and
limits the usage of cluster advantages. That's why eXo JCR offers three strategies
that are suitable for it's own usecases. They are standalone, clustered with shared
index and clustered with local indexes. Each one has it's pros and cons.
- </para>
- <para>
- Stanadlone strategy provides a stack of indexes to achieve greater performance within
single JVM.
- </para>
- <mediaobject>
- <imageobject>
- <imagedata align="center"
fileref="images/eXoJCR/diagram-standalone-index.png" />
- </imageobject>
+ <title>QueryHandler configuration</title>
+ <section
id="sect-Reference_Guide-QueryHandler_configuration-Indexing_in_clustered_environment">
+ <title>Indexing in clustered environment</title>
+ <para>
+ JCR offers indexing strategies for clustered environments using the
advantages of running in a single JVM or doing the best to use all resources available in
cluster. JCR uses Lucene library as underlying search and indexing engine, but it has
several limitations that greatly reduce possibilities and limits the usage of cluster
advantages. That's why eXo JCR offers two strategies that are suitable for it's
own usecases. They are clustered with shared index and clustered with local indexes. Each
one has it's pros and cons.
+ </para>
+ <para>
+ Clustered implementation with local indexes combines in-memory buffer index
directory with delayed file-system flushing. This index is called "Volatile" and
it is invoked in searches also. Within some conditions volatile index is flushed to the
persistent storage (file system) as new index directory. This allows to achieve great
results for write operations.
+ </para>
+ <mediaobject>
+ <imageobject>
+ <imagedata align="center"
fileref="images/eXoJCR/diagram-local-index.png" width="444" />
+ </imageobject>
- </mediaobject>
- <para>
- It combines in-memory buffer index directory with delayed file-system flushing. This
index is called "Volatile" and it is invoked in searches also. Within some
conditions volatile index is flushed to the persistent storage (file system) as new index
directory. This allows to achieve great results for write operations.
- </para>
- <para>
- Clustered implementation with local indexes is built upon same strategy with volatile
in-memory index buffer along with delayed flushing on persistent storage.
- </para>
- <mediaobject>
- <imageobject>
- <imagedata align="center"
fileref="images/eXoJCR/diagram-local-index.png" width="444" />
- </imageobject>
+ </mediaobject>
+ <para>
+ As this implementation designed for clustered environment it has additional
mechanisms for data delivery within cluster. Actual text extraction jobs done on the same
node that does content operations (i.e. write operation). Prepared "documents"
(Lucene term that means block of data ready for indexing) are replicated withing cluster
nodes and processed by local indexes. So each cluster instance has the same index content.
When new node joins the cluster it has no initial index, so it must be created. There are
some supported ways of doing this operation. The simplest is to simply copy the index
manually but this is not intended for use. If no initial index found JCR uses automated
sceneries. They are controlled via configuration (see "index-recovery-mode"
parameter) offering full re-indexing from database or copying from another cluster node.
+ </para>
+ <para>
+ For some reasons having a multiple index copies on each instance can be
costly. So shared index can be used instead (see diagram below).
+ </para>
+ <mediaobject>
+ <imageobject>
+ <imagedata align="center"
fileref="images/eXoJCR/diagram-shared-index.png" width="444" />
+ </imageobject>
- </mediaobject>
- <para>
- As this implementation designed for clustered environment it has additional mechanisms
for data delivery within cluster. Actual text extraction jobs done on the same node that
does content operations (i.e. write operation). Prepared "documents" (Lucene
term that means block of data ready for indexing) are replicated withing cluster nodes and
processed by local indexes. So each cluster instance has the same index content. When new
node joins the cluster it has no initial index, so it must be created. There are some
supported ways of doing this operation. The simplest is to simply copy the index manually
but this is not intended for use. If no initial index found JCR uses automated sceneries.
They are controlled via configuration (see "index-recovery-mode" parameter)
offering full re-indexing from database or copying from another cluster node.
- </para>
- <para>
- For some reasons having a multiple index copies on each instance can be costly. So
shared index can be used instead (see diagram below).
- </para>
- <mediaobject>
- <imageobject>
- <imagedata align="center"
fileref="images/eXoJCR/diagram-shared-index.png" width="444" />
- </imageobject>
+ </mediaobject>
+ <para>
+ This indexing strategy combines advantages of in-memory index along with
shared persistent index offering "near" real time search capabilities. This
means that newly added content is accessible via search practically immediately. This
strategy allows nodes to index data in their own volatile (in-memory) indexes, but
persistent indexes are managed by single "coordinator" node only. Each cluster
instance has a read access for shared index to perform queries combining search results
found in own in-memory index also. Take in account that shared folder must be configured
in your system environment (i.e. mounted NFS folder). But this strategy in some extremely
rare cases can have a bit different volatile indexes within cluster instances for a while.
In a few seconds they will be up2date.
+ </para>
+ <para>
+ See more about <xref
linkend="sect-Reference_Guide-Search_Configuration" />.
+ </para>
- </mediaobject>
- <para>
- This indexing strategy combines advantages of in-memory index along with shared
persistent index offering "near" real time search capabilities. This means that
newly added content is accessible via search practically immediately. This strategy allows
nodes to index data in their own volatile (in-memory) indexes, but persistent indexes are
managed by single "coordinator" node only. Each cluster instance has a read
access for shared index to perform queries combining search results found in own in-memory
index also. Take in account that shared folder must be configured in your system
environment (i.e. mounted NFS folder). But this strategy in some extremely rare cases can
have a bit different volatile indexes within cluster instances for a while. In a few
seconds they will be up2date.
- </para>
- <para>
- See more about <xref linkend="sect-Reference_Guide-Search_Configuration"
/>.
- </para>
-
- </section>
-
- <section
id="sect-Reference_Guide-QueryHandler_configuration-Configuration">
- <title>Configuration</title>
- <section
id="sect-Reference_Guide-Configuration-Query_handler_configuration_overview">
- <title>Query-handler configuration overview</title>
- <para>
- Configuration example:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-QueryHandler_configuration-Configuration">
+ <title>Configuration</title>
+ <section
id="sect-Reference_Guide-Configuration-Query_handler_configuration_overview">
+ <title>Query-handler configuration overview</title>
+ <para>
+ Configuration example:
+ </para>
+
<programlisting language="XML" role="XML"><workspace
name="ws">
<query-handler
class="org.exoplatform.services.jcr.impl.core.query.lucene.SearchIndex">
<properties>
@@ -78,150 +66,130 @@
</query-handler>
</workspace>
</programlisting>
- <table
id="tabl-Reference_Guide-Query_handler_configuration_overview-Config_properties_description">
- <title>Config properties description</title>
- <tgroup cols="2">
- <thead>
- <row>
- <entry>
- Property name
- </entry>
- <entry>
- Description
- </entry>
+ <table
id="tabl-Reference_Guide-Query_handler_configuration_overview-Config_properties_description">
+ <title>Config properties description</title>
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>
+ Property name
+ </entry>
+ <entry>
+ Description
+ </entry>
- </row>
+ </row>
- </thead>
- <tbody>
- <row>
- <entry>
- index-dir
- </entry>
- <entry>
- path to index
- </entry>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+ index-dir
+ </entry>
+ <entry>
+ path to index
+ </entry>
- </row>
- <row>
- <entry>
- changesfilter-class
- </entry>
- <entry>
- template of JBoss-cache configuration for all query-handlers in repository
- </entry>
+ </row>
+ <row>
+ <entry>
+ changesfilter-class
+ </entry>
+ <entry>
+ template of JBoss-cache configuration for all
query-handlers in repository
+ </entry>
- </row>
- <row>
- <entry>
- jbosscache-configuration
- </entry>
- <entry>
- template of JBoss-cache configuration for all query-handlers in repository
- </entry>
+ </row>
+ <row>
+ <entry>
+ jbosscache-configuration
+ </entry>
+ <entry>
+ template of JBoss-cache configuration for all
query-handlers in repository
+ </entry>
- </row>
- <row>
- <entry>
- jgroups-configuration
- </entry>
- <entry>
- jgroups-configuration is template configuration for all components (search,
cache, locks) [Add link to document describing template configurations]
- </entry>
+ </row>
+ <row>
+ <entry>
+ jgroups-configuration
+ </entry>
+ <entry>
+ jgroups-configuration is template configuration for all
components (search, cache, locks) [Add link to document describing template
configurations]
+ </entry>
- </row>
- <row>
- <entry>
- jgroups-multiplexer-stack
- </entry>
- <entry>
- [TODO about jgroups-multiplexer-stack - add link to JBoss doc]
- </entry>
+ </row>
+ <row>
+ <entry>
+ jgroups-multiplexer-stack
+ </entry>
+ <entry>
+ [TODO about jgroups-multiplexer-stack - add link to JBoss
doc]
+ </entry>
- </row>
- <row>
- <entry>
- jbosscache-cluster-name
- </entry>
- <entry>
- cluster name (must be unique)
- </entry>
+ </row>
+ <row>
+ <entry>
+ jbosscache-cluster-name
+ </entry>
+ <entry>
+ cluster name (must be unique)
+ </entry>
- </row>
- <row>
- <entry>
- max-volatile-time
- </entry>
- <entry>
- max time to live for Volatile Index
- </entry>
+ </row>
+ <row>
+ <entry>
+ max-volatile-time
+ </entry>
+ <entry>
+ max time to live for Volatile Index
+ </entry>
- </row>
- <row>
- <entry>
- rdbms-reindexing
- </entry>
- <entry>
- indicate that need to use rdbms reindexing mechanism if possible, the default
value is true
- </entry>
+ </row>
+ <row>
+ <entry>
+ rdbms-reindexing
+ </entry>
+ <entry>
+ indicate that need to use rdbms reindexing mechanism if
possible, the default value is true
+ </entry>
- </row>
- <row>
- <entry>
- reindexing-page-size
- </entry>
- <entry>
- maximum amount of nodes which can be retrieved from storage for re-indexing
purpose, the default value is 100
- </entry>
+ </row>
+ <row>
+ <entry>
+ reindexing-page-size
+ </entry>
+ <entry>
+ maximum amount of nodes which can be retrieved from
storage for re-indexing purpose, the default value is 100
+ </entry>
- </row>
- <row>
- <entry>
- index-recovery-mode
- </entry>
- <entry>
- If the parameter has been set to <command>from-indexing</command>, so
a full indexing will be automatically launched (default behavior), if the parameter has
been set to <command>from-coordinator</command>, the index will be retrieved
from coordinator
- </entry>
+ </row>
+ <row>
+ <entry>
+ index-recovery-mode
+ </entry>
+ <entry>
+ If the parameter has been set to
<command>from-indexing</command>, so a full indexing will be automatically
launched (default behavior), if the parameter has been set to
<command>from-coordinator</command>, the index will be retrieved from
coordinator
+ </entry>
- </row>
+ </row>
- </tbody>
+ </tbody>
- </tgroup>
+ </tgroup>
- </table>
+ </table>
- </section>
-
- <section id="sect-Reference_Guide-Configuration-Standalone_strategy">
- <title>Standalone strategy</title>
- <para>
- When running JCR in standalone usually standalone indexing is used also. Such
parameters as "changesfilter-class", "jgroups-configuration" and all
the "jbosscache-*" must be skipped and not defined. Like the configuration
below.
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-Configuration-Cluster_ready_indexing_strategies">
+ <title>Cluster-ready indexing strategies</title>
+ <para>
+ For both cluster-ready implementations JBoss Cache, JGroups and Changes
Filter values must be defined. Shared index requires some kind of remote or shared file
system to be attached in a system (i.e. NFS, SMB or etc). Indexing directory
("indexDir" value) must point to it. Setting "changesfilter-class" to
"org.exoplatform.services.jcr.impl.core.query.jbosscache.JBossCacheIndexChangesFilter"
will enable shared index implementation.
+ </para>
+
<programlisting language="XML" role="XML"><workspace
name="ws">
<query-handler
class="org.exoplatform.services.jcr.impl.core.query.lucene.SearchIndex">
<properties>
- <property name="index-dir"
value="shareddir/index/db1/ws" />
- <property name="max-volatile-time" value="60"
/>
- <property name="rdbms-reindexing" value="true"
/>
- <property name="reindexing-page-size" value="1000"
/>
- <property name="index-recovery-mode"
value="from-coordinator" />
- </properties>
- </query-handler>
-</workspace></programlisting>
-
- </section>
-
- <section
id="sect-Reference_Guide-Configuration-Cluster_ready_indexing_strategies">
- <title>Cluster-ready indexing strategies</title>
- <para>
- For both cluster-ready implementations JBoss Cache, JGroups and Changes Filter values
must be defined. Shared index requires some kind of remote or shared file system to be
attached in a system (i.e. NFS, SMB or etc). Indexing directory ("indexDir"
value) must point to it. Setting "changesfilter-class" to
"org.exoplatform.services.jcr.impl.core.query.jbosscache.JBossCacheIndexChangesFilter"
will enable shared index implementation.
- </para>
-
-<programlisting language="XML" role="XML"><workspace
name="ws">
- <query-handler
class="org.exoplatform.services.jcr.impl.core.query.lucene.SearchIndex">
- <properties>
<property name="index-dir"
value="/mnt/nfs_drive/index/db1/ws" />
<property name="changesfilter-class"
value="org.exoplatform.services.jcr.impl.core.query.jbosscache.JBossCacheIndexChangesFilter"
/>
@@ -236,10 +204,10 @@
</properties>
</query-handler>
</workspace></programlisting>
- <para>
- In order to use cluster-ready strategy based on local indexes, when each node has own
copy of index on local file system, the following configuration must be applied. Indexing
directory must point to any folder on local file system and
"changesfilter-class" must be set to
"org.exoplatform.services.jcr.impl.core.query.jbosscache.LocalIndexChangesFilter".
- </para>
-
+ <para>
+ In order to use cluster-ready strategy based on local indexes, when each
node has own copy of index on local file system, the following configuration must be
applied. Indexing directory must point to any folder on local file system and
"changesfilter-class" must be set to
"org.exoplatform.services.jcr.impl.core.query.jbosscache.LocalIndexChangesFilter".
+ </para>
+
<programlisting language="XML" role="XML"><workspace
name="ws">
<query-handler
class="org.exoplatform.services.jcr.impl.core.query.lucene.SearchIndex">
<properties>
@@ -259,24 +227,24 @@
</workspace>
</programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-Configuration-JBoss_Cache_template_configuration">
- <title>JBoss-Cache template configuration</title>
- <para>
- JBoss-Cache template configuration for query handler is about the same for both
clustered strategies.
- </para>
- <para>
- jbosscache-indexer.xml
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-Configuration-JBoss_Cache_template_configuration">
+ <title>JBoss-Cache template configuration</title>
+ <para>
+ JBoss-Cache template configuration for query handler is about the same
for both clustered strategies.
+ </para>
+ <para>
+ jbosscache-indexer.xml
+ </para>
+
<programlisting language="XML" role="XML"><?xml
version="1.0" encoding="UTF-8"?>
<jbosscache
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:jboss:jbosscache-core:config:3.1">
<locking useLockStriping="false" concurrencyLevel="50000"
lockParentForChildInsertRemove="false"
lockAcquisitionTimeout="20000" />
<!-- Configure the TransactionManager -->
- <transaction
transactionManagerLookupClass="org.jboss.cache.transaction.JBossStandaloneJTAManagerLookup"
/>
+ <transaction
transactionManagerLookupClass="org.jboss.cache.transaction.JBoss<remark>Standalone</remark>JTAManagerLookup"
/>
<clustering mode="replication"
clusterName="${jbosscache-cluster-name}">
<stateRetrieval timeout="20000"
fetchInMemoryState="false" />
@@ -292,14 +260,14 @@
</eviction>
</jbosscache></programlisting>
- <para>
- See more about template configurations <xref
linkend="sect-Reference_Guide-JBoss_Cache_configuration" />.
- </para>
+ <para>
+ See more about template configurations <xref
linkend="sect-Reference_Guide-JBoss_Cache_configuration" />.
+ </para>
- </section>
-
+ </section>
+
- </section>
+ </section>
</section>
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/repository-creation-service.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/repository-creation-service.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/repository-creation-service.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -4,85 +4,79 @@
%BOOK_ENTITIES;
]>
<section id="sect-Reference_Guide-RepositoryCreationService">
- <title>RepositoryCreationService</title>
- <section id="sect-Reference_Guide-RepositoryCreationService-Intro">
- <title>Intro</title>
- <para>
- RepositoryCreationService is the service for creation repositories in runtime. The
service can be used in standalone or cluster environment.
- </para>
+ <title>RepositoryCreationService</title>
+ <section id="sect-Reference_Guide-RepositoryCreationService-Intro">
+ <title>Intro</title>
+ <para>
+ RepositoryCreationService is the service for creation repositories in
runtime.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-RepositoryCreationService-Dependencies">
- <title>Dependencies</title>
- <para>
- RepositoryConfigurationService depends to next components:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <xref linkend="sect-Reference_Guide-Database_Creator" /> - DBCreator
used to create new database for each unbinded datasource.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-RepositoryCreationService-Dependencies">
+ <title>Dependencies</title>
+ <para>
+ RepositoryConfigurationService depends to next components:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <xref linkend="sect-Reference_Guide-Database_Creator"
/> - DBCreator used to create new database for each unbinded datasource.
+ </para>
- </listitem>
- <listitem>
- <para>
- <xref linkend="sect-Reference_Guide-eXo_JCR_Backup_Service" /> -
BackupManager used to created repository from backup.
- </para>
+ </listitem>
+ <!--<listitem>
+ <para>
+ <xref
linkend="sect-Reference_Guide-eXo_JCR_Backup_Service" /> - BackupManager used
to created repository from backup.
+ </para>
- </listitem>
- <listitem>
- <para>
- <xref linkend="sect-Reference_Guide-RPC_Service" /> - RPCService
used for communication between cluster-nodes
- </para>
- <note>
- <para>
- RPCService may not be configured - in this case, RepositoryService will work as
standalone service.
- </para>
+ </listitem>-->
+ <listitem>
+ <para>
+ <xref linkend="sect-Reference_Guide-RPC_Service" /> -
RPCService used for communication between cluster-nodes
+ </para>
- </note>
+ </listitem>
- </listitem>
+ </itemizedlist>
- </itemizedlist>
+ </section>
+
+ <section
id="sect-Reference_Guide-RepositoryCreationService-How_it_works">
+ <title>How it works</title>
+ <itemizedlist>
+ <listitem>
+ <para>
+ User executes reserveRepositoryName(String repositoryName) -
client-node calls coordinator-node to reserve repositoryName. If this name is already
reserved or repository with this name exist, client-node will fetch
RepositoryCreationException. If not Client will get token string.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-RepositoryCreationService-How_it_works">
- <title>How it works</title>
- <itemizedlist>
- <listitem>
- <para>
- User executes reserveRepositoryName(String repositoryName) - client-node calls
coordinator-node to reserve repositoryName. If this name is already reserved or repository
with this name exist, client-node will fetch RepositoryCreationException. If not Client
will get token string.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ than user executes createRepository(String backupId, RepositoryEntry
rEntry, String token). Coordinator-node checks the token, and creates Repository.
+ </para>
- </listitem>
- <listitem>
- <para>
- than user executes createRepository(String backupId, RepositoryEntry rEntry, String
token). Coordinator-node checks the token, and creates Repository.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ whan repository become created - user-node broadcast message to all
clusterNodes with RepositoryEntry, so each cluster node starts new Repository.
+ </para>
- </listitem>
- <listitem>
- <para>
- whan repository become created - user-node broadcast message to all clusterNodes
with RepositoryEntry, so each cluster node starts new Repository.
- </para>
+ </listitem>
- </listitem>
+ </itemizedlist>
+ <para>
+ There is two ways to create repositry: make it in single step - just call
createRepository(String backupId, RepositoryEntry); or reserve repositoryName at first
(reserveRepositoryName(String repositoryName)), than create reserved repository
(createRepository(String backupId, RepositoryEntry rEntry, String token)).
+ </para>
- </itemizedlist>
- <para>
- There is two ways to create repositry: make it in single step - just call
createRepository(String backupId, RepositoryEntry); or reserve repositoryName at first
(reserveRepositoryName(String repositoryName)), than create reserved repository
(createRepository(String backupId, RepositoryEntry rEntry, String token)).
- </para>
-
- </section>
-
- <section
id="sect-Reference_Guide-RepositoryCreationService-Configuration">
- <title>Configuration</title>
- <para>
- RepositoryCreationService configuration
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-RepositoryCreationService-Configuration">
+ <title>Configuration</title>
+ <para>
+ RepositoryCreationService configuration
+ </para>
+
<programlisting language="XML"
role="XML"><component>
<key>org.exoplatform.services.jcr.ext.backup.BackupManager</key>
<type>org.exoplatform.services.jcr.ext.backup.impl.BackupManagerImpl</type>
@@ -125,7 +119,7 @@
<init-params>
<value-param>
<name>jgroups-configuration</name>
- <value>jar:/conf/standalone/udp-mux.xml</value>
+ <value>jar:/conf/cluster/udp-mux.xml</value>
</value-param>
<value-param>
<name>jgroups-cluster-name</name>
@@ -150,21 +144,21 @@
</value-param>
</init-params>
</component></programlisting>
- <itemizedlist>
- <listitem>
- <para>
- factory-class-name - is not mandatory parameter, indicates what the factory need to
use to create DataSource objects
- </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ factory-class-name - is not mandatory parameter, indicates what the
factory need to use to create DataSource objects
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
- </section>
-
- <section
id="sect-Reference_Guide-RepositoryCreationService-RepositoryCreationService_Interface">
- <title>RepositoryCreationService Interface</title>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-RepositoryCreationService-RepositoryCreationService_Interface">
+ <title>RepositoryCreationService Interface</title>
+
<programlisting language="Java" role="Java">public interface
RepositoryCreationService
{
/**
@@ -247,28 +241,16 @@
}</programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-RepositoryCreationService-Conclusions_and_restrictions">
- <title>Conclusions and restrictions</title>
- <itemizedlist>
- <listitem>
- <para>
- Each datasource in RepositoryEntry of new Repository must have unbinded datasources.
Thats mean, such datasource must have not databases behind them. This restriction exists
to avoid corruption of existing repositories data.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-RepositoryCreationService-Conclusions_and_restrictions">
+ <title>Conclusions and restrictions</title>
+ <para>
+ Each datasource in RepositoryEntry of new Repository must have
unbinded datasources. Thats mean, such datasource must have not databases behind them.
This restriction exists to avoid corruption of existing repositories data.
+ </para>
- </listitem>
- <listitem>
- <para>
- RPCService is optional component, but without it, RepositoryCreatorService can not
communicate with other cluster-nodes and works as standalone.
- </para>
+ </section>
- </listitem>
-
- </itemizedlist>
-
- </section>
-
</section>
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/transaction-manager-lookup.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/transaction-manager-lookup.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr/transaction-manager-lookup.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -4,23 +4,19 @@
%BOOK_ENTITIES;
]>
<section id="sect-Reference_Guide-TransactionManagerLookup">
- <title>TransactionManagerLookup</title>
- <section
id="sect-Reference_Guide-TransactionManagerLookup-Configuration">
- <title>Configuration</title>
- <para>
- It's JBossCache class registered as eXo container component in configuration.xml
file.
- </para>
-
+ <title>TransactionManagerLookup</title>
+ <section
id="sect-Reference_Guide-TransactionManagerLookup-Configuration">
+ <title>Configuration</title>
+ <para>
+ It's JBossCache class registered as eXo container component in
configuration.xml file.
+ </para>
+
<programlisting language="XML" role="XML">
<component>
<key>org.jboss.cache.transaction.TransactionManagerLookup</key>
-
<type>org.jboss.cache.transaction.JBossStandaloneJTAManagerLookup</type>
+
<type>org.jboss.cache.transaction.GenericTransactionManagerLookup</type>
</component></programlisting>
- <para>
- JBossStandaloneJTAManagerLookup used in standalone environment. Bur for Application
Server environment use GenericTransactionManagerLookup.
- </para>
+ </section>
- </section>
-
</section>
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr-with-gtn/how-to-extend-my-gatein-instance.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr-with-gtn/how-to-extend-my-gatein-instance.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr-with-gtn/how-to-extend-my-gatein-instance.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -4,207 +4,207 @@
%BOOK_ENTITIES;
]>
<section id="sect-Reference_Guide-How_to_extend_my_GateIn_instance">
- <title>How to extend my GateIn instance?</title>
- <section
id="sect-Reference_Guide-How_to_extend_my_GateIn_instance-Introduction">
- <title>Introduction</title>
- <section id="sect-Reference_Guide-Introduction-Overview">
- <title>Overview</title>
- <para>
- Since GateIn beta 2, we added a set of features in order to customize a GateIn
instance without modifying the GateIn binary, this usecase will be called
<emphasis>portal extension</emphasis> in this documentation. Those features
are also required to be able to launch several portal instances at the same time, in
"eXo terminology" that means to have several "portal.war".
- </para>
+ <title>How to extend my GateIn instance?</title>
+ <section
id="sect-Reference_Guide-How_to_extend_my_GateIn_instance-Introduction">
+ <title>Introduction</title>
+ <section id="sect-Reference_Guide-Introduction-Overview">
+ <title>Overview</title>
+ <para>
+ Since GateIn beta 2, we added a set of features in order to customize a
GateIn instance without modifying the GateIn binary, this usecase will be called
<emphasis>portal extension</emphasis> in this documentation. Those features
are also required to be able to launch several portal instances at the same time, in
"eXo terminology" that means to have several "portal.war".
+ </para>
- </section>
-
- <section id="sect-Reference_Guide-Introduction-Motivations">
- <title>Motivations</title>
- <para>
- Up to now, to create an application over an eXo portal such as DMS, WCM, CS and KS,
we need to modify files into the "portal.war". This has many painful
consequences, such as:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- It is quite hard to manage from the support point of view since we never know if or
how the customer changed his eXo product.
- </para>
+ </section>
+
+ <section id="sect-Reference_Guide-Introduction-Motivations">
+ <title>Motivations</title>
+ <para>
+ Up to now, to create an application over an eXo portal such as DMS, WCM,
CS and KS, we need to modify files into the "portal.war". This has many painful
consequences, such as:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ It is quite hard to manage from the support point of view since
we never know if or how the customer changed his eXo product.
+ </para>
- </listitem>
- <listitem>
- <para>
- It is hard to be able to package several eXo products (WCM, CS...) as we need to
merge everything manually which is quite error prone.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ It is hard to be able to package several eXo products (WCM,
CS...) as we need to merge everything manually which is quite error prone.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- Finally, at the very beginning, eXo was developed to be able to support several
portal instances (which also means several portal containers) but with the time several
bad practices made it impossible. So it was important to review the whole code base in
order to help/enforce all the GateIn developers to follow the "good practices".
- </para>
+ </itemizedlist>
+ <para>
+ Finally, at the very beginning, eXo was developed to be able to support
several portal instances (which also means several portal containers) but with the time
several bad practices made it impossible. So it was important to review the whole code
base in order to help/enforce all the GateIn developers to follow the "good
practices".
+ </para>
- </section>
-
+ </section>
+
- </section>
-
- <section
id="sect-Reference_Guide-How_to_extend_my_GateIn_instance-Prerequisites">
- <title>Prerequisites</title>
- <para>
- To be able to migrate an application to GateIn, the first thing we need to do is to
ensure that our application supports properly several portal container instances. The
following section aims to help you to be compatible with GateIn.
- </para>
- <section
id="sect-Reference_Guide-Prerequisites-Removing_all_the_hard_coded_portal_container_name_i.e._portal">
- <title>Removing all the hard coded portal container name (i.e.
"portal")</title>
- <para>
- Now if we need to get the portal container name (even in a standalone mode: in case
of standalone mode the default value will be returned), we can:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- If the component is instantiated by Pico container, you can add in the constructor
of your component, the component <emphasis>ExoContainerContext</emphasis>,
then call the method <emphasis>getPortalContainerName()</emphasis>
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-How_to_extend_my_GateIn_instance-Prerequisites">
+ <title>Prerequisites</title>
+ <para>
+ To be able to migrate an application to GateIn, the first thing we need to do
is to ensure that our application supports properly several portal container instances.
The following section aims to help you to be compatible with GateIn.
+ </para>
+ <section
id="sect-Reference_Guide-Prerequisites-Removing_all_the_hard_coded_portal_container_name_i.e._portal">
+ <title>Removing all the hard coded portal container name (i.e.
"portal")</title>
+ <para>
+ Now if we need to get the portal container name we can:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ If the component is instantiated by Pico container, you can add
in the constructor of your component, the component
<emphasis>ExoContainerContext</emphasis>, then call the method
<emphasis>getPortalContainerName()</emphasis>
+ </para>
- </listitem>
- <listitem>
- <para>
- If the component is not instantiated by Pico container, you can call at runtime the
static method
<emphasis>PortalContainer.getCurrentPortalContainerName()</emphasis>
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ If the component is not instantiated by Pico container, you can
call at runtime the static method
<emphasis>PortalContainer.getCurrentPortalContainerName()</emphasis>
+ </para>
- </listitem>
- <listitem>
- <para>
- In js files, you can use the variable
<emphasis>currentContext</emphasis> if your script must be loaded before the
variable <emphasis>eXo.env.server.context</emphasis>, otherwise use
<emphasis>eXo.env.server.context</emphasis> instead.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ In js files, you can use the variable
<emphasis>currentContext</emphasis> if your script must be loaded before the
variable <emphasis>eXo.env.server.context</emphasis>, otherwise use
<emphasis>eXo.env.server.context</emphasis> instead.
+ </para>
- </listitem>
- <listitem>
- <para>
- In jsp files, you can use
<emphasis>request.getContextPath()</emphasis>.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ In jsp files, you can use
<emphasis>request.getContextPath()</emphasis>.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
- </section>
-
- <section
id="sect-Reference_Guide-Prerequisites-Removing_all_the_hard_coded_rest_context_name_i.e._rest">
- <title>Removing all the hard coded rest context name (i.e.
"rest")</title>
- <para>
- Now if we need to get the rest context name (even in a standalone mode: in case of
standalone mode the default value will be returned), we can:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- If the component is instantiated by Pico container, you can add in the constructor
of your component, the component <emphasis>ExoContainerContext</emphasis>,
then call the method <emphasis>getRestContextName()</emphasis>
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Prerequisites-Removing_all_the_hard_coded_rest_context_name_i.e._rest">
+ <title>Removing all the hard coded rest context name (i.e.
"rest")</title>
+ <para>
+ Now if we need to get the rest context name we can:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ If the component is instantiated by Pico container, you can add
in the constructor of your component, the component
<emphasis>ExoContainerContext</emphasis>, then call the method
<emphasis>getRestContextName()</emphasis>
+ </para>
- </listitem>
- <listitem>
- <para>
- If the component is not instantiated by Pico container, you can call at runtime the
static method
<emphasis>PortalContainer.getCurrentRestContextName()</emphasis>
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ If the component is not instantiated by Pico container, you can
call at runtime the static method
<emphasis>PortalContainer.getCurrentRestContextName()</emphasis>
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
- </section>
-
- <section
id="sect-Reference_Guide-Prerequisites-Removing_all_the_hard_coded_realm_name_i.e._exo_domain">
- <title>Removing all the hard coded realm name (i.e.
"exo-domain")</title>
- <para>
- Now if we need to get the realm name (even in a standalone mode: in case of
standalone mode the default value will be returned), we can:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- If the component is instantiated by Pico container, you can add in the constructor
of your component, the component <emphasis>ExoContainerContext</emphasis>,
then call the method <emphasis>getRealmName()</emphasis>
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Prerequisites-Removing_all_the_hard_coded_realm_name_i.e._exo_domain">
+ <title>Removing all the hard coded realm name (i.e.
"exo-domain")</title>
+ <para>
+ Now if we need to get the realm name we can:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ If the component is instantiated by Pico container, you can add
in the constructor of your component, the component
<emphasis>ExoContainerContext</emphasis>, then call the method
<emphasis>getRealmName()</emphasis>
+ </para>
- </listitem>
- <listitem>
- <para>
- If the component is not instantiated by Pico container, you can call at runtime the
static method <emphasis>PortalContainer.getCurrentRealmName()</emphasis>
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ If the component is not instantiated by Pico container, you can
call at runtime the static method
<emphasis>PortalContainer.getCurrentRealmName()</emphasis>
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
- </section>
-
- <section
id="sect-Reference_Guide-Prerequisites-Making_your_Http_Filters_compatible">
- <title>Making your Http Filters compatible</title>
- <para>
- Now all your Http Filters that need to get the current
<emphasis>ExoContainer</emphasis> must extends
<emphasis>org.exoplatform.container.web.AbstractFilter</emphasis>. You just
need to call the method <emphasis>getContainer()</emphasis> to get the current
<emphasis>ExoContainer</emphasis>.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Prerequisites-Making_your_Http_Filters_compatible">
+ <title>Making your Http Filters compatible</title>
+ <para>
+ Now all your Http Filters that need to get the current
<emphasis>ExoContainer</emphasis> must extends
<emphasis>org.exoplatform.container.web.AbstractFilter</emphasis>. You just
need to call the method <emphasis>getContainer()</emphasis> to get the current
<emphasis>ExoContainer</emphasis>.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Prerequisites-Making_your_HttpServlets_compatible">
- <title>Making your HttpServlets compatible</title>
- <para>
- Now all your HttpServlets that need to get the current
<emphasis>ExoContainer</emphasis> must extends
<emphasis>org.exoplatform.container.web.AbstractHttpServlet</emphasis>. This
abstract class will ensure that the environment has been properly set, so you will be able
to call the usual methods such as
<emphasis>ExoContainerContext.getCurrentContainer()</emphasis> (if it must
also be compatible with the standalone mode) or
<emphasis>PortalContainer.getInstance()</emphasis> (if it will only work on a
portal environment mode).
- </para>
- <para>
- If you had to implement the method <emphasis>service(HttpServletRequest req,
HttpServletResponse res)</emphasis>, now you will need to implement
<emphasis>onService(ExoContainer container, HttpServletRequest req,
HttpServletResponse res)</emphasis>, this method will directly give you the current
<emphasis>ExoContainer</emphasis> in its signature.
- </para>
- <important>
- <title>Useful Information</title>
- <para>
- In the class
<emphasis>org.exoplatform.container.web.AbstractHttpServlet</emphasis> you
have a method called <emphasis>requirePortalEnvironment()</emphasis> that is
used to indicate that we would like the abstract class to setup or not the full portal
environment ( <emphasis>PortalContainer</emphasis>,
<emphasis>ClassLoader</emphasis> and
<emphasis>ServletContext</emphasis>) before executing the servlet. This value
should return true when the servlet is executed within the web application of a portal
container. By default, it checks if the name of the current
<emphasis>ServletContext</emphasis> is a portal container name, it is
sufficient in most of cases but you can still overload this method if you already know
that the servlet will always been executed within the web application of portal container
(i.e. the method always return true) or will never be executed within the web application
of a portal container (i.e. the method always return false) .
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Prerequisites-Making_your_HttpServlets_compatible">
+ <title>Making your HttpServlets compatible</title>
+ <para>
+ Now all your HttpServlets that need to get the current
<emphasis>ExoContainer</emphasis> must extends
<emphasis>org.exoplatform.container.web.AbstractHttpServlet</emphasis>. This
abstract class will ensure that the environment has been properly set, so you will be able
to call the usual methods such as
<emphasis>PortalContainer.getInstance()</emphasis>.
+ </para>
+ <para>
+ If you had to implement the method
<emphasis>service(HttpServletRequest req, HttpServletResponse res)</emphasis>,
now you will need to implement <emphasis>onService(ExoContainer container,
HttpServletRequest req, HttpServletResponse res)</emphasis>, this method will
directly give you the current <emphasis>ExoContainer</emphasis> in its
signature.
+ </para>
+ <important>
+ <title>Useful Information</title>
+ <para>
+ In the class
<emphasis>org.exoplatform.container.web.AbstractHttpServlet</emphasis> you
have a method called <emphasis>requirePortalEnvironment()</emphasis> that is
used to indicate that we would like the abstract class to setup or not the full portal
environment ( <emphasis>PortalContainer</emphasis>,
<emphasis>ClassLoader</emphasis> and
<emphasis>ServletContext</emphasis>) before executing the servlet. This value
should return true when the servlet is executed within the web application of a portal
container. By default, it checks if the name of the current
<emphasis>ServletContext</emphasis> is a portal container name, it is
sufficient in most of cases but you can still overload this method if you already know
that the servlet will always been executed within the web application of portal container
(i.e. the method always return true) or will never be executed within the web application
of a portal container (i.e. the method always return false) .
+ </para>
- </important>
+ </important>
- </section>
-
- <section
id="sect-Reference_Guide-Prerequisites-Making_your_HttpSessionListeners_compatible">
- <title>Making your HttpSessionListeners compatible</title>
- <para>
- Now all your HttpSessionListeners that need to get the current
<emphasis>ExoContainer</emphasis> must extends
<emphasis>org.exoplatform.container.web.AbstractHttpSessionListener</emphasis>.
This abstract class will give you the current
<emphasis>ExoContainer</emphasis> directly in the signature of the methods to
implement which are _ onSessionCreated(ExoContainer container, HttpSessionEvent event)\_
and <emphasis>onSessionDestroyed(ExoContainer container, HttpSessionEvent
event)</emphasis>
- </para>
- <para>
- You will also need to implement the method called
<emphasis>requirePortalEnvironment()</emphasis> that is used to indicate that
we would like the abstract class to setup or not the full portal environment (
<emphasis>PortalContainer</emphasis> and
<emphasis>ClassLoader</emphasis>) before processing the event. This value
should return true when the event is processed within the web application of a portal
container.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Prerequisites-Making_your_HttpSessionListeners_compatible">
+ <title>Making your HttpSessionListeners compatible</title>
+ <para>
+ Now all your HttpSessionListeners that need to get the current
<emphasis>ExoContainer</emphasis> must extends
<emphasis>org.exoplatform.container.web.AbstractHttpSessionListener</emphasis>.
This abstract class will give you the current
<emphasis>ExoContainer</emphasis> directly in the signature of the methods to
implement which are _ onSessionCreated(ExoContainer container, HttpSessionEvent event)\_
and <emphasis>onSessionDestroyed(ExoContainer container, HttpSessionEvent
event)</emphasis>
+ </para>
+ <para>
+ You will also need to implement the method called
<emphasis>requirePortalEnvironment()</emphasis> that is used to indicate that
we would like the abstract class to setup or not the full portal environment (
<emphasis>PortalContainer</emphasis> and
<emphasis>ClassLoader</emphasis>) before processing the event. This value
should return true when the event is processed within the web application of a portal
container.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Prerequisites-Use_init_tasks_if_you_need_a_PortalContainer_to_initialize_an_Http_Filter_or_an_HttpServlet">
- <title>Use init tasks if you need a PortalContainer to initialize an Http Filter
or an HttpServlet</title>
- <para>
- If your Http <emphasis>Filter</emphasis> or your
<emphasis>HttpServlet</emphasis> requires a PortalContainer to initialize, you
need to convert your code in order to launch the code responsible for the initialization
in the method <emphasis>onAlreadyExists</emphasis> of an
<emphasis>org.exoplatform.container.RootContainer.PortalContainerInitTask</emphasis>.
- </para>
- <para>
- We need to rely on init tasks, in order to be sure that the portal container is at
the right state when the task is executed, in other words the task could be delayed if you
try to execute it too early. Each task is linked to a web application, so when we add a
new task, we first retrieve all the portal containers that depend on this web application
according to the <emphasis>PortalContainerDefinitions</emphasis>, and for each
container we add the task in a sorted queue which order is in fact the order of the web
applications dependencies defined in the
<emphasis>PortalContainerDefinition</emphasis>. If no
<emphasis>PortalContainerDefinition</emphasis> can be found we execute
synchronously the task which is in fact the old behavior (i.e. without the starter).
- </para>
- <para>
- The supported init tasks are:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- The
<emphasis>org.exoplatform.container.RootContainer.PortalContainerPreInitTask</emphasis>
which are executed before the portal container has been initialized
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Prerequisites-Use_init_tasks_if_you_need_a_PortalContainer_to_initialize_an_Http_Filter_or_an_HttpServlet">
+ <title>Use init tasks if you need a PortalContainer to initialize an
Http Filter or an HttpServlet</title>
+ <para>
+ If your Http <emphasis>Filter</emphasis> or your
<emphasis>HttpServlet</emphasis> requires a PortalContainer to initialize, you
need to convert your code in order to launch the code responsible for the initialization
in the method <emphasis>onAlreadyExists</emphasis> of an
<emphasis>org.exoplatform.container.RootContainer.PortalContainerInitTask</emphasis>.
+ </para>
+ <para>
+ We need to rely on init tasks, in order to be sure that the portal
container is at the right state when the task is executed, in other words the task could
be delayed if you try to execute it too early. Each task is linked to a web application,
so when we add a new task, we first retrieve all the portal containers that depend on this
web application according to the
<emphasis>PortalContainerDefinitions</emphasis>, and for each container we add
the task in a sorted queue which order is in fact the order of the web applications
dependencies defined in the <emphasis>PortalContainerDefinition</emphasis>. If
no <emphasis>PortalContainerDefinition</emphasis> can be found we execute
synchronously the task which is in fact the old behavior (i.e. without the starter).
+ </para>
+ <para>
+ The supported init tasks are:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The
<emphasis>org.exoplatform.container.RootContainer.PortalContainerPreInitTask</emphasis>
which are executed before the portal container has been initialized
+ </para>
- </listitem>
- <listitem>
- <para>
- The
<emphasis>org.exoplatform.container.RootContainer.PortalContainerPostInitTask</emphasis>
which are executed after the portal container has been initialized
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The
<emphasis>org.exoplatform.container.RootContainer.PortalContainerPostInitTask</emphasis>
which are executed after the portal container has been initialized
+ </para>
- </listitem>
- <listitem>
- <para>
- The
<emphasis>org.exoplatform.container.RootContainer.PortalContainerPostCreateTask</emphasis>
which are executed after the portal container has been fully created (i.e. after all the
post init tasks).
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The
<emphasis>org.exoplatform.container.RootContainer.PortalContainerPostCreateTask</emphasis>
which are executed after the portal container has been fully created (i.e. after all the
post init tasks).
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- An init task is defined as below:
- </para>
- <note>
- <title>PortalContainerPreInitTask</title>
-
+ </itemizedlist>
+ <para>
+ An init task is defined as below:
+ </para>
+ <note>
+ <title>PortalContainerPreInitTask</title>
+
<programlisting language="Java" role="Java"> /**
* This interface is used to define a task that needs to be launched at a given state
during the
* initialization of a portal container
@@ -244,40 +244,40 @@
public String getType();
}</programlisting>
- </note>
- <para>
- To add a task, you can either call:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <emphasis>PortalContainer.addInitTask(ServletContext context,
PortalContainerInitTask task)</emphasis> in order to execute the task on all the
portal containers that depend on the given <emphasis>ServletContext</emphasis>
according to the <emphasis>PortalContainerDefinitions</emphasis>.
- </para>
+ </note>
+ <para>
+ To add a task, you can either call:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <emphasis>PortalContainer.addInitTask(ServletContext
context, PortalContainerInitTask task)</emphasis> in order to execute the task on
all the portal containers that depend on the given
<emphasis>ServletContext</emphasis> according to the
<emphasis>PortalContainerDefinitions</emphasis>.
+ </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>PortalContainer.addInitTask(ServletContext context,
PortalContainerInitTask task, String portalContainerName)</emphasis> in order to
execute the task on a given portal container.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis>PortalContainer.addInitTask(ServletContext
context, PortalContainerInitTask task, String portalContainerName)</emphasis> in
order to execute the task on a given portal container.
+ </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>RootContainer.addInitTask(ServletContext context,
PortalContainerInitTask task)</emphasis> in order to execute the task on the portal
container which name is the name of the given
<emphasis>ServletContext</emphasis>.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis>RootContainer.addInitTask(ServletContext context,
PortalContainerInitTask task)</emphasis> in order to execute the task on the portal
container which name is the name of the given
<emphasis>ServletContext</emphasis>.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- We will take for example the class <emphasis>GadgetRegister</emphasis>
that is used to register new google gadgets on a given portal container.
- </para>
- <para>
- <emphasis role="underline">The old code was:</emphasis>
- </para>
- <note>
- <title>Old GadgetRegister.java</title>
-
+ </itemizedlist>
+ <para>
+ We will take for example the class
<emphasis>GadgetRegister</emphasis> that is used to register new google
gadgets on a given portal container.
+ </para>
+ <para>
+ <emphasis role="underline">The old code
was:</emphasis>
+ </para>
+ <note>
+ <title>Old GadgetRegister.java</title>
+
<programlisting language="Java" role="Java">...
public class GadgetRegister implements ServletContextListener
{
@@ -293,13 +293,13 @@
...
}</programlisting>
- </note>
- <para>
- The new code relies on a
<emphasis>org.exoplatform.container.RootContainer.PortalContainerPostInitTask</emphasis>,
as you can see below
- </para>
- <note>
- <title>New GadgetRegister.java</title>
-
+ </note>
+ <para>
+ The new code relies on a
<emphasis>org.exoplatform.container.RootContainer.PortalContainerPostInitTask</emphasis>,
as you can see below
+ </para>
+ <note>
+ <title>New GadgetRegister.java</title>
+
<programlisting language="Java" role="Java">...
public class GadgetRegister implements ServletContextListener {
...
@@ -328,155 +328,155 @@
...
}</programlisting>
- </note>
+ </note>
- </section>
-
- <section
id="sect-Reference_Guide-Prerequisites-Making_your_LoginModules_compatible">
- <title>Making your LoginModules compatible</title>
- <para>
- Now all your LoginModules that need to get the current
<emphasis>ExoContainer</emphasis> must extends
<emphasis>org.exoplatform.services.security.jaas.AbstractLoginModule</emphasis>.
You just need to call the method <emphasis>getContainer()</emphasis> to get
the current <emphasis>ExoContainer</emphasis>.
- </para>
- <important>
- <title>Useful Information</title>
- <para>
- The class
<emphasis>org.exoplatform.services.security.jaas.AbstractLoginModule</emphasis>
supports 2 login module options which are
<emphasis>portalContainerName</emphasis> and
<emphasis>realmName</emphasis>, to allow you to indicate the realm name and
the portal container name, if you want to change the default value.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Prerequisites-Making_your_LoginModules_compatible">
+ <title>Making your LoginModules compatible</title>
+ <para>
+ Now all your LoginModules that need to get the current
<emphasis>ExoContainer</emphasis> must extends
<emphasis>org.exoplatform.services.security.jaas.AbstractLoginModule</emphasis>.
You just need to call the method <emphasis>getContainer()</emphasis> to get
the current <emphasis>ExoContainer</emphasis>.
+ </para>
+ <important>
+ <title>Useful Information</title>
+ <para>
+ The class
<emphasis>org.exoplatform.services.security.jaas.AbstractLoginModule</emphasis>
supports 2 login module options which are
<emphasis>portalContainerName</emphasis> and
<emphasis>realmName</emphasis>, to allow you to indicate the realm name and
the portal container name, if you want to change the default value.
+ </para>
- </important>
+ </important>
- </section>
-
- <section
id="sect-Reference_Guide-Prerequisites-Avoiding_static_modifier_on_component_dependency">
- <title>Avoiding <emphasis>static</emphasis> modifier on component
dependency</title>
- <para>
- A local variable that stores a component dependency must not be static. In other
words, when you create a component A that depends on component B, we don't store B in
a static variable of A otherwise we cannot have several different instances of A in the
same JVM which is not compatible with a multi-portal instance.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Prerequisites-Avoiding_static_modifier_on_component_dependency">
+ <title>Avoiding <emphasis>static</emphasis> modifier on
component dependency</title>
+ <para>
+ A local variable that stores a component dependency must not be static.
In other words, when you create a component A that depends on component B, we don't
store B in a static variable of A otherwise we cannot have several different instances of
A in the same JVM which is not compatible with a multi-portal instance.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Prerequisites-Avoid_component_initialization_based_on_component_dependency_in_the_constructor">
- <title>Avoid component initialization based on component dependency in the
constructor</title>
- <para>
- We will have more and more extensible components (i.e. that can be extended thanks to
an external plugin) which means that those components can only be initialized in the
<emphasis>start</emphasis> method, thus it is not a good practice to
initialize a component in its constructor if this initialization uses other components
because those components may not be initialized. For example, now the
ResourceBundleService is extensible, so if you create a component that depends on the
ResourceBundleService and you need the ResourceBundleService to initialize your component,
your component will need to be "Startable" and you will have to initialize your
component in a <emphasis>start</emphasis> method.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Prerequisites-Avoid_component_initialization_based_on_component_dependency_in_the_constructor">
+ <title>Avoid component initialization based on component dependency in
the constructor</title>
+ <para>
+ We will have more and more extensible components (i.e. that can be
extended thanks to an external plugin) which means that those components can only be
initialized in the <emphasis>start</emphasis> method, thus it is not a good
practice to initialize a component in its constructor if this initialization uses other
components because those components may not be initialized. For example, now the
ResourceBundleService is extensible, so if you create a component that depends on the
ResourceBundleService and you need the ResourceBundleService to initialize your component,
your component will need to be "Startable" and you will have to initialize your
component in a <emphasis>start</emphasis> method.
+ </para>
- </section>
-
+ </section>
+
- </section>
-
- <section
id="sect-Reference_Guide-How_to_extend_my_GateIn_instance-FAQ">
- <title>FAQ</title>
- <section
id="sect-Reference_Guide-FAQ-What_has_changed_since_the_previous_versions">
- <title>What has changed since the previous versions?</title>
- <para>
- The main difference with previous versions is the way to package your application, in
the previous versions you had to change the content of the file
<emphasis>portal.war</emphasis> in order to customize the portal. Now we more
consider your application as an add-on that you can packaged in another ear/war file. You
just need to follow some rules in order to notify the platform that it must take into
account your add-on in order to customize the portal.
- </para>
- <para>
- Among other things, you will have to:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Indicate the platform how to initialize and manage your application by defining and
registering the <emphasis>PortalContainerDefinition</emphasis> related to your
portal instance.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-How_to_extend_my_GateIn_instance-FAQ">
+ <title>FAQ</title>
+ <section
id="sect-Reference_Guide-FAQ-What_has_changed_since_the_previous_versions">
+ <title>What has changed since the previous versions?</title>
+ <para>
+ The main difference with previous versions is the way to package your
application, in the previous versions you had to change the content of the file
<emphasis>portal.war</emphasis> in order to customize the portal. Now we more
consider your application as an add-on that you can packaged in another ear/war file. You
just need to follow some rules in order to notify the platform that it must take into
account your add-on in order to customize the portal.
+ </para>
+ <para>
+ Among other things, you will have to:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Indicate the platform how to initialize and manage your
application by defining and registering the
<emphasis>PortalContainerDefinition</emphasis> related to your portal
instance.
+ </para>
- </listitem>
- <listitem>
- <para>
- Deploy the <emphasis>starter</emphasis> ear/war file that is used to
create and start all the portals (i.e. portal containers).
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Deploy the <emphasis>starter</emphasis> ear/war file
that is used to create and start all the portals (i.e. portal containers).
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <warning>
- <title>Warning</title>
- <para>
- Please take into account, that you need to ensure that the
<emphasis>starter</emphasis> is launched after all the other ear/war files.
- </para>
+ </itemizedlist>
+ <warning>
+ <title>Warning</title>
+ <para>
+ Please take into account, that you need to ensure that the
<emphasis>starter</emphasis> is launched after all the other ear/war files.
+ </para>
- </warning>
- <important>
- <title>Nota Bene</title>
- <para>
- If you don't need to customize the portal, you don't have to deploy the
starter. The old way to deploy an application is still compatible.
- </para>
+ </warning>
+ <important>
+ <title>Nota Bene</title>
+ <para>
+ If you don't need to customize the portal, you don't have to
deploy the starter. The old way to deploy an application is still compatible.
+ </para>
- </important>
+ </important>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-What_is_the_main_purpose_of_a_portal_extension">
- <title>What is the main purpose of a <emphasis>portal
extension</emphasis>?</title>
- <para>
- An <emphasis>extension</emphasis> is just a set of files that we use to
customize or add new features to a given portal. An extension must be the least intrusive
as possible, as we could potentially have several extensions for the same portal. In other
words, we are supposed to only add what is missing in the portal and avoid changing or
duplicated files that are in the portal.war.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-What_is_the_main_purpose_of_a_portal_extension">
+ <title>What is the main purpose of a <emphasis>portal
extension</emphasis>?</title>
+ <para>
+ An <emphasis>extension</emphasis> is just a set of files that
we use to customize or add new features to a given portal. An extension must be the least
intrusive as possible, as we could potentially have several extensions for the same
portal. In other words, we are supposed to only add what is missing in the portal and
avoid changing or duplicated files that are in the portal.war.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-What_is_the_main_purpose_of_the_starter">
- <title>What is the main purpose of the
<emphasis>starter</emphasis>?</title>
- <para>
- The <emphasis>sarter</emphasis> is a web application that has been added
to create and start all the portals (i.e. portal containers) at the same time when all the
other web applications have already been started. In fact all other web applications can
potentially defined several things at startup such as skins, javascripts, google gadgets
and configuration files, thus the loading order is important as we can redefine skins or
configuration files or a javascript from a web application 1 could depend on another
javascript from a web application 2 so if the web application 2 is loaded after the web
application 1, we will get errors in the merged javascript file.
- </para>
- <para>
- If a <emphasis>PortalContainerDefinition</emphasis> has been defined, the
loading order will be the order that has been used to define the list of dependency. And
if you defined a <emphasis>PortalContainerDefinition</emphasis> you need to
deploy the starter otherwise the loading order will be the default one (i.e. the loading
order of the Application Server)
- </para>
- <para>
- So if you need to customize your portal by adding a new extension and/or a new
portal, you need to defined the related
<emphasis>PortalContainerDefinitions</emphasis> so you need to deploy also the
starter. Otherwise, you don't need to define any
<emphasis>PortalContainerDefinition</emphasis> and to deploy the
<emphasis>starter</emphasis>.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-What_is_the_main_purpose_of_the_starter">
+ <title>What is the main purpose of the
<emphasis>starter</emphasis>?</title>
+ <para>
+ The <emphasis>sarter</emphasis> is a web application that has
been added to create and start all the portals (i.e. portal containers) at the same time
when all the other web applications have already been started. In fact all other web
applications can potentially defined several things at startup such as skins, javascripts,
google gadgets and configuration files, thus the loading order is important as we can
redefine skins or configuration files or a javascript from a web application 1 could
depend on another javascript from a web application 2 so if the web application 2 is
loaded after the web application 1, we will get errors in the merged javascript file.
+ </para>
+ <para>
+ If a <emphasis>PortalContainerDefinition</emphasis> has been
defined, the loading order will be the order that has been used to define the list of
dependency. And if you defined a
<emphasis>PortalContainerDefinition</emphasis> you need to deploy the starter
otherwise the loading order will be the default one (i.e. the loading order of the
Application Server)
+ </para>
+ <para>
+ So if you need to customize your portal by adding a new extension and/or
a new portal, you need to defined the related
<emphasis>PortalContainerDefinitions</emphasis> so you need to deploy also the
starter. Otherwise, you don't need to define any
<emphasis>PortalContainerDefinition</emphasis> and to deploy the
<emphasis>starter</emphasis>.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_a_portal_and_a_portal_container_are_related">
- <title>How a portal and a portal container are related?</title>
- <para>
- Each portal instance has its own portal container which allows the portal to have its
own set of components/services. It will ensure the isolation between the different portal
instances.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_a_portal_and_a_portal_container_are_related">
+ <title>How a portal and a portal container are related?</title>
+ <para>
+ Each portal instance has its own portal container which allows the portal
to have its own set of components/services. It will ensure the isolation between the
different portal instances.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_define_and_register_a_PortalContainerDefinition">
- <title>How to define and register a
<emphasis>PortalContainerDefinition</emphasis>?</title>
- <para>
- A <emphasis>PortalContainerDefinition</emphasis> allows you to indicate
the platform how it must initialize and manage your portal. In a
<emphasis>PortalContainerDefinition</emphasis>, you can define a set of
properties, such as:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- The name of the portal container
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_define_and_register_a_PortalContainerDefinition">
+ <title>How to define and register a
<emphasis>PortalContainerDefinition</emphasis>?</title>
+ <para>
+ A <emphasis>PortalContainerDefinition</emphasis> allows you
to indicate the platform how it must initialize and manage your portal. In a
<emphasis>PortalContainerDefinition</emphasis>, you can define a set of
properties, such as:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The name of the portal container
+ </para>
- </listitem>
- <listitem>
- <para>
- The name of the context name of the rest web application
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The name of the context name of the rest web application
+ </para>
- </listitem>
- <listitem>
- <para>
- The name of the realm
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The name of the realm
+ </para>
- </listitem>
- <listitem>
- <para>
- The list of all the dependencies of the portal container ordered by priority
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The list of all the dependencies of the portal container ordered
by priority
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- You can define and register a
<emphasis>PortalContainerDefinition</emphasis> thanks to an external plugin
that has to be treated at the <emphasis>RootContainer</emphasis> level. In
other words, your configuration file must be a file
<emphasis>conf/configuration.xml</emphasis> packaged into a jar file or
$AS_HOME/exo-conf/configuration.xml (for more details, please have a look to the article
<xref linkend="sect-Reference_Guide-Container_Configuration" />).
- </para>
- <para>
- <emphasis role="underline">See below an example of configuration file
that define and register a PortalContainerDefinition:</emphasis>
- </para>
-
+ </itemizedlist>
+ <para>
+ You can define and register a
<emphasis>PortalContainerDefinition</emphasis> thanks to an external plugin
that has to be treated at the <emphasis>RootContainer</emphasis> level. In
other words, your configuration file must be a file
<emphasis>conf/configuration.xml</emphasis> packaged into a jar file or
$AS_HOME/exo-conf/configuration.xml (for more details, please have a look to the article
<xref linkend="sect-Reference_Guide-Container_Configuration" />).
+ </para>
+ <para>
+ <emphasis role="underline">See below an example of
configuration file that define and register a PortalContainerDefinition:</emphasis>
+ </para>
+
<programlisting language="XML" role="XML"><?xml
version="1.0" encoding="UTF-8"?>
<configuration
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -543,89 +543,89 @@
</component-plugin>
</external-component-plugins>
</configuration></programlisting>
- <para>
- In the previous example, we define a portal container called "portal",
which rest context name is "rest", which realm name is "exo-domain"
and which dependencies are the web applications "eXoResources",
"portal"... The platform will load first "eXoResources", then
"portal" and so on.
- </para>
+ <para>
+ In the previous example, we define a portal container called
"portal", which rest context name is "rest", which realm name is
"exo-domain" and which dependencies are the web applications
"eXoResources", "portal"... The platform will load first
"eXoResources", then "portal" and so on.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_the_platform_interprets_the_dependency_order_defined_into_the_PortalContainerDefinition">
- <title>How the platform interprets the dependency order defined into the
PortalContainerDefinition?</title>
- <para>
- The dependency order defined into the
<emphasis>PortalContainerDefinition</emphasis> is really crucial since it will
be interpreted the same way by several components of the platform. All those components,
will consider the 1st element in the list is less important than the second element and so
on.
- </para>
- <para>
- <emphasis role="underline">So it is currently used
to:</emphasis>
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Know loading order of all the dependencies
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_the_platform_interprets_the_dependency_order_defined_into_the_PortalContainerDefinition">
+ <title>How the platform interprets the dependency order defined into
the PortalContainerDefinition?</title>
+ <para>
+ The dependency order defined into the
<emphasis>PortalContainerDefinition</emphasis> is really crucial since it will
be interpreted the same way by several components of the platform. All those components,
will consider the 1st element in the list is less important than the second element and so
on.
+ </para>
+ <para>
+ <emphasis role="underline">So it is currently used
to:</emphasis>
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Know loading order of all the dependencies
+ </para>
- </listitem>
- <listitem>
- <para>
- If we have several <emphasis>PortalContainerConfigOwner</emphasis> (see
next section for more details about a PortalContainerConfigOwner)
- </para>
- <itemizedlist>
- <listitem>
- <para>
- The ServletContext of all the
<emphasis>PortalContainerConfigOwner</emphasis> will be unified, if we use the
unified ServletContext (PortalContainer.getPortalContext()) to get a resource, it will try
to get the resource in the ServletContext of the most important
<emphasis>PortalContainerConfigOwner</emphasis> (i.e. last in the dependency
list) and if it cans find it, it will try with the second most important
<emphasis>PortalContainerConfigOwner</emphasis> and so on.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ If we have several
<emphasis>PortalContainerConfigOwner</emphasis> (see next section for more
details about a PortalContainerConfigOwner)
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The ServletContext of all the
<emphasis>PortalContainerConfigOwner</emphasis> will be unified, if we use the
unified ServletContext (PortalContainer.getPortalContext()) to get a resource, it will try
to get the resource in the ServletContext of the most important
<emphasis>PortalContainerConfigOwner</emphasis> (i.e. last in the dependency
list) and if it cans find it, it will try with the second most important
<emphasis>PortalContainerConfigOwner</emphasis> and so on.
+ </para>
- </listitem>
- <listitem>
- <para>
- The ClassLoader of all the
<emphasis>PortalContainerConfigOwner</emphasis> will be unified, if we use the
unified ClassLoader (PortalContainer.getPortalClassLoader()) to get a resource, it will
try to get the resource in the ClassLoader of the most important
<emphasis>PortalContainerConfigOwner</emphasis> (i.e. last in the dependency
list) and if it cans find it, it will try with the second most important
<emphasis>PortalContainerConfigOwner</emphasis> and so on.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The ClassLoader of all the
<emphasis>PortalContainerConfigOwner</emphasis> will be unified, if we use the
unified ClassLoader (PortalContainer.getPortalClassLoader()) to get a resource, it will
try to get the resource in the ClassLoader of the most important
<emphasis>PortalContainerConfigOwner</emphasis> (i.e. last in the dependency
list) and if it cans find it, it will try with the second most important
<emphasis>PortalContainerConfigOwner</emphasis> and so on.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
- </listitem>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_change_the_ServletContext_name_the_realm_name_andor_the_rest_context_name_of_my_portal_without_using_a_PortalContainerDefinition">
- <title>How to change the ServletContext name, the realm name and/or the rest
context name of my portal without using a PortalContainerDefinition?</title>
- <para>
- To do that you need first to change the default values used by a PortalContainer that
has not been defined thanks to a
<emphasis>PortalContainerDefinition</emphasis>. Those default values can be
modified thanks to a set of init parameters of the component
<emphasis>PortalContainerConfig</emphasis>.
- </para>
- <para>
- The component <emphasis>PortalContainerConfig</emphasis> must be
registered at the <emphasis>RootContainer</emphasis> level. In other words,
your configuration file must be a file
<emphasis>conf/configuration.xml</emphasis> packaged into a jar file or
$AS_HOME/exo-conf/configuration.xml (for more details please have a look to the article
<xref linkend="sect-Reference_Guide-Container_Configuration" />).
- </para>
- <para>
- <emphasis role="underline">In the example below we will
rename:</emphasis>
- </para>
- <itemizedlist>
- <listitem>
- <para>
- The portal name "portal" to "myPortal".
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_change_the_ServletContext_name_the_realm_name_andor_the_rest_context_name_of_my_portal_without_using_a_PortalContainerDefinition">
+ <title>How to change the ServletContext name, the realm name and/or the
rest context name of my portal without using a PortalContainerDefinition?</title>
+ <para>
+ To do that you need first to change the default values used by a
PortalContainer that has not been defined thanks to a
<emphasis>PortalContainerDefinition</emphasis>. Those default values can be
modified thanks to a set of init parameters of the component
<emphasis>PortalContainerConfig</emphasis>.
+ </para>
+ <para>
+ The component <emphasis>PortalContainerConfig</emphasis> must
be registered at the <emphasis>RootContainer</emphasis> level. In other words,
your configuration file must be a file
<emphasis>conf/configuration.xml</emphasis> packaged into a jar file or
$AS_HOME/exo-conf/configuration.xml (for more details please have a look to the article
<xref linkend="sect-Reference_Guide-Container_Configuration" />).
+ </para>
+ <para>
+ <emphasis role="underline">In the example below we will
rename:</emphasis>
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The portal name "portal" to "myPortal".
+ </para>
- </listitem>
- <listitem>
- <para>
- The rest servlet context name "rest" to "myRest".
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The rest servlet context name "rest" to
"myRest".
+ </para>
- </listitem>
- <listitem>
- <para>
- The realm name "exo-domain" to "my-exo-domain".
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The realm name "exo-domain" to
"my-exo-domain".
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- <emphasis role="underline">See below an example</emphasis>
- </para>
-
+ </itemizedlist>
+ <para>
+ <emphasis role="underline">See below an
example</emphasis>
+ </para>
+
<programlisting language="XML" role="XML"><?xml
version="1.0" encoding="UTF-8"?>
<configuration
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -653,150 +653,150 @@
</init-params>
</component>
</configuration></programlisting>
- <para>
- Once your configuration is ready, you need to:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Update the file <emphasis>WEB-INF/web.xml</emphasis> of the file
"portal.war" by changing the "display-name" (the new value is
"myPortal") and the "realm-name" in the "login-config" (the
new value is "my-exo-domain").
- </para>
+ <para>
+ Once your configuration is ready, you need to:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Update the file <emphasis>WEB-INF/web.xml</emphasis>
of the file "portal.war" by changing the "display-name" (the new value
is "myPortal") and the "realm-name" in the "login-config"
(the new value is "my-exo-domain").
+ </para>
- </listitem>
- <listitem>
- <para>
- If you use JBoss AS: Update the file
<emphasis>WEB-INF/jboss-web.xml</emphasis> of the file "portal.war"
by changing the "security-domain" (the new value is
"java:/jaas/my-exo-domain").
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ If you use JBoss AS: Update the file
<emphasis>WEB-INF/jboss-web.xml</emphasis> of the file "portal.war"
by changing the "security-domain" (the new value is
"java:/jaas/my-exo-domain").
+ </para>
- </listitem>
- <listitem>
- <para>
- Rename the "portal.war" to "myPortal.war" (or
"02portal.war" to "02myPortal.war")
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Rename the "portal.war" to "myPortal.war" (or
"02portal.war" to "02myPortal.war")
+ </para>
- </listitem>
- <listitem>
- <para>
- Update the file <emphasis>WEB-INF/web.xml</emphasis> of the file
"rest.war" by changing the "display-name" (the new value is
"myRest") and the "realm-name" in the "login-config" (the
new value is "my-exo-domain").
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Update the file <emphasis>WEB-INF/web.xml</emphasis>
of the file "rest.war" by changing the "display-name" (the new value
is "myRest") and the "realm-name" in the "login-config" (the
new value is "my-exo-domain").
+ </para>
- </listitem>
- <listitem>
- <para>
- If you use JBoss AS: Update the file
<emphasis>WEB-INF/jboss-web.xml</emphasis> of the file "rest.war" by
changing the "security-domain" (the new value is
"java:/jaas/my-exo-domain").
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ If you use JBoss AS: Update the file
<emphasis>WEB-INF/jboss-web.xml</emphasis> of the file "rest.war" by
changing the "security-domain" (the new value is
"java:/jaas/my-exo-domain").
+ </para>
- </listitem>
- <listitem>
- <para>
- Rename the "rest.war" to "myRest.war"
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Rename the "rest.war" to "myRest.war"
+ </para>
- </listitem>
- <listitem>
- <para>
- If "portal.war" and "rest.war" were embedded into an ear file:
Update the file <emphasis>META-INF/application.xml</emphasis> of the file
"exoplatform.ear" by remaming "02portal.war" to
"02myPortal.war", "portal" to "myPortal",
"rest.war" to "myRest.war" and "rest" to
"myRest".
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ If "portal.war" and "rest.war" were embedded
into an ear file: Update the file
<emphasis>META-INF/application.xml</emphasis> of the file
"exoplatform.ear" by remaming "02portal.war" to
"02myPortal.war", "portal" to "myPortal",
"rest.war" to "myRest.war" and "rest" to
"myRest".
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- The end of the process depends on your application server
- </para>
- <section
id="sect-Reference_Guide-How_to_change_the_ServletContext_name_the_realm_name_andor_the_rest_context_name_of_my_portal_without_using_a_PortalContainerDefinition-On_JBoss_tested_on_JBoss_5.1.0.GA">
- <title>On JBoss (tested on JBoss 5.1.0.GA)</title>
- <para>
- You need to change the name of the application policy in your file
<emphasis>conf/login-config.xml</emphasis> (the new name is
"my-exo-domain").
- </para>
+ </itemizedlist>
+ <para>
+ The end of the process depends on your application server
+ </para>
+ <section
id="sect-Reference_Guide-How_to_change_the_ServletContext_name_the_realm_name_andor_the_rest_context_name_of_my_portal_without_using_a_PortalContainerDefinition-On_JBoss_tested_on_JBoss_5.1.0.GA">
+ <title>On JBoss (tested on JBoss 5.1.0.GA)</title>
+ <para>
+ You need to change the name of the application policy in your file
<emphasis>conf/login-config.xml</emphasis> (the new name is
"my-exo-domain").
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-How_to_change_the_ServletContext_name_the_realm_name_andor_the_rest_context_name_of_my_portal_without_using_a_PortalContainerDefinition-On_Tomcat_tested_on_Tomcat_6.0.20">
- <title>On Tomcat (tested on Tomcat 6.0.20)</title>
- <para>
- <emphasis role="underline">You need to:</emphasis>
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Update the file
<emphasis>tomcat/conf/Catalina/localhost/portal.xml</emphasis> by changing the
"path" (the new value is "/myPortal"), the "docBase" (the
new value is "myPortal") and the "appName" in the "Realm"
definition (the new value is "my-exo-domain").
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-How_to_change_the_ServletContext_name_the_realm_name_andor_the_rest_context_name_of_my_portal_without_using_a_PortalContainerDefinition-On_Tomcat_tested_on_Tomcat_6.0.20">
+ <title>On Tomcat (tested on Tomcat 6.0.20)</title>
+ <para>
+ <emphasis role="underline">You need
to:</emphasis>
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Update the file
<emphasis>tomcat/conf/Catalina/localhost/portal.xml</emphasis> by changing the
"path" (the new value is "/myPortal"), the "docBase" (the
new value is "myPortal") and the "appName" in the "Realm"
definition (the new value is "my-exo-domain").
+ </para>
- </listitem>
- <listitem>
- <para>
- Rename the file
<emphasis>tomcat/conf/Catalina/localhost/portal.xml</emphasis> to
<emphasis>myPortal.xml</emphasis>.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Rename the file
<emphasis>tomcat/conf/Catalina/localhost/portal.xml</emphasis> to
<emphasis>myPortal.xml</emphasis>.
+ </para>
- </listitem>
- <listitem>
- <para>
- Update the file
<emphasis>tomcat/conf/Catalina/localhost/rest.xml</emphasis> by changing the
"path" (the new value is "/myRest"), the "docBase" (the new
value is "myRest") and the "appName" in the "Realm"
definition (the new value is "my-exo-domain").
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Update the file
<emphasis>tomcat/conf/Catalina/localhost/rest.xml</emphasis> by changing the
"path" (the new value is "/myRest"), the "docBase" (the new
value is "myRest") and the "appName" in the "Realm"
definition (the new value is "my-exo-domain").
+ </para>
- </listitem>
- <listitem>
- <para>
- Rename the file
<emphasis>tomcat/conf/Catalina/localhost/rest.xml</emphasis> to
<emphasis>myRest.xml</emphasis>.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Rename the file
<emphasis>tomcat/conf/Catalina/localhost/rest.xml</emphasis> to
<emphasis>myRest.xml</emphasis>.
+ </para>
- </listitem>
- <listitem>
- <para>
- Change the realm name in the file
<emphasis>tomcat/conf/jaas.conf</emphasis> (the new name is
"my-exo-domain").
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Change the realm name in the file
<emphasis>tomcat/conf/jaas.conf</emphasis> (the new name is
"my-exo-domain").
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
- </section>
-
+ </section>
+
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_add_new_configuration_file_to_a_given_portal_from_a_war_file">
- <title>How to add new configuration file to a given portal from a war
file?</title>
- <para>
- To indicate the platform that a given web application has configuration file to
provide, you need to:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Add the ServletContextListener
<emphasis>org.exoplatform.container.web.PortalContainerConfigOwner</emphasis>
in its web.xml.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_add_new_configuration_file_to_a_given_portal_from_a_war_file">
+ <title>How to add new configuration file to a given portal from a war
file?</title>
+ <para>
+ To indicate the platform that a given web application has configuration
file to provide, you need to:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Add the ServletContextListener
<emphasis>org.exoplatform.container.web.PortalContainerConfigOwner</emphasis>
in its web.xml.
+ </para>
- </listitem>
- <listitem>
- <para>
- Add the servlet context name of this web application as a new dependency in the
<emphasis>PortalContainerDefinition</emphasis> of all the portal containers
for which you want to share the configuration file embedded into the war file, located at
<emphasis>WEB-INF/conf/configuration.xml</emphasis>.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Add the servlet context name of this web application as a new
dependency in the <emphasis>PortalContainerDefinition</emphasis> of all the
portal containers for which you want to share the configuration file embedded into the war
file, located at <emphasis>WEB-INF/conf/configuration.xml</emphasis>.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- The simple fact to add this Servlet Context Listener, will add the Servlet Context of
this web application to the Unified Servlet Context of all the
<emphasis>PortalContainers</emphasis> that depend on this web application
according to their <emphasis>PortalContainerDefinition</emphasis>.
- </para>
- <important>
- <title>Useful Information #1</title>
- <para>
- The position of the servlet context name of this web application in the dependency
list is important since the last configuration file loaded has always right towards other
configuration files. Each configuration file loaded, could potentially redefine a
configuration file that has already been loaded. Moreover, as we now use a unified Servlet
Context to load the configuration files, if you want for instance to import the file
<emphasis>war:/conf/database/database-configuration.xml</emphasis> and this
file exists in 2 different web applications, the file from the last (according to the
dependency order) web application will be loaded.
- </para>
+ </itemizedlist>
+ <para>
+ The simple fact to add this Servlet Context Listener, will add the
Servlet Context of this web application to the Unified Servlet Context of all the
<emphasis>PortalContainers</emphasis> that depend on this web application
according to their <emphasis>PortalContainerDefinition</emphasis>.
+ </para>
+ <important>
+ <title>Useful Information #1</title>
+ <para>
+ The position of the servlet context name of this web application in
the dependency list is important since the last configuration file loaded has always right
towards other configuration files. Each configuration file loaded, could potentially
redefine a configuration file that has already been loaded. Moreover, as we now use a
unified Servlet Context to load the configuration files, if you want for instance to
import the file
<emphasis>war:/conf/database/database-configuration.xml</emphasis> and this
file exists in 2 different web applications, the file from the last (according to the
dependency order) web application will be loaded.
+ </para>
- </important>
- <important>
- <title>Useful Information #2</title>
- <para>
- A portal is implicitly considered as a
<emphasis>PortalContainerConfigOwner</emphasis> without having to define the
ServletContextListener
<emphasis>org.exoplatform.container.web.PortalContainerConfigOwner</emphasis>
in its web.xml.
- </para>
+ </important>
+ <important>
+ <title>Useful Information #2</title>
+ <para>
+ A portal is implicitly considered as a
<emphasis>PortalContainerConfigOwner</emphasis> without having to define the
ServletContextListener
<emphasis>org.exoplatform.container.web.PortalContainerConfigOwner</emphasis>
in its web.xml.
+ </para>
- </important>
- <para>
- See an example of a web.xml below:
- </para>
-
+ </important>
+ <para>
+ See an example of a web.xml below:
+ </para>
+
<programlisting language="XML" role="XML"><?xml
version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application
2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
@@ -856,17 +856,17 @@
</servlet-mapping>
</web-app></programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_createdefine_a_portal_extension">
- <title>How to create/define a portal extension?</title>
- <para>
- A portal extension is in fact a web application declared as a
<emphasis>PortalContainerConfigOwner</emphasis> (see previous section for more
details about a <emphasis>PortalContainerConfigOwner</emphasis>) that has been
added to the dependency list of the
<emphasis>PortalContainerDefinition</emphasis> of a given portal.
- </para>
- <para>
- <emphasis role="underline">See below an example of configuration file
that add the portal extension "portal-ext" to the dependency list of the portal
"portal":</emphasis>
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_createdefine_a_portal_extension">
+ <title>How to create/define a portal extension?</title>
+ <para>
+ A portal extension is in fact a web application declared as a
<emphasis>PortalContainerConfigOwner</emphasis> (see previous section for more
details about a <emphasis>PortalContainerConfigOwner</emphasis>) that has been
added to the dependency list of the
<emphasis>PortalContainerDefinition</emphasis> of a given portal.
+ </para>
+ <para>
+ <emphasis role="underline">See below an example of
configuration file that add the portal extension "portal-ext" to the dependency
list of the portal "portal":</emphasis>
+ </para>
+
<programlisting language="XML" role="XML"><?xml
version="1.0" encoding="UTF-8"?>
<configuration
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -936,130 +936,130 @@
</external-component-plugins>
</configuration></programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_deploy_a_portal_extension">
- <title>How to deploy a portal extension?</title>
- <para>
- Refer to <emphasis>How to deploy the sample extension?</emphasis>
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_deploy_a_portal_extension">
+ <title>How to deploy a portal extension?</title>
+ <para>
+ Refer to <emphasis>How to deploy the sample
extension?</emphasis>
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_createdefine_a_new_portal">
- <title>How to create/define a new portal?</title>
- <para>
- To duplicate the entire "portal.war" file to create a new portal, you just
need to duplicate the following files from the original "portal.war":
- </para>
- <itemizedlist>
- <listitem>
- <para>
- login/jsp/login.jsp
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_createdefine_a_new_portal">
+ <title>How to create/define a new portal?</title>
+ <para>
+ To duplicate the entire "portal.war" file to create a new
portal, you just need to duplicate the following files from the original
"portal.war":
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ login/jsp/login.jsp
+ </para>
- </listitem>
- <listitem>
- <para>
- login/skin: You can customize the css files and pictures
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ login/skin: You can customize the css files and pictures
+ </para>
- </listitem>
- <listitem>
- <para>
- bookmark.jsp
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ bookmark.jsp
+ </para>
- </listitem>
- <listitem>
- <para>
- favicon.ico: You can replace it by your own logo
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ favicon.ico: You can replace it by your own logo
+ </para>
- </listitem>
- <listitem>
- <para>
- index.jsp
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ index.jsp
+ </para>
- </listitem>
- <listitem>
- <para>
- portal-unavailable.jsp
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ portal-unavailable.jsp
+ </para>
- </listitem>
- <listitem>
- <para>
- portal-warning.jsp
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ portal-warning.jsp
+ </para>
- </listitem>
- <listitem>
- <para>
- WEB-INF/web.xml: You just need to change the "display-name" and set a
different value for the "realm-name" in the "login-config". Indeed, we
must have one realm name per portal.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ WEB-INF/web.xml: You just need to change the
"display-name" and set a different value for the "realm-name" in the
"login-config". Indeed, we must have one realm name per portal.
+ </para>
- </listitem>
- <listitem>
- <para>
- WEB-INF/jboss-web.xml: If you use JBoss AS, you need to duplicate also this file
and set the new "security-domain" with the new realm name.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ WEB-INF/jboss-web.xml: If you use JBoss AS, you need to duplicate
also this file and set the new "security-domain" with the new realm name.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- You need also to duplicate the "rest.war" file to create a dedicated rest
web application for your portal as we must have one rest web application per portal, in
fact you just need to duplicate the following files from the original
"rest.war":
- </para>
- <itemizedlist>
- <listitem>
- <para>
- WEB-INF/web.xml: You just need to change the "display-name" and set a
different value for the "realm-name" in the "login-config". Indeed, we
must have one realm name per portal.
- </para>
+ </itemizedlist>
+ <para>
+ You need also to duplicate the "rest.war" file to create a
dedicated rest web application for your portal as we must have one rest web application
per portal, in fact you just need to duplicate the following files from the original
"rest.war":
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ WEB-INF/web.xml: You just need to change the
"display-name" and set a different value for the "realm-name" in the
"login-config". Indeed, we must have one realm name per portal.
+ </para>
- </listitem>
- <listitem>
- <para>
- WEB-INF/jboss-web.xml: If you use JBoss AS, you need to duplicate also this file
and set the new "security-domain" with the new realm name.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ WEB-INF/jboss-web.xml: If you use JBoss AS, you need to duplicate
also this file and set the new "security-domain" with the new realm name.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- Finally, you need to register and define the corresponding
<emphasis>PortalContainerDefinition</emphasis>. The
<emphasis>PortalContainerDefinition</emphasis> of your portal will be composed
of:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- The name of new portal
- </para>
+ </itemizedlist>
+ <para>
+ Finally, you need to register and define the corresponding
<emphasis>PortalContainerDefinition</emphasis>. The
<emphasis>PortalContainerDefinition</emphasis> of your portal will be composed
of:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The name of new portal
+ </para>
- </listitem>
- <listitem>
- <para>
- The name of the context name of the new rest web application
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The name of the context name of the new rest web application
+ </para>
- </listitem>
- <listitem>
- <para>
- The name of the new realm
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The name of the new realm
+ </para>
- </listitem>
- <listitem>
- <para>
- The list of all the dependencies of the original portal, with the new name of the
rest web application instead of the old name (i.e. "rest") and with a new
dependency which is in fact the name of your portal. As we leave the dependency of the
original portal in the list of dependencies, it will load the configuration files of
original "portal.war" file.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The list of all the dependencies of the original portal, with the
new name of the rest web application instead of the old name (i.e. "rest") and
with a new dependency which is in fact the name of your portal. As we leave the dependency
of the original portal in the list of dependencies, it will load the configuration files
of original "portal.war" file.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- <emphasis role="underline">See an example below:</emphasis>
- </para>
-
+ </itemizedlist>
+ <para>
+ <emphasis role="underline">See an example
below:</emphasis>
+ </para>
+
<programlisting language="XML" role="XML"><?xml
version="1.0" encoding="UTF-8"?>
<configuration
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -1126,58 +1126,58 @@
</component-plugin>
</external-component-plugins>
</configuration></programlisting>
- <important>
- <title>Useful Information #1</title>
- <para>
- A portal is implicitly a <emphasis>PortalContainerConfigOwner</emphasis>
which means that it shares the configuration file embedded into the war file, located at
<emphasis>WEB-INF/conf/configuration.xml</emphasis>
- </para>
+ <important>
+ <title>Useful Information #1</title>
+ <para>
+ A portal is implicitly a
<emphasis>PortalContainerConfigOwner</emphasis> which means that it shares the
configuration file embedded into the war file, located at
<emphasis>WEB-INF/conf/configuration.xml</emphasis>
+ </para>
- </important>
- <important>
- <title>Useful Information #2</title>
- <para>
- The position of the servlet context name of this web application in the dependency
list is important since the last configuration file loaded has always right towards other
configuration files. Each configuration file loaded, could potentially redefine a
configuration file that has already been loaded. Moreover, as we now use a unified Servlet
Context to load the configuration files, if you want for instance to import the file
<emphasis>war:/conf/database/database-configuration.xml</emphasis> and this
file exists in 2 different web applications, the file from the last (according to the
dependency order) web application will be loaded.
- </para>
+ </important>
+ <important>
+ <title>Useful Information #2</title>
+ <para>
+ The position of the servlet context name of this web application in
the dependency list is important since the last configuration file loaded has always right
towards other configuration files. Each configuration file loaded, could potentially
redefine a configuration file that has already been loaded. Moreover, as we now use a
unified Servlet Context to load the configuration files, if you want for instance to
import the file
<emphasis>war:/conf/database/database-configuration.xml</emphasis> and this
file exists in 2 different web applications, the file from the last (according to the
dependency order) web application will be loaded.
+ </para>
- </important>
+ </important>
- </section>
-
- <section id="sect-Reference_Guide-FAQ-How_to_deploy_a_new_portal">
- <title>How to deploy a new portal?</title>
- <para>
- Refer to <emphasis>How to deploy the sample portal?</emphasis>
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_deploy_a_new_portal">
+ <title>How to deploy a new portal?</title>
+ <para>
+ Refer to <emphasis>How to deploy the sample
portal?</emphasis>
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_import_properly_a_configuration_file_using_the_prefix_war">
- <title>How to import properly a configuration file using the prefix
"war:"?</title>
- <para>
- Now, the <emphasis>ConfigurationManager</emphasis> uses by default the
unified servlet context of the portal in order to get any resources in particular the
configuration files. The unified servlet context is aware of the priorities that has been
set in the <emphasis>PortalContainerDefinition</emphasis> of the portal. In
other words, if you want for instance to import the file
<emphasis>war:/conf/database/database-configuration.xml</emphasis> and this
file exists in 2 different web applications, the file from the last (according to the
dependency order) web application will be loaded.
- </para>
- <para>
- So, in order to avoid issues when we would like to package several products at the
same time (i.e. WCM, DMS, CS, KS), we need to:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Avoid the best you can to redefine a configuration file from the
"portal.war" by using the exact same path (like the previous example)
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_import_properly_a_configuration_file_using_the_prefix_war">
+ <title>How to import properly a configuration file using the prefix
"war:"?</title>
+ <para>
+ Now, the <emphasis>ConfigurationManager</emphasis> uses by
default the unified servlet context of the portal in order to get any resources in
particular the configuration files. The unified servlet context is aware of the priorities
that has been set in the <emphasis>PortalContainerDefinition</emphasis> of the
portal. In other words, if you want for instance to import the file
<emphasis>war:/conf/database/database-configuration.xml</emphasis> and this
file exists in 2 different web applications, the file from the last (according to the
dependency order) web application will be loaded.
+ </para>
+ <para>
+ So, in order to avoid issues when we would like to package several
products at the same time (i.e. WCM, DMS, CS, KS), we need to:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Avoid the best you can to redefine a configuration file from the
"portal.war" by using the exact same path (like the previous example)
+ </para>
- </listitem>
- <listitem>
- <para>
- Add your configuration files in a dedicated folder which name will be the name of
the product, in oder to ensure that no other products will use the same path
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Add your configuration files in a dedicated folder which name
will be the name of the product, in oder to ensure that no other products will use the
same path
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- The example below, is an the example of a file
<emphasis>WEB-INF/conf/configuration.xml</emphasis> of the product
"sample-ext".
- </para>
-
+ </itemizedlist>
+ <para>
+ The example below, is an the example of a file
<emphasis>WEB-INF/conf/configuration.xml</emphasis> of the product
"sample-ext".
+ </para>
+
<programlisting language="XML" role="XML"><?xml
version="1.0" encoding="ISO-8859-1"?>
<configuration
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -1189,14 +1189,14 @@
<import>war:/conf/sample-ext/web/web-inf-extension-configuration.xml</import>
</configuration></programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_avoid_duplicating_configuration_files_just_to_rename_a_simple_value">
- <title>How to avoid duplicating configuration files just to rename a simple
value?</title>
- <para>
- In your configuration file, you can use a special variable called
<emphasis>container.name.suffix</emphasis> in order to add a suffix to values
that could change between portal containers. The value of this variable will be an empty
sting if no <emphasis>PortalContainerDefinition</emphasis> has been defined
otherwise the value will be <emphasis>\-$portal.container.name</emphasis>.
<emphasis role="underline">See an example below:</emphasis>
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_avoid_duplicating_configuration_files_just_to_rename_a_simple_value">
+ <title>How to avoid duplicating configuration files just to rename a
simple value?</title>
+ <para>
+ In your configuration file, you can use a special variable called
<emphasis>container.name.suffix</emphasis> in order to add a suffix to values
that could change between portal containers. The value of this variable will be an empty
sting if no <emphasis>PortalContainerDefinition</emphasis> has been defined
otherwise the value will be <emphasis>\-$portal.container.name</emphasis>.
<emphasis role="underline">See an example below:</emphasis>
+ </para>
+
<programlisting language="XML" role="XML"><?xml
version="1.0" encoding="ISO-8859-1"?>
<configuration
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -1227,38 +1227,38 @@
</component>
</configuration></programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_add_or_change_a_Repository_andor_a_Workspace">
- <title>How to add or change a Repository and/or a Workspace?</title>
- <para>
- Now you can add new JCR repositories or workspaces thanks to an external plugin, the
configuration of your JCR Repositories will be merged knowing that the merge algorithm
will:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Add missing Repository Definitions and/or Workspace Definitions.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_add_or_change_a_Repository_andor_a_Workspace">
+ <title>How to add or change a Repository and/or a
Workspace?</title>
+ <para>
+ Now you can add new JCR repositories or workspaces thanks to an external
plugin, the configuration of your JCR Repositories will be merged knowing that the merge
algorithm will:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Add missing Repository Definitions and/or Workspace Definitions.
+ </para>
- </listitem>
- <listitem>
- <para>
- Change the properties of a Repository Definition if it has already been defined.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Change the properties of a Repository Definition if it has
already been defined.
+ </para>
- </listitem>
- <listitem>
- <para>
- Replace the Workspace Definition if it has already been defined.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Replace the Workspace Definition if it has already been defined.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- <emphasis role="underline">See an example of jcr-configuration.xml
below:</emphasis>
- </para>
-
+ </itemizedlist>
+ <para>
+ <emphasis role="underline">See an example of
jcr-configuration.xml below:</emphasis>
+ </para>
+
<programlisting language="XML" role="XML"><?xml
version="1.0" encoding="ISO-8859-1"?>
<configuration
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -1284,10 +1284,10 @@
</component-plugin>
</external-component-plugins>
</configuration></programlisting>
- <para>
- See an example of repository-configuration.xml below:
- </para>
-
+ <para>
+ See an example of repository-configuration.xml below:
+ </para>
+
<programlisting language="XML"
role="XML"><repository-service
default-repository="repository">
<repositories>
<repository name="repository" system-workspace="system"
default-workspace="portal-system">
@@ -1347,25 +1347,25 @@
</repository>
</repositories>
</repository-service></programlisting>
- <warning>
- <title>Warning</title>
- <para>
- If you have to change the default repository or the default workspace, please be
careful since it could cause side effects as you could be incompatible with some portal
configuration files that refer explicitly to
<emphasis>portal-system</emphasis> and/or to
<emphasis>repository</emphasis>. To solve this problem you can either redefine
the configuration file in a portal extension to change the workspace name and/or the
repository name or you could also add your own repository instead of your own workspace.
- </para>
+ <warning>
+ <title>Warning</title>
+ <para>
+ If you have to change the default repository or the default
workspace, please be careful since it could cause side effects as you could be
incompatible with some portal configuration files that refer explicitly to
<emphasis>portal-system</emphasis> and/or to
<emphasis>repository</emphasis>. To solve this problem you can either redefine
the configuration file in a portal extension to change the workspace name and/or the
repository name or you could also add your own repository instead of your own workspace.
+ </para>
- </warning>
+ </warning>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_add_new_ResourceBundles_to_my_portal">
- <title>How to add new ResourceBundles to my portal?</title>
- <para>
- Now you can add new Resource Bundles, thanks to an external plugin.
- </para>
- <para>
- <emphasis role="underline">See an example below:</emphasis>
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_add_new_ResourceBundles_to_my_portal">
+ <title>How to add new ResourceBundles to my portal?</title>
+ <para>
+ Now you can add new Resource Bundles, thanks to an external plugin.
+ </para>
+ <para>
+ <emphasis role="underline">See an example
below:</emphasis>
+ </para>
+
<programlisting language="XML" role="XML"><?xml
version="1.0" encoding="ISO-8859-1"?>
<configuration
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -1403,34 +1403,34 @@
</external-component-plugins>
</configuration></programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_overwrite_existing_ResourceBundles_in_my_portal">
- <title>How to overwrite existing ResourceBundles in my portal?</title>
- <para>
- Now each portal container has its own <emphasis>ClassLoader</emphasis>
which is automatically set for you at runtime (FYI: it could be retrieved thanks to
<emphasis>portalContainer.getPortalClassLoader()</emphasis>). This
<emphasis>ClassLoader</emphasis> is an unified
<emphasis>ClassLoader</emphasis> that is also aware of the dependency order
defined into the <emphasis>PortalContainerDefinition</emphasis>, so to add new
keys or update key values, you just need to:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Add the corresponding resource bundle with the same name, with <emphasis
role="underline">the same extension</emphasis> (xml or properties) at
the same location into the <emphasis>classpath</emphasis> of your Web
application (i.e. directly into the <emphasis>WEB-INF/classes</emphasis>
directory or into a jar file in the <emphasis>WEB-INF/lib</emphasis>
directory)
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_overwrite_existing_ResourceBundles_in_my_portal">
+ <title>How to overwrite existing ResourceBundles in my
portal?</title>
+ <para>
+ Now each portal container has its own
<emphasis>ClassLoader</emphasis> which is automatically set for you at runtime
(FYI: it could be retrieved thanks to
<emphasis>portalContainer.getPortalClassLoader()</emphasis>). This
<emphasis>ClassLoader</emphasis> is an unified
<emphasis>ClassLoader</emphasis> that is also aware of the dependency order
defined into the <emphasis>PortalContainerDefinition</emphasis>, so to add new
keys or update key values, you just need to:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Add the corresponding resource bundle with the same name, with
<emphasis role="underline">the same extension</emphasis> (xml or
properties) at the same location into the <emphasis>classpath</emphasis> of
your Web application (i.e. directly into the
<emphasis>WEB-INF/classes</emphasis> directory or into a jar file in the
<emphasis>WEB-INF/lib</emphasis> directory)
+ </para>
- </listitem>
- <listitem>
- <para>
- Ensure that your web application is defined after the web application of the portal
in the dependency list of the related
<emphasis>PortalContainerDefinition</emphasis>.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Ensure that your web application is defined after the web
application of the portal in the dependency list of the related
<emphasis>PortalContainerDefinition</emphasis>.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- In the example below, we want to change the values of the keys
<emphasis>UIHomePagePortlet.Label.Username</emphasis> and
<emphasis>UIHomePagePortlet.Label.Password</emphasis>, and add the new key
<emphasis>UIHomePagePortlet.Label.SampleKey</emphasis> into the Resource
Bundle <emphasis>locale.portal.webui</emphasis>.
- </para>
- <note>
- <title>WEB-INF/classes/local/portal/webui_en.properties</title>
-
+ </itemizedlist>
+ <para>
+ In the example below, we want to change the values of the keys
<emphasis>UIHomePagePortlet.Label.Username</emphasis> and
<emphasis>UIHomePagePortlet.Label.Password</emphasis>, and add the new key
<emphasis>UIHomePagePortlet.Label.SampleKey</emphasis> into the Resource
Bundle <emphasis>locale.portal.webui</emphasis>.
+ </para>
+ <note>
+
<title>WEB-INF/classes/local/portal/webui_en.properties</title>
+
<programlisting>#############################################################################
#org.exoplatform.portal.webui.component.UIHomePagePortlet
#
#############################################################################
@@ -1439,42 +1439,42 @@
UIHomePagePortlet.Label.Password=Pwd:
UIHomePagePortlet.Label.SampleKey=This is a new key that has been added to the Resource
Bundle "locale.portal.webui" of "sample-ext"</programlisting>
- </note>
+ </note>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_replace_a_groovy_template_of_my_portal">
- <title>How to replace a groovy template of my portal?</title>
- <para>
- Now each portal container has its own <emphasis>ServletContext</emphasis>
which is automatically set for you at runtime (FYI: it could be retrieved thanks to
<emphasis>portalContainer.getPortalContext()</emphasis>). This
<emphasis>ServletContext</emphasis> is an unified
<emphasis>ServletContext</emphasis> that is also aware of the dependency order
defined into the <emphasis>PortalContainerDefinition</emphasis> so to replace
a groovy template of the portal, you just need to:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Add the corresponding groovy template with the same name at the same location into
your Web application
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_replace_a_groovy_template_of_my_portal">
+ <title>How to replace a groovy template of my portal?</title>
+ <para>
+ Now each portal container has its own
<emphasis>ServletContext</emphasis> which is automatically set for you at
runtime (FYI: it could be retrieved thanks to
<emphasis>portalContainer.getPortalContext()</emphasis>). This
<emphasis>ServletContext</emphasis> is an unified
<emphasis>ServletContext</emphasis> that is also aware of the dependency order
defined into the <emphasis>PortalContainerDefinition</emphasis> so to replace
a groovy template of the portal, you just need to:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Add the corresponding groovy template with the same name at the
same location into your Web application
+ </para>
- </listitem>
- <listitem>
- <para>
- Ensure that your web application is defined after the web application of the portal
in the dependency list of the related
<emphasis>PortalContainerDefinition</emphasis>.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Ensure that your web application is defined after the web
application of the portal in the dependency list of the related
<emphasis>PortalContainerDefinition</emphasis>.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_add_new_Portal_Configurations_Navigations_Pages_or_Portlet_Preferences_to_my_portal">
- <title>How to add new Portal Configurations, Navigations, Pages or Portlet
Preferences to my portal?</title>
- <para>
- Now you can add new Portal Configurations, Navigations, Pages or Portlet Preferences
thanks to an external plugin.
- </para>
- <para>
- <emphasis role="underline">See an example below:</emphasis>
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_add_new_Portal_Configurations_Navigations_Pages_or_Portlet_Preferences_to_my_portal">
+ <title>How to add new Portal Configurations, Navigations, Pages or
Portlet Preferences to my portal?</title>
+ <para>
+ Now you can add new Portal Configurations, Navigations, Pages or Portlet
Preferences thanks to an external plugin.
+ </para>
+ <para>
+ <emphasis role="underline">See an example
below:</emphasis>
+ </para>
+
<programlisting language="XML" role="XML"><?xml
version="1.0" encoding="ISO-8859-1"?>
<configuration
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -1554,17 +1554,17 @@
</external-component-plugins>
</configuration></programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_add_new_Http_Filters_to_my_portal_without_modifying_the_portal_binary">
- <title>How to add new Http Filters to my portal without modifying the portal
binary?</title>
- <para>
- We added a <emphasis>GenericFilter</emphasis> that allows you to define
new Http Filters thanks to an external plugin. Your filter will need to implement the
interface <emphasis>org.exoplatform.web.filter.Filter</emphasis>.
- </para>
- <para>
- <emphasis role="underline">See an example of configuration
below:</emphasis>
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_add_new_Http_Filters_to_my_portal_without_modifying_the_portal_binary">
+ <title>How to add new Http Filters to my portal without modifying the
portal binary?</title>
+ <para>
+ We added a <emphasis>GenericFilter</emphasis> that allows you
to define new Http Filters thanks to an external plugin. Your filter will need to
implement the interface
<emphasis>org.exoplatform.web.filter.Filter</emphasis>.
+ </para>
+ <para>
+ <emphasis role="underline">See an example of
configuration below:</emphasis>
+ </para>
+
<programlisting language="XML" role="XML"><?xml
version="1.0" encoding="UTF-8"?>
<configuration
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -1601,12 +1601,12 @@
</component-plugin>
</external-component-plugins>
</configuration></programlisting>
- <para>
- See an example of Filter below:
- </para>
- <note>
- <title>SampleFilter.java</title>
-
+ <para>
+ See an example of Filter below:
+ </para>
+ <note>
+ <title>SampleFilter.java</title>
+
<programlisting language="Java" role="Java">...
import org.exoplatform.web.filter.Filter;
@@ -1635,49 +1635,49 @@
}
}</programlisting>
- </note>
+ </note>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_add_new_HttpSessionListeners_andor_ServletContextListeners_to_my_portal_without_modifying_the_portal_binary">
- <title>How to add new <emphasis>HttpSessionListeners</emphasis>
and/or <emphasis>ServletContextListeners</emphasis> to my portal without
modifying the portal binary?</title>
- <para>
- We added a <emphasis>GenericHttpListener</emphasis> that allows you to
define new <emphasis>HttpSessionListeners</emphasis> and/or
<emphasis>ServletContextListeners</emphasis> thanks to an external plugin.
Actually, the <emphasis>GenericHttpListener</emphasis> will broadcast events
thanks to the <emphasis>ListenerService</emphasis> that you can easily
capture. The events that it broadcasts are:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <emphasis>org.exoplatform.web.GenericHttpListener.sessionCreated</emphasis>:
When a new session is created in the portal.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_add_new_HttpSessionListeners_andor_ServletContextListeners_to_my_portal_without_modifying_the_portal_binary">
+ <title>How to add new
<emphasis>HttpSessionListeners</emphasis> and/or
<emphasis>ServletContextListeners</emphasis> to my portal without modifying
the portal binary?</title>
+ <para>
+ We added a <emphasis>GenericHttpListener</emphasis> that
allows you to define new <emphasis>HttpSessionListeners</emphasis> and/or
<emphasis>ServletContextListeners</emphasis> thanks to an external plugin.
Actually, the <emphasis>GenericHttpListener</emphasis> will broadcast events
thanks to the <emphasis>ListenerService</emphasis> that you can easily
capture. The events that it broadcasts are:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+
<emphasis>org.exoplatform.web.GenericHttpListener.sessionCreated</emphasis>:
When a new session is created in the portal.
+ </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>org.exoplatform.web.GenericHttpListener.sessionDestroyed</emphasis>:
When a session is destroyed in the portal.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+
<emphasis>org.exoplatform.web.GenericHttpListener.sessionDestroyed</emphasis>:
When a session is destroyed in the portal.
+ </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>org.exoplatform.web.GenericHttpListener.contextInitialized</emphasis>:
When the servlet context of the portal is initialized.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+
<emphasis>org.exoplatform.web.GenericHttpListener.contextInitialized</emphasis>:
When the servlet context of the portal is initialized.
+ </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>org.exoplatform.web.GenericHttpListener.contextDestroyed</emphasis>:
When the servlet context of the portal is destroyed.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+
<emphasis>org.exoplatform.web.GenericHttpListener.contextDestroyed</emphasis>:
When the servlet context of the portal is destroyed.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- If you want to listen to
<emphasis>org.exoplatform.web.GenericHttpListener.sessionCreated</emphasis>,
you will need to create a Listener that extends _Listener<PortalContainer,
HttpSessionEvent>_If you want to listen to
\_org.exoplatform.web.GenericHttpListener.sessionDestroyed_, you will need to create a
Listener that extends _Listener<PortalContainer, HttpSessionEvent>_If you
want to listen to \_org.exoplatform.web.GenericHttpListener.contextInitialized_, you will
need to create a Listener that extends _Listener<PortalContainer,
ServletContextEvent>_If you want to listen to
\_org.exoplatform.web.GenericHttpListener.contextDestroyed_, you will need to create a
Listener that extends <emphasis>Listener<PortalContainer,
ServletContextEvent></emphasis>
- </para>
- <para>
- <emphasis role="underline">See an example of configuration
below:</emphasis>
- </para>
-
+ </itemizedlist>
+ <para>
+ If you want to listen to
<emphasis>org.exoplatform.web.GenericHttpListener.sessionCreated</emphasis>,
you will need to create a Listener that extends _Listener<PortalContainer,
HttpSessionEvent>_If you want to listen to
\_org.exoplatform.web.GenericHttpListener.sessionDestroyed_, you will need to create a
Listener that extends _Listener<PortalContainer, HttpSessionEvent>_If you
want to listen to \_org.exoplatform.web.GenericHttpListener.contextInitialized_, you will
need to create a Listener that extends _Listener<PortalContainer,
ServletContextEvent>_If you want to listen to
\_org.exoplatform.web.GenericHttpListener.contextDestroyed_, you will need to create a
Listener that extends <emphasis>Listener<PortalContainer,
ServletContextEvent></emphasis>
+ </para>
+ <para>
+ <emphasis role="underline">See an example of
configuration below:</emphasis>
+ </para>
+
<programlisting language="XML" role="XML"><?xml
version="1.0" encoding="UTF-8"?>
<configuration
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -1720,12 +1720,12 @@
</component-plugin>
</external-component-plugins>
</configuration></programlisting>
- <para>
- See an example of Session Listener below:
- </para>
- <note>
- <title>SampleHttpSessionCreatedListener.java</title>
-
+ <para>
+ See an example of Session Listener below:
+ </para>
+ <note>
+ <title>SampleHttpSessionCreatedListener.java</title>
+
<programlisting language="Java" role="Java">..
import org.exoplatform.container.PortalContainer;
import org.exoplatform.services.listener.Event;
@@ -1743,13 +1743,13 @@
}
}</programlisting>
- </note>
- <para>
- See an example of Context Listener below:
- </para>
- <note>
- <title>SampleContextInitializedListener.java</title>
-
+ </note>
+ <para>
+ See an example of Context Listener below:
+ </para>
+ <note>
+ <title>SampleContextInitializedListener.java</title>
+
<programlisting language="Java" role="Java">..
import org.exoplatform.container.PortalContainer;
import org.exoplatform.services.listener.Event;
@@ -1767,233 +1767,233 @@
}
}</programlisting>
- </note>
+ </note>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_add_new_HttpServlet_to_my_portal_without_modifying_the_portal_binary">
- <title>How to add new <emphasis>HttpServlet</emphasis> to my portal
without modifying the portal binary?</title>
- <para>
- Actually, it is not possible but you can create a rest component instead. For more
details about rest, please refer to the following article <xref
linkend="sect-Reference_Guide-eXo_Web_Services" />.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_add_new_HttpServlet_to_my_portal_without_modifying_the_portal_binary">
+ <title>How to add new <emphasis>HttpServlet</emphasis> to
my portal without modifying the portal binary?</title>
+ <para>
+ Actually, it is not possible but you can create a rest component instead.
For more details about rest, please refer to the following article <xref
linkend="sect-Reference_Guide-eXo_Web_Services" />.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_override_or_add_a_Context_Parameter_to_my_portal_without_modifying_the_portal_binary">
- <title>How to override or add a Context Parameter to my portal without modifying
the portal binary?</title>
- <para>
- Actually, you have nothing to do, you just need to ensure that you get the context
parameter value from the unified servlet context of the portal, that should be set for you
but you can still get it from
<emphasis>portalContainer.getPortalContext()</emphasis>.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_override_or_add_a_Context_Parameter_to_my_portal_without_modifying_the_portal_binary">
+ <title>How to override or add a Context Parameter to my portal without
modifying the portal binary?</title>
+ <para>
+ Actually, you have nothing to do, you just need to ensure that you get
the context parameter value from the unified servlet context of the portal, that should be
set for you but you can still get it from
<emphasis>portalContainer.getPortalContext()</emphasis>.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-Where_can_I_found_an_example_of_how_to_extend_my_portal">
- <title>Where can I found an example of how to extend my portal?</title>
- <para>
- We added an example of portal extension (i.e. ability to customize a portal without
changing anything in the portal.ear) that you can find in the svn of gatein at
gatein/sample/extension.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-Where_can_I_found_an_example_of_how_to_extend_my_portal">
+ <title>Where can I found an example of how to extend my
portal?</title>
+ <para>
+ We added an example of portal extension (i.e. ability to customize a
portal without changing anything in the portal.ear) that you can find in the svn of gatein
at gatein/sample/extension.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_deploy_the_sample_extension">
- <title>How to deploy the sample extension?</title>
- <section
id="sect-Reference_Guide-How_to_deploy_the_sample_extension-On_JBoss_tested_on_JBoss_5.1.0.GA">
- <title>On JBoss (tested on JBoss 5.1.0.GA)</title>
- <para>
- We assume that you have a clean JBoss version of GateIn, in other words, we assume
that you have already the file <emphasis>exoplatform.ear</emphasis> in the
<emphasis>deploy</emphasis> directory of JBoss and you have the related
application policy in your <emphasis>conf/login-config.xml</emphasis>.
- </para>
- <para>
- <emphasis role="underline">You need to:</emphasis>
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Add the file <emphasis>sample-ext.ear</emphasis> from
sample/extension/ear/target/ to the deploy directory of JBoss, this file contains:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- The file <emphasis>sample-ext.war</emphasis> which is the web
application that contains (potentially) configuration files, groovy templates, resource
bundles, skins and javascript files, that will extend the portal.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_deploy_the_sample_extension">
+ <title>How to deploy the sample extension?</title>
+ <section
id="sect-Reference_Guide-How_to_deploy_the_sample_extension-On_JBoss_tested_on_JBoss_5.1.0.GA">
+ <title>On JBoss (tested on JBoss 5.1.0.GA)</title>
+ <para>
+ We assume that you have a clean JBoss version of GateIn, in other
words, we assume that you have already the file
<emphasis>exoplatform.ear</emphasis> in the
<emphasis>deploy</emphasis> directory of JBoss and you have the related
application policy in your <emphasis>conf/login-config.xml</emphasis>.
+ </para>
+ <para>
+ <emphasis role="underline">You need
to:</emphasis>
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Add the file <emphasis>sample-ext.ear</emphasis>
from sample/extension/ear/target/ to the deploy directory of JBoss, this file contains:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The file
<emphasis>sample-ext.war</emphasis> which is the web application that contains
(potentially) configuration files, groovy templates, resource bundles, skins and
javascript files, that will extend the portal.
+ </para>
- </listitem>
- <listitem>
- <para>
- The file
<emphasis>exo.portal.sample.extension.config-X.Y.Z.jar</emphasis> which is the
file in which we defined the <emphasis>PortalContainerDefinition</emphasis> of
the original portal in which we added <emphasis>sample-ext</emphasis> at the
end of dependency list.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The file
<emphasis>exo.portal.sample.extension.config-X.Y.Z.jar</emphasis> which is the
file in which we defined the <emphasis>PortalContainerDefinition</emphasis> of
the original portal in which we added <emphasis>sample-ext</emphasis> at the
end of dependency list.
+ </para>
- </listitem>
- <listitem>
- <para>
- The file
<emphasis>exo.portal.sample.extension.jar-X.Y.Z.jar</emphasis> which is the
file in which we have internal classes that are actualy a set of sample classes
<emphasis>(SampleFilter, SampleContextInitializedListener,
SampleContextDestroyedListener, SampleHttpSessionCreatedListener and
SampleHttpSessionDestroyedListener)</emphasis>
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The file
<emphasis>exo.portal.sample.extension.jar-X.Y.Z.jar</emphasis> which is the
file in which we have internal classes that are actualy a set of sample classes
<emphasis>(SampleFilter, SampleContextInitializedListener,
SampleContextDestroyedListener, SampleHttpSessionCreatedListener and
SampleHttpSessionDestroyedListener)</emphasis>
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
- </listitem>
- <listitem>
- <para>
- Add the file <emphasis>starter.ear</emphasis> from starter/ear/target/
to the deploy directory of JBoss, this file contains:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- The file <emphasis>starter.war</emphasis> which is the web
application that will create and start all the portal containers, that is why it must be
launched after all the other web applications.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Add the file <emphasis>starter.ear</emphasis>
from starter/ear/target/ to the deploy directory of JBoss, this file contains:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The file <emphasis>starter.war</emphasis>
which is the web application that will create and start all the portal containers, that is
why it must be launched after all the other web applications.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
- </listitem>
+ </listitem>
- </itemizedlist>
- <warning>
- <title>Warning #1</title>
- <para>
- This can only work if a Unified ClassLoader has been configured on your JBoss
(default behavior) and the load order is first the
<emphasis>exoplatform.ear</emphasis> then the
<emphasis>sample-ext.ear</emphasis> and finally the
<emphasis>starter.ear</emphasis>.
- </para>
+ </itemizedlist>
+ <warning>
+ <title>Warning #1</title>
+ <para>
+ This can only work if a Unified ClassLoader has been configured
on your JBoss (default behavior) and the load order is first the
<emphasis>exoplatform.ear</emphasis> then the
<emphasis>sample-ext.ear</emphasis> and finally the
<emphasis>starter.ear</emphasis>.
+ </para>
- </warning>
- <warning>
- <title>Warning #2</title>
- <para>
- The file <emphasis>starter.ear</emphasis> must always been started
last.
- </para>
+ </warning>
+ <warning>
+ <title>Warning #2</title>
+ <para>
+ The file <emphasis>starter.ear</emphasis> must always
been started last.
+ </para>
- </warning>
+ </warning>
- </section>
-
- <section
id="sect-Reference_Guide-How_to_deploy_the_sample_extension-On_Tomcat_tested_on_Tomcat_6.0.20">
- <title>On Tomcat (tested on Tomcat 6.0.20)</title>
- <para>
- We assume that you have a clean Tomcat version of GateIn, in other words, we assume
that you have already all the jar files of GateIn and their dependencies into
<emphasis>tomcat/lib</emphasis>, you have all the war files of GateIn into
<emphasis>tomcat/webapps</emphasis> and you have the realm name
"exo-domain" defined into the file
<emphasis>tomcat/conf/jaas.conf</emphasis>.
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Add the file <emphasis>sample-ext.war</emphasis> from
sample/extension/war/target/ to the <emphasis>tomcat/webapps</emphasis>
directory. <emphasis>(See the purpose of this file in the JBoss
section)</emphasis>.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-How_to_deploy_the_sample_extension-On_Tomcat_tested_on_Tomcat_6.0.20">
+ <title>On Tomcat (tested on Tomcat 6.0.20)</title>
+ <para>
+ We assume that you have a clean Tomcat version of GateIn, in other
words, we assume that you have already all the jar files of GateIn and their dependencies
into <emphasis>tomcat/lib</emphasis>, you have all the war files of GateIn
into <emphasis>tomcat/webapps</emphasis> and you have the realm name
"exo-domain" defined into the file
<emphasis>tomcat/conf/jaas.conf</emphasis>.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Add the file <emphasis>sample-ext.war</emphasis>
from sample/extension/war/target/ to the <emphasis>tomcat/webapps</emphasis>
directory. <emphasis>(See the purpose of this file in the JBoss
section)</emphasis>.
+ </para>
- </listitem>
- <listitem>
- <para>
- Add the folder <emphasis>starter</emphasis> from starter/war/target/
to the <emphasis>tomcat/webapps</emphasis> directory. <emphasis>(See the
purpose of this file in the JBoss section)</emphasis>.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Add the folder <emphasis>starter</emphasis> from
starter/war/target/ to the <emphasis>tomcat/webapps</emphasis> directory.
<emphasis>(See the purpose of this file in the JBoss section)</emphasis>.
+ </para>
- </listitem>
- <listitem>
- <para>
- Rename the directory (unzipped folder) <emphasis>starter</emphasis> to
<emphasis>starter.war</emphasis> (for more details see the warning below)
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Rename the directory (unzipped folder)
<emphasis>starter</emphasis> to <emphasis>starter.war</emphasis>
(for more details see the warning below)
+ </para>
- </listitem>
- <listitem>
- <para>
- Add the jar file
<emphasis>exo.portal.sample.extension.config-X.Y.Z.jar</emphasis> from
sample/extension/config/target/ to the <emphasis>tomcat/lib</emphasis>
directory. <emphasis>(See the purpose of this file in the JBoss
section)</emphasis>.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Add the jar file
<emphasis>exo.portal.sample.extension.config-X.Y.Z.jar</emphasis> from
sample/extension/config/target/ to the <emphasis>tomcat/lib</emphasis>
directory. <emphasis>(See the purpose of this file in the JBoss
section)</emphasis>.
+ </para>
- </listitem>
- <listitem>
- <para>
- Add the jar file
<emphasis>exo.portal.sample.extension.jar-X.Y.Z.jar</emphasis> from
sample/extension/jar/target/ to the <emphasis>tomcat/lib</emphasis> directory.
<emphasis>(See the purpose of this file in the JBoss section)</emphasis>.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Add the jar file
<emphasis>exo.portal.sample.extension.jar-X.Y.Z.jar</emphasis> from
sample/extension/jar/target/ to the <emphasis>tomcat/lib</emphasis> directory.
<emphasis>(See the purpose of this file in the JBoss section)</emphasis>.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <warning>
- <title>Warning</title>
- <para>
- This can only work if the <emphasis>starter.war</emphasis> is the last
war file to be loaded, so don't hesitate to rename it if your war files are loaded
following to the alphabetic order.
- </para>
+ </itemizedlist>
+ <warning>
+ <title>Warning</title>
+ <para>
+ This can only work if the
<emphasis>starter.war</emphasis> is the last war file to be loaded, so
don't hesitate to rename it if your war files are loaded following to the alphabetic
order.
+ </para>
- </warning>
+ </warning>
- </section>
-
+ </section>
+
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-Where_can_I_find_an_example_of_how_to_create_a_new_portal">
- <title>Where can I find an example of how to create a new portal?</title>
- <para>
- We added an example of new portal (i.e. ability to create a new portal from another
portal without changing anything in the portal.ear) that you can find in the svn of gatein
at gatein/sample/portal.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-Where_can_I_find_an_example_of_how_to_create_a_new_portal">
+ <title>Where can I find an example of how to create a new
portal?</title>
+ <para>
+ We added an example of new portal (i.e. ability to create a new portal
from another portal without changing anything in the portal.ear) that you can find in the
svn of gatein at gatein/sample/portal.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-How_to_deploy_the_sample_portal">
- <title>How to deploy the sample portal?</title>
- <section
id="sect-Reference_Guide-How_to_deploy_the_sample_portal-On_JBoss_tested_on_JBoss_5.1.0.GA">
- <title>On JBoss (tested on JBoss 5.1.0.GA)</title>
- <para>
- We assume that you have a clean JBoss version of GateIn, in other words, we assume
that you have already the file <emphasis>exoplatform.ear</emphasis> in the
<emphasis>deploy</emphasis> directory of JBoss and you have the related
application policy in your <emphasis>conf/login-config.xml</emphasis>.
- </para>
- <para>
- <emphasis role="underline">You need to:</emphasis>
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Add the file <emphasis>sample-portal.ear</emphasis> from
<emphasis>sample/portal/ear/target/</emphasis> to the deploy directory of
JBoss, this file contains:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- The file <emphasis>sample-portal.war</emphasis> which is the entry
point of the new portal
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-How_to_deploy_the_sample_portal">
+ <title>How to deploy the sample portal?</title>
+ <section
id="sect-Reference_Guide-How_to_deploy_the_sample_portal-On_JBoss_tested_on_JBoss_5.1.0.GA">
+ <title>On JBoss (tested on JBoss 5.1.0.GA)</title>
+ <para>
+ We assume that you have a clean JBoss version of GateIn, in other
words, we assume that you have already the file
<emphasis>exoplatform.ear</emphasis> in the
<emphasis>deploy</emphasis> directory of JBoss and you have the related
application policy in your <emphasis>conf/login-config.xml</emphasis>.
+ </para>
+ <para>
+ <emphasis role="underline">You need
to:</emphasis>
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Add the file
<emphasis>sample-portal.ear</emphasis> from
<emphasis>sample/portal/ear/target/</emphasis> to the deploy directory of
JBoss, this file contains:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The file
<emphasis>sample-portal.war</emphasis> which is the entry point of the new
portal
+ </para>
- </listitem>
- <listitem>
- <para>
- The file <emphasis>rest-sample-portal.war</emphasis> which is the
entry point for <emphasis>rest</emphasis> outside the portal (in the portal
you can access to <emphasis>rest</emphasis> thanks to path prefix
<emphasis>/sample-portal/rest</emphasis>)
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The file
<emphasis>rest-sample-portal.war</emphasis> which is the entry point for
<emphasis>rest</emphasis> outside the portal (in the portal you can access to
<emphasis>rest</emphasis> thanks to path prefix
<emphasis>/sample-portal/rest</emphasis>)
+ </para>
- </listitem>
- <listitem>
- <para>
- The file
<emphasis>exo.portal.sample.portal.config-X.Y.Z.jar</emphasis> which is the
file in which we defined the <emphasis>PortalContainerDefinition</emphasis> of
this portal
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The file
<emphasis>exo.portal.sample.portal.config-X.Y.Z.jar</emphasis> which is the
file in which we defined the <emphasis>PortalContainerDefinition</emphasis> of
this portal
+ </para>
- </listitem>
- <listitem>
- <para>
- The file <emphasis>exo.portal.sample.portal.jar-X.Y.Z.jar</emphasis>
which is the file in which we have internal classes that are actualy a set of sample
classes <emphasis>(SampleFilter, SampleContextInitializedListener,
SampleContextDestroyedListener, SampleHttpSessionCreatedListener and
SampleHttpSessionDestroyedListener)</emphasis>
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The file
<emphasis>exo.portal.sample.portal.jar-X.Y.Z.jar</emphasis> which is the file
in which we have internal classes that are actualy a set of sample classes
<emphasis>(SampleFilter, SampleContextInitializedListener,
SampleContextDestroyedListener, SampleHttpSessionCreatedListener and
SampleHttpSessionDestroyedListener)</emphasis>
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
- </listitem>
- <listitem>
- <para>
- Add the file <emphasis>starter.ear</emphasis> from starter/ear/target/
to the deploy directory of JBoss, this file contains:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- The file <emphasis>starter.war</emphasis> which is the web
application that will create and start all the portal containers, that is why it must be
launched after all the other web applications.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Add the file <emphasis>starter.ear</emphasis>
from starter/ear/target/ to the deploy directory of JBoss, this file contains:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The file <emphasis>starter.war</emphasis>
which is the web application that will create and start all the portal containers, that is
why it must be launched after all the other web applications.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
- </listitem>
- <listitem>
- <para>
- Define the related application policy in your file
<emphasis>conf/login-config.xml</emphasis>, as below:
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Define the related application policy in your file
<emphasis>conf/login-config.xml</emphasis>, as below:
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
-
+ </itemizedlist>
+
<programlisting language="XML" role="XML">
<application-policy name="exo-domain-sample-portal">
<authentication>
<login-module
code="org.exoplatform.web.security.PortalLoginModule"
flag="required">
@@ -2010,76 +2010,76 @@
</login-module>
</authentication>
</application-policy></programlisting>
- <warning>
- <title>Warning #1</title>
- <para>
- This can only work if a Unified ClassLoader has been configured on your JBoss
(default behavior) and the load order is first the
<emphasis>exoplatform.ear</emphasis> then the
<emphasis>sample-portal.ear</emphasis> and finally the
<emphasis>starter.ear</emphasis>.
- </para>
+ <warning>
+ <title>Warning #1</title>
+ <para>
+ This can only work if a Unified ClassLoader has been configured
on your JBoss (default behavior) and the load order is first the
<emphasis>exoplatform.ear</emphasis> then the
<emphasis>sample-portal.ear</emphasis> and finally the
<emphasis>starter.ear</emphasis>.
+ </para>
- </warning>
- <warning>
- <title>Warning #2</title>
- <para>
- The file <emphasis>starter.ear</emphasis> must always been started
last.
- </para>
+ </warning>
+ <warning>
+ <title>Warning #2</title>
+ <para>
+ The file <emphasis>starter.ear</emphasis> must always
been started last.
+ </para>
- </warning>
+ </warning>
- </section>
-
- <section
id="sect-Reference_Guide-How_to_deploy_the_sample_portal-On_Tomcat_tested_on_Tomcat_6.0.20">
- <title>On Tomcat (tested on Tomcat 6.0.20)</title>
- <para>
- We assume that you have a clean Tomcat version of GateIn, in other words, we assume
that you have already all the jar files of GateIn and their dependencies into
<emphasis>tomcat/lib</emphasis>, you have all the war files of GateIn into
<emphasis>tomcat/webapps</emphasis> and you have the realm name
"exo-domain" defined into the file
<emphasis>tomcat/conf/jaas.conf</emphasis>.
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Add the file <emphasis>sample-portal.war</emphasis> from
sample/portal/war/target/ to the <emphasis>tomcat/webapps</emphasis>
directory. <emphasis>(See the purpose of this file in the JBoss
section)</emphasis>.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-How_to_deploy_the_sample_portal-On_Tomcat_tested_on_Tomcat_6.0.20">
+ <title>On Tomcat (tested on Tomcat 6.0.20)</title>
+ <para>
+ We assume that you have a clean Tomcat version of GateIn, in other
words, we assume that you have already all the jar files of GateIn and their dependencies
into <emphasis>tomcat/lib</emphasis>, you have all the war files of GateIn
into <emphasis>tomcat/webapps</emphasis> and you have the realm name
"exo-domain" defined into the file
<emphasis>tomcat/conf/jaas.conf</emphasis>.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Add the file
<emphasis>sample-portal.war</emphasis> from sample/portal/war/target/ to the
<emphasis>tomcat/webapps</emphasis> directory. <emphasis>(See the
purpose of this file in the JBoss section)</emphasis>.
+ </para>
- </listitem>
- <listitem>
- <para>
- Add the file <emphasis>rest-sample-portal.war</emphasis> from
sample/portal/rest-war/target/ to the <emphasis>tomcat/webapps</emphasis>
directory. <emphasis>(See the purpose of this file in the JBoss
section)</emphasis>.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Add the file
<emphasis>rest-sample-portal.war</emphasis> from
sample/portal/rest-war/target/ to the <emphasis>tomcat/webapps</emphasis>
directory. <emphasis>(See the purpose of this file in the JBoss
section)</emphasis>.
+ </para>
- </listitem>
- <listitem>
- <para>
- Add the folder <emphasis>starter</emphasis> from starter/war/target/
to the <emphasis>tomcat/webapps</emphasis> directory. <emphasis>(See the
purpose of this file in the JBoss section)</emphasis>.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Add the folder <emphasis>starter</emphasis> from
starter/war/target/ to the <emphasis>tomcat/webapps</emphasis> directory.
<emphasis>(See the purpose of this file in the JBoss section)</emphasis>.
+ </para>
- </listitem>
- <listitem>
- <para>
- Rename the directory (unzipped folder) <emphasis>starter</emphasis> to
<emphasis>starter.war</emphasis> <emphasis>(for more details see the
warning below)</emphasis>.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Rename the directory (unzipped folder)
<emphasis>starter</emphasis> to <emphasis>starter.war</emphasis>
<emphasis>(for more details see the warning below)</emphasis>.
+ </para>
- </listitem>
- <listitem>
- <para>
- Add the jar file
<emphasis>exo.portal.sample.portal.config-X.Y.Z.jar</emphasis> from
sample/portal/config/target/ to the <emphasis>tomcat/lib</emphasis> directory.
<emphasis>(See the purpose of this file in the JBoss section)</emphasis>.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Add the jar file
<emphasis>exo.portal.sample.portal.config-X.Y.Z.jar</emphasis> from
sample/portal/config/target/ to the <emphasis>tomcat/lib</emphasis> directory.
<emphasis>(See the purpose of this file in the JBoss section)</emphasis>.
+ </para>
- </listitem>
- <listitem>
- <para>
- Add the jar file
<emphasis>exo.portal.sample.portal.jar-X.Y.Z.jar</emphasis> from
sample/portal/jar/target/ to the <emphasis>tomcat/lib</emphasis> directory.
<emphasis>(See the purpose of this file in the JBoss section)</emphasis>.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Add the jar file
<emphasis>exo.portal.sample.portal.jar-X.Y.Z.jar</emphasis> from
sample/portal/jar/target/ to the <emphasis>tomcat/lib</emphasis> directory.
<emphasis>(See the purpose of this file in the JBoss section)</emphasis>.
+ </para>
- </listitem>
- <listitem>
- <para>
- Define the related realm in your file
<emphasis>tomcat/conf/jaas.conf</emphasis>, as below:
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Define the related realm in your file
<emphasis>tomcat/conf/jaas.conf</emphasis>, as below:
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <note>
- <title>tomcat/conf/jaas.conf</title>
-
+ </itemizedlist>
+ <note>
+ <title>tomcat/conf/jaas.conf</title>
+
<programlisting>...
exo-domain-sample-portal {
org.exoplatform.web.security.PortalLoginModule required
@@ -2093,19 +2093,19 @@
realmName="exo-domain-sample-portal";
};</programlisting>
- </note>
- <itemizedlist>
- <listitem>
- <para>
- Define the context of <emphasis>sample-portal</emphasis> by creating a
file called <emphasis>sample-portal.xml</emphasis> into
<emphasis>tomcat/conf/Catalina/localhost/</emphasis> with the following
content:
- </para>
+ </note>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Define the context of
<emphasis>sample-portal</emphasis> by creating a file called
<emphasis>sample-portal.xml</emphasis> into
<emphasis>tomcat/conf/Catalina/localhost/</emphasis> with the following
content:
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <note>
- <title>tomcat/conf/Catalina/localhost/sample-portal.xml</title>
-
+ </itemizedlist>
+ <note>
+
<title>tomcat/conf/Catalina/localhost/sample-portal.xml</title>
+
<programlisting language="XML" role="XML"><Context
path='/sample-portal' docBase='sample-portal' debug='0'
reloadable='true' crossContext='true' privileged='true'>
<Logger className='org.apache.catalina.logger.SystemOutLogger'
prefix='localhost_portal_log.' suffix='.txt'
timestamp='true'/>
@@ -2117,19 +2117,19 @@
debug='0' cache='false'/>
<Valve className='org.apache.catalina.authenticator.FormAuthenticator'
characterEncoding='UTF-8'/></Context></programlisting>
- </note>
- <itemizedlist>
- <listitem>
- <para>
- Define the context of <emphasis>rest-sample-portal</emphasis> by
creating a file called <emphasis>rest-sample-portal.xml</emphasis> into
<emphasis>tomcat/conf/Catalina/localhost/</emphasis> with the following
content:
- </para>
+ </note>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Define the context of
<emphasis>rest-sample-portal</emphasis> by creating a file called
<emphasis>rest-sample-portal.xml</emphasis> into
<emphasis>tomcat/conf/Catalina/localhost/</emphasis> with the following
content:
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <note>
- <title>tomcat/conf/Catalina/localhost/rest-sample-portal.xml</title>
-
+ </itemizedlist>
+ <note>
+
<title>tomcat/conf/Catalina/localhost/rest-sample-portal.xml</title>
+
<programlisting language="XML" role="XML"><Context
path="/rest-sample-portal" docBase="rest-sample-portal"
reloadable="true" crossContext="false">
<Logger className='org.apache.catalina.logger.SystemOutLogger'
@@ -2142,100 +2142,100 @@
debug='0' cache='false'/>
</Context></programlisting>
- </note>
- <warning>
- <title>Warning</title>
- <para>
- This can only work if the <emphasis>starter.war</emphasis> is the last
war file to be loaded, so don't hesitate to rename it if your war files are loaded
following to the alphabetic order.
- </para>
+ </note>
+ <warning>
+ <title>Warning</title>
+ <para>
+ This can only work if the
<emphasis>starter.war</emphasis> is the last war file to be loaded, so
don't hesitate to rename it if your war files are loaded following to the alphabetic
order.
+ </para>
- </warning>
+ </warning>
- </section>
-
+ </section>
+
- </section>
-
- <section
id="sect-Reference_Guide-FAQ-I_get_java.lang.IllegalStateException_No_pre_init_tasks_can_be_added_to_the_portal_container_portal_because_it_has_already_been_initialized._what_can_I_do_to_fix_it">
- <title>I get "java.lang.IllegalStateException: No pre init tasks can be
added to the portal container 'portal', because it has already been
initialized." what can I do to fix it?</title>
- <para>
- To fix this issue you need to check if:
- </para>
- <orderedlist>
- <listitem>
- <para>
- The file <emphasis>starter-gatein.ear</emphasis> (which will be
<emphasis>starter.war</emphasis> for Tomcat) has been deployed
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-FAQ-I_get_java.lang.IllegalStateException_No_pre_init_tasks_can_be_added_to_the_portal_container_portal_because_it_has_already_been_initialized._what_can_I_do_to_fix_it">
+ <title>I get "java.lang.IllegalStateException: No pre init tasks
can be added to the portal container 'portal', because it has already been
initialized." what can I do to fix it?</title>
+ <para>
+ To fix this issue you need to check if:
+ </para>
+ <orderedlist>
+ <listitem>
+ <para>
+ The file <emphasis>starter-gatein.ear</emphasis>
(which will be <emphasis>starter.war</emphasis> for Tomcat) has been deployed
+ </para>
- </listitem>
- <listitem>
- <para>
- The file <emphasis>starter-gatein.ear</emphasis> (which will be
<emphasis>starter.war</emphasis> for Tomcat) is the last ear file to be
launched
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The file <emphasis>starter-gatein.ear</emphasis>
(which will be <emphasis>starter.war</emphasis> for Tomcat) is the last ear
file to be launched
+ </para>
- </listitem>
+ </listitem>
- </orderedlist>
- <note>
- <title>Note</title>
- <para>
- With Tomcat to prevent any alphabetic issue, the good way to solve this problem is
to:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Unzip the archive <emphasis>starter.war</emphasis> into a directory
called <emphasis>starter</emphasis>
- </para>
+ </orderedlist>
+ <note>
+ <title>Note</title>
+ <para>
+ With Tomcat to prevent any alphabetic issue, the good way to solve
this problem is to:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Unzip the archive
<emphasis>starter.war</emphasis> into a directory called
<emphasis>starter</emphasis>
+ </para>
- </listitem>
- <listitem>
- <para>
- Remove the archive <emphasis>starter.war</emphasis>
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Remove the archive
<emphasis>starter.war</emphasis>
+ </para>
- </listitem>
- <listitem>
- <para>
- Rename the folder <emphasis>starter</emphasis> to
<emphasis>starter.war</emphasis>
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Rename the folder <emphasis>starter</emphasis> to
<emphasis>starter.war</emphasis>
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- This tip works because folders corresponding to unzipped wars are launched after war
files.
- </para>
+ </itemizedlist>
+ <para>
+ This tip works because folders corresponding to unzipped wars are
launched after war files.
+ </para>
- </note>
+ </note>
- </section>
-
+ </section>
+
- </section>
-
- <section
id="sect-Reference_Guide-How_to_extend_my_GateIn_instance-Recommendations">
- <title>Recommendations</title>
- <section
id="sect-Reference_Guide-Recommendations-Dont_ship_your_configuration_files_with_your_jar_files">
- <title>Don't ship your configuration files with your jar
files?</title>
- <para>
- Remove all the configuration files from the jar files (
<emphasis>conf/configuration.xml</emphasis> and
<emphasis>conf/portal/configuration.xml</emphasis>) and move them to the war
file of your extension, otherwise your configuration files will be loaded for all the
portal containers which could cause incompatibility issues with other portals.
- </para>
- <para>
- Each extension should manage independently, its css files, js files, google gadgets
and configuration files. If you add configuration files into the jar files of your
extension, you brake this law.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-How_to_extend_my_GateIn_instance-Recommendations">
+ <title>Recommendations</title>
+ <section
id="sect-Reference_Guide-Recommendations-Dont_ship_your_configuration_files_with_your_jar_files">
+ <title>Don't ship your configuration files with your jar
files?</title>
+ <para>
+ Remove all the configuration files from the jar files (
<emphasis>conf/configuration.xml</emphasis> and
<emphasis>conf/portal/configuration.xml</emphasis>) and move them to the war
file of your extension, otherwise your configuration files will be loaded for all the
portal containers which could cause incompatibility issues with other portals.
+ </para>
+ <para>
+ Each extension should manage independently, its css files, js files,
google gadgets and configuration files. If you add configuration files into the jar files
of your extension, you brake this law.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Recommendations-Using_a_dedicated_workspacerepository_for_your_extension">
- <title>Using a dedicated workspace/repository for your extension?</title>
- <para>
- In order to avoid conflicts with other extensions and to manage each extension
independently, it is highly recommended to use a dedicated workspace or repository per
extension.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Recommendations-Using_a_dedicated_workspacerepository_for_your_extension">
+ <title>Using a dedicated workspace/repository for your
extension?</title>
+ <para>
+ In order to avoid conflicts with other extensions and to manage each
extension independently, it is highly recommended to use a dedicated workspace or
repository per extension.
+ </para>
- </section>
-
+ </section>
+
- </section>
+ </section>
</section>
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/jcr.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -48,10 +48,10 @@
<xi:include href="jcr/protocols/webdav.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="jcr/protocols/ftp.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <!-- backup -->
+ <!-- backup
<xi:include href="jcr/backup/exojcr-backup-service.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="jcr/backup/backup-client.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="jcr/backup/use-external-backup-tool.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="jcr/backup/use-external-backup-tool.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" /> -->
<!-- other -->
<xi:include href="jcr/statistics.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/cache.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/cache.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/cache.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -1340,453 +1340,6 @@
</section>
-
- <section
id="sect-Reference_Guide-eXo_Cache-eXo_Cache_based_on_Infinispan">
- <title>eXo Cache based on Infinispan</title>
- <section
id="sect-Reference_Guide-eXo_Cache_based_on_Infinispan-Configure_the_ExoCacheFactory">
- <title>Configure the ExoCacheFactory</title>
- <para>
- When you add the related jar file in your classpath, the eXo service
container will use the default configuration provided in the library itself but of course
you can still redefined the configuration if you wish as you can do with any components.
- </para>
- <para>
- The default configuration of the factory is:
- </para>
-
-<programlisting language="XML"
role="XML"><configuration>
- <component>
-
<key>org.exoplatform.services.cache.ExoCacheFactory</key>
-
<type>org.exoplatform.services.cache.impl.infinispan.ExoCacheFactoryImpl</type>
- <init-params>
- <value-param>
- <name>cache.config.template</name>
-
<value>jar:/conf/portal/cache-configuration-template.xml</value>
- </value-param>
- </init-params>
- </component>
-</configuration></programlisting>
- <para>
- As you can see the factory requires one single parameter which is
<emphasis>cache.config.template</emphasis>, this parameter allows you to
define the location of the default configuration template of your infinispan. In the
default configuration, we ask the eXo container to get the file shipped into the jar at
<emphasis>/conf/portal/cache-configuration-template.xml</emphasis>.
- </para>
- <para>
- The default configuration template aims to be the skeleton from which we
will create any type of infinispan cache instance, thus it must be very generic.
- </para>
- <note>
- <para>
- All the cache instances that will rely on this cache configuration
will share the same <envar>EmbeddedCacheManager.</envar>
- </para>
-
- </note>
-
- </section>
-
- <section
id="sect-Reference_Guide-eXo_Cache_based_on_Infinispan-Add_specific_configuration_for_a_cache">
- <title>Add specific configuration for a cache</title>
- <para>
- If for a given reason, you need to use a specific configuration for a
cache, you can register one thanks to an "<emphasis>external
plugin</emphasis>", see an example below:
- </para>
-
-<programlisting language="XML"
role="XML"><configuration>
- ...
- <external-component-plugins>
-
<target-component>org.exoplatform.services.cache.ExoCacheFactory</target-component>
- <component-plugin>
- <name>addConfig</name>
- <set-method>addConfig</set-method>
-
<type>org.exoplatform.services.cache.impl.infinispan.ExoCacheFactoryConfigPlugin</type>
- <description>add Custom Configurations</description>
- <init-params>
- <value-param>
- <name>myCustomCache</name>
-
<value>jar:/conf/portal/custom-cache-configuration.xml</value>
- </value-param>
- </init-params>
- </component-plugin>
- </external-component-plugins>
- ...
-</configuration></programlisting>
- <para>
- In the example above, I call the method
<emphasis>addConfig(ExoCacheFactoryConfigPlugin plugin)</emphasis> on the
current implementation of <envar>ExoCacheFactory</envar> which is actually the
infinispan implementation.
- </para>
- <para>
- In the <emphasis>init-params</emphasis> block, you can define
a set of <emphasis>value-param</emphasis> blocks and for each
<emphasis>value-param</emphasis>, we expect the name of cache that needs a
specific configuration as name and the location of your custom configuration as
<emphasis>value</emphasis>.
- </para>
- <para>
- In this example, we indicates to the factory that we would like that the
cache <emphasis>myCustomCache</emphasis> use the configuration available at
<emphasis>jar:/conf/portal/custom-cache-configuration.xml</emphasis>.
- </para>
- <note>
- <para>
- All the cache instances that will rely on the cache configuration
located at the same location will share the same
<envar>EmbeddedCacheManager</envar>.
- </para>
-
- </note>
-
- </section>
-
- <section
id="sect-Reference_Guide-eXo_Cache_based_on_Infinispan-Add_a_cache_creator">
- <title>Add a cache creator</title>
- <section
id="sect-Reference_Guide-Add_a_cache_creator-Understanding_a_cache_creator">
- <title>Understanding a cache creator</title>
- <para>
- The factory for infinispan, delegates the cache creation to
<envar>ExoCacheCreator</envar> that is defined as below:
- </para>
-
-<programlisting language="Java" role="Java">package
org.exoplatform.services.cache.impl.infinispan;
-...
-public interface ExoCacheCreator {
-
- /**
- * Creates an eXo cache according to the given configuration {@link
org.exoplatform.services.cache.ExoCacheConfig}
- * @param config the configuration of the cache to apply
- * @param cacheConfig the configuration of the infinispan cache
- * @param cacheGetter a {@link Callable} instance from which we can get the cache
- * @exception ExoCacheInitException if an exception happens while initializing the
cache
- */
- public ExoCache<Serializable, Object> create(ExoCacheConfig config,
Configuration cacheConfig, Callable<Cache<Serializable,
Object>> cacheGetter) throws ExoCacheInitException;
-
- /**
- * Returns the type of {@link org.exoplatform.services.cache.ExoCacheConfig} expected
by the creator
- * @return the expected type
- */
- public Class<? extends ExoCacheConfig> getExpectedConfigType();
-
- /**
- * Returns a set of all the implementations expected by the creator. This is mainly
used to be backward compatible
- * @return the expected by the creator
- */
- public Set<String> getExpectedImplementations();
-}</programlisting>
- <para>
- The <envar>ExoCacheCreator</envar> allows you to define
any kind of infinispan cache instance that you would like to have. It has been designed to
give you the ability to have your own type of configuration and to always be backward
compatible.
- </para>
- <para>
- In an <envar>ExoCacheCreator</envar>, you need to
implement 3 methods which are:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <emphasis>create</emphasis> - this method is used
to create a new <envar>ExoCache</envar> from the
<envar>ExoCacheConfig</envar>, an inifinispan cache configuration and a
Callable object to allow you to get the cache instance.
- </para>
-
- </listitem>
- <listitem>
- <para>
- <emphasis>getExpectedConfigType</emphasis> - this
method is used to indicate the factory the subtype of
<envar>ExoCacheConfig</envar> supported by the creator.
- </para>
-
- </listitem>
- <listitem>
- <para>
- <emphasis>getExpectedImplementation</emphasis>s -
this method is used to indicate the factory the values of the field
<emphasis>implementation</emphasis> of
<envar>ExoCacheConfig</envar> that is supported by the creator. This is used
for backward compatibility, in other words you can still configure your cache with an
instance of <envar>ExoCacheConfig</envar>.
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </section>
-
- <section
id="sect-Reference_Guide-Add_a_cache_creator-Register_a_cache_creator">
- <title>Register a cache creator</title>
- <para>
- You can register any cache creator you want thanks to an
<emphasis>"external plugin"</emphasis>, see an example below:
- </para>
-
-<programlisting language="XML" role="XML">
<external-component-plugins>
-
<target-component>org.exoplatform.services.cache.ExoCacheFactory</target-component>
- <component-plugin>
- <name>addCreator</name>
- <set-method>addCreator</set-method>
-
<type>org.exoplatform.services.cache.impl.infinispan.ExoCacheCreatorPlugin</type>
- <description>add Exo Cache Creator</description>
- <init-params>
- <object-param>
- <name>Test</name>
- <description>The cache creator for testing
purpose</description>
- <object
type="org.exoplatform.services.cache.impl.infinispan.TestExoCacheCreator"></object>
- </object-param>
- </init-params>
- </component-plugin>
- </external-component-plugins></programlisting>
- <para>
- In the example above, I call the method
<emphasis>addCreator(ExoCacheCreatorPlugin plugin)</emphasis> on the current
implementation of <envar>ExoCacheFactory</envar> which is actually the
infinispan implementation.
- </para>
- <para>
- In the <emphasis>init-params</emphasis> block, you can
define a set of <emphasis>object-param</emphasis> blocks and for each
<emphasis>object-param</emphasis>, we expect any object definition of type
<envar>ExoCacheCreator</envar>.
- </para>
- <para>
- In this example, we register the cache creator related to the
eviction policy <emphasis>Test</emphasis>.
- </para>
-
- </section>
-
- <section
id="sect-Reference_Guide-Add_a_cache_creator-The_cache_creators_available">
- <title>The cache creators available</title>
- <para>
- By default, no cache creator are defined, so you need to define them
yourself by adding them in your configuration files.
- </para>
- <section
id="sect-Reference_Guide-The_cache_creators_available-Generic_Cache_Creator">
- <title>Generic Cache Creator</title>
- <para>
- This is the generic cache creator that allows you to use any
eviction strategies defined by default in Infinispan.
- </para>
-
-<programlisting language="XML" role="XML">..
-<object-param>
- <name>GENERIC</name>
- <description>The generic cache creator</description>
- <object
type="org.exoplatform.services.cache.impl.infinispan.generic.GenericExoCacheCreator">
- <field name="implementations">
- <collection type="java.util.HashSet">
- <value>
- <string>NONE</string>
- </value>
- <value>
- <string>FIFO</string>
- </value>
- <value>
- <string>LRU</string>
- </value>
- <value>
- <string>UNORDERED</string>
- </value>
- <value>
- <string>LIRS</string>
- </value>
- </collection>
- </field>
- <field
name="defaultStrategy"><string>${my-value}</string></field>
- <field
name="defaultMaxIdle"><long>${my-value}</long></field>
- <field
name="defaultWakeUpInterval"><long>${my-value}</long></field>
- </object>
-</object-param>
-...</programlisting>
- <table
id="tabl-Reference_Guide-Generic_Cache_Creator-Fields_description">
- <title>Fields description</title>
- <tgroup cols="2">
- <tbody>
- <row>
- <entry>
- implementations
- </entry>
- <entry>
- This is the list of all the
<emphasis>implementations</emphasis> supported by the cache creator. Actualy,
it is a subset of the full list of the eviction strategies supported by infinispan to
which you want to give access to. In the configuraton above, you have the full list of all
the eviction strategies currently supported by infinispan 4.1. This field is used to
manage the backward compatibility.
- </entry>
-
- </row>
- <row>
- <entry>
- defaultStrategy
- </entry>
- <entry>
- This is the name of the default eviction strategy
to use. By default the value is <emphasis>LRU</emphasis>. This value is only
use when we define a cache of this type with the old configuration.
- </entry>
-
- </row>
- <row>
- <entry>
- defaultMaxIdle
- </entry>
- <entry>
- This is the default value of the field
<emphasis>maxIdle</emphasis> described in the section dedicated to this cache
type. By default the value is <emphasis>-1</emphasis>.This value is only use
when we define a cache of this type with the old configuration.
- </entry>
-
- </row>
- <row>
- <entry>
- defaultWakeUpInterval
- </entry>
- <entry>
- his is the default value of the field
<emphasis>wakeUpInterval</emphasis> described in the section dedicated to this
cache type. By default the value is <emphasis>5000</emphasis>.This value is
only use when we define a cache of this type with the old configuration
- </entry>
-
- </row>
-
- </tbody>
-
- </tgroup>
-
- </table>
-
- </section>
-
-
- </section>
-
-
- </section>
-
- <section
id="sect-Reference_Guide-eXo_Cache_based_on_Infinispan-Define_an_infinispan_cache_instance">
- <title>Define an infinispan cache instance</title>
- <section
id="sect-Reference_Guide-Define_an_infinispan_cache_instance-How_to_define_a_distributed_or_a_local_cache">
- <title>How to define a distributed or a local cache?</title>
- <para>
- Actually, if you use a custom configuration for your cache as
described in a previous section, we will use the cache mode define in your configuration
file.
- </para>
- <para>
- In case, you decide to use the default configuration template, we use
the field <emphasis>distributed</emphasis> of your
<envar>ExoCacheConfig</envar> to decide. In other words, if the value of this
field is false (the default value), the cache will be a local cache otherwise it will be
the cache mode defined in your default configuration template that should be distributed.
- </para>
-
- </section>
-
- <section
id="sect-Reference_Guide-Define_an_infinispan_cache_instance-How_to_define_an_infinispan_cache_instance">
- <title>How to define an infinispan cache instance</title>
- <para>
- All the eviction strategies proposed by default in infinispan rely on
the generic cache creator.
- </para>
- <itemizedlist>
- <listitem>
- <para>
- New configuration
- </para>
-
- </listitem>
-
- </itemizedlist>
-
-<programlisting language="XML" role="XML">...
- <object-param>
- <name>myCache</name>
- <description>My cache configuration</description>
- <object
type="org.exoplatform.services.cache.impl.infinispan.generic.GenericExoCacheConfig">
- <field
name="name"><string>myCacheName</string></field>
- <field
name="strategy"><int>${my-value}</int></field>
- <field
name="maxEntries"><long>${my-value}</long></field>
- <field
name="lifespan"><long>${my-value}</long></field>
- <field
name="maxIdle"><long>${my-value}</long></field>
- <field
name="wakeUpInterval"><long>${my-value}</long></field>
- </object>
- </object-param>
-...</programlisting>
- <table
id="tabl-Reference_Guide-How_to_define_an_infinispan_cache_instance-Fields_description-1">
- <title>Fields description</title>
- <tgroup cols="2">
- <tbody>
- <row>
- <entry>
- strategy
- </entry>
- <entry>
- The name of the strategy to use such as
'UNORDERED', 'FIFO', 'LRU', 'LIRS' and 'NONE' (to
disable eviction).
- </entry>
-
- </row>
- <row>
- <entry>
- maxEntries
- </entry>
- <entry>
- Maximum number of entries in a cache instance. If
selected value is not a power of two the actual value will default to the least power of
two larger than selected value. -1 means no limit which is also the default value.
- </entry>
-
- </row>
- <row>
- <entry>
- lifespan
- </entry>
- <entry>
- Maximum lifespan of a cache entry, after which the
entry is expired cluster-wide, in milliseconds. -1 means the entries never expire which is
also the default value.
- </entry>
-
- </row>
- <row>
- <entry>
- maxIdle
- </entry>
- <entry>
- Maximum idle time a cache entry will be maintained in
the cache, in milliseconds. If the idle time is exceeded, the entry will be expired
cluster-wide. -1 means the entries never expire which is also the default value.
- </entry>
-
- </row>
- <row>
- <entry>
- wakeUpInterval
- </entry>
- <entry>
- Interval between subsequent eviction runs, in
milliseconds. If you wish to disable the periodic eviction process altogether, set
wakeupInterval to -1. The default value is 5000.
- </entry>
-
- </row>
-
- </tbody>
-
- </tgroup>
-
- </table>
- <itemizedlist>
- <listitem>
- <para>
- Old configuration
- </para>
-
- </listitem>
-
- </itemizedlist>
-
-<programlisting language="XML" role="XML">...
- <object-param>
- <name>myCache</name>
- <description>My cache configuration</description>
- <field
name="name"><string>lru-with-old-config</string></field>
- <field
name="maxSize"><int>${my-value}</int></field>
- <field
name="liveTime"><long>${my-value}</long></field>
- <field
name="implementation"><string>${my-value}</string></field>
- </object>
- </object-param>
-...</programlisting>
- <table
id="tabl-Reference_Guide-How_to_define_an_infinispan_cache_instance-Fields_description-2">
- <title>Fields description</title>
- <tgroup cols="2">
- <tbody>
- <row>
- <entry>
- maxSize
- </entry>
- <entry>
- Maximum number of entries in a cache instance. If
selected value is not a power of two the actual value will default to the least power of
two larger than selected value. -1 means no limit which is also the default value.
- </entry>
-
- </row>
- <row>
- <entry>
- liveTime
- </entry>
- <entry>
- Maximum lifespan of a cache entry, after which the
entry is expired cluster-wide, in milliseconds. -1 means the entries never expire which is
also the default value.
- </entry>
-
- </row>
- <row>
- <entry>
- implementation
- </entry>
- <entry>
- The name of the implementation to use the expected
value is one of the eviction strategies defined in the field
<emphasis>implementations</emphasis> of the generic cache creator.
- </entry>
-
- </row>
-
- </tbody>
-
- </tgroup>
-
- </table>
- <para>
- <note>
- <para>
- For the fields <emphasis>maxIdle</emphasis> and
<emphasis>wakeUpInterval</emphasis> needed by infinispan, we will use the
default values provided by the creator.
- </para>
-
- </note>
- </para>
-
- </section>
-
-
- </section>
-
-
- </section>
-
</section>
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/rpc-service.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/rpc-service.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/rpc-service.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -96,7 +96,7 @@
</para>
<note>
<para>
- We expect to have one <emphasis>RPCService</emphasis>
instance per <emphasis>PortalContainer</emphasis> in a portal mode and only
one <emphasis>RPCService</emphasis> instance in a standalone mode
+ We expect to have one <emphasis>RPCService</emphasis>
instance per <emphasis>PortalContainer</emphasis> in a portal.
</para>
</note>
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/service-configuration-for-beginners.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/service-configuration-for-beginners.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/service-configuration-for-beginners.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -4,568 +4,455 @@
%BOOK_ENTITIES;
]>
<section id="sect-Reference_Guide-Service_Configuration_for_Beginners">
- <title>Service Configuration for Beginners</title>
- <para>
- <emphasis role="bold">Related documents</emphasis>
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <xref linkend="sect-Reference_Guide-Service_Configuration_in_Detail"
/>
- </para>
+ <title>Service Configuration for Beginners</title>
+ <para>
+ <emphasis role="bold">Related documents</emphasis>
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <xref
linkend="sect-Reference_Guide-Service_Configuration_in_Detail" />
+ </para>
- </listitem>
- <listitem>
- <para>
- <xref linkend="sect-Reference_Guide-Services_Wiring" />
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <xref linkend="sect-Reference_Guide-Services_Wiring" />
+ </para>
- </listitem>
- <listitem>
- <para>
- <xref linkend="sect-Reference_Guide-Container_Configuration" />
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <xref linkend="sect-Reference_Guide-Container_Configuration"
/>
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Objective">
- <title>Objective</title>
- <para>
- We are going to talk about service configuration. You will learn about modes, services
and containers, you will find out where the service configuration files have to be placed
and you will also see the overriding mechanism of configurations. Finally you will
understand how the container creates the services one after the other and what
<emphasis>Inversion of Control</emphasis> really means.
- </para>
+ </itemizedlist>
+ <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Objective">
+ <title>Objective</title>
+ <para>
+ We are going to talk about service configuration. You will learn about modes,
services and containers, you will find out where the service configuration files have to
be placed and you will also see the overriding mechanism of configurations. Finally you
will understand how the container creates the services one after the other and what
<emphasis>Inversion of Control</emphasis> really means.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Requirements">
- <title>Requirements</title>
- <para>
- By reading this article you are already glancing at the heart of eXo Kernel.
- </para>
- <para>
- Even you will read in this article to open the directory "exo-tomcat", you
may have installed eXo Portal on any application server, just replace
"exo-tomcat" by your folder name.
- </para>
- <note>
- <para>
- If you only installed the all-in-one package for the eXo Portal, the folder paths are
a slightly different. You have to replace <emphasis>exo-tomcat</emphasis> by
<emphasis>exo-eXoPortal-2.5.1-tomcat</emphasis> (obviously depending on your
version). Furthermore the webapps are delivered as war files.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Requirements">
+ <title>Requirements</title>
+ <para>
+ By reading this article you are already glancing at the heart of eXo Kernel.
+ </para>
+ <para>
+ Even you will read in this article to open the directory
"exo-tomcat", you may have installed eXo Portal on any application server, just
replace "exo-tomcat" by your folder name.
+ </para>
+ <note>
+ <para>
+ If you only installed the all-in-one package for the eXo Portal, the
folder paths are a slightly different. You have to replace
<emphasis>exo-tomcat</emphasis> by
<emphasis>exo-eXoPortal-2.5.1-tomcat</emphasis> (obviously depending on your
version). Furthermore the webapps are delivered as war files.
+ </para>
- </note>
- <para>
- You certainly already discovered eXo's fisheye URL (eXo is open source!) -
<ulink
url="https://anonsvn.jboss.org/repos/exo-jcr/">https://anons...
- which allows you to surf in the source code of all classes, if you wish to do so.
- </para>
+ </note>
+ <para>
+ You certainly already discovered eXo's fisheye URL (eXo is open source!)
- <ulink
url="https://anonsvn.jboss.org/repos/exo-jcr/">https://anons...
- which allows you to surf in the source code of all classes, if you wish to do so.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Services">
- <title>Services</title>
- <para>
- Nearly everything could be considered a service! To get a better idea, let's look
into the <emphasis>exo-tomcat/lib</emphasis> folder where you find all
deployed jar files.
- </para>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/eXoJCR/TomcatLibFolder.png"
width="444" />
- </imageobject>
+ </section>
+
+ <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Services">
+ <title>Services</title>
+ <para>
+ Nearly everything could be considered a service! To get a better idea,
let's look into the <emphasis>exo-tomcat/lib</emphasis> folder where you
find all deployed jar files.
+ </para>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/eXoJCR/TomcatLibFolder.png"
width="444" />
+ </imageobject>
- </mediaobject>
- <para>
- For example you find services for databases, caching, ldap and ftp:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- exo.core.component.database-2.1.3.jar
- </para>
+ </mediaobject>
+ <para>
+ For example you find services for databases, caching, ldap and ftp:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ exo.core.component.database-2.1.3.jar
+ </para>
- </listitem>
- <listitem>
- <para>
- exo.kernel.component.cache-2.0.5.jar
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ exo.kernel.component.cache-2.0.5.jar
+ </para>
- </listitem>
- <listitem>
- <para>
- exo.core.component.organization.ldap-2.1.3.jar
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ exo.core.component.organization.ldap-2.1.3.jar
+ </para>
- </listitem>
- <listitem>
- <para>
- exo.jcr.component.ftp-1.10.1.jar
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ exo.jcr.component.ftp-1.10.1.jar
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- Of course, there are many more services, in fact a lot of these jar files are
services. To find out you have to open the jar file and then look into its
<emphasis>/conf</emphasis> or <emphasis>/conf/portal</emphasis>
directory. Only if there is a file named
<emphasis>configuration.xml</emphasis>, you are sure to have found a service.
- </para>
- <note>
- <para>
- Why are there 2 different places to look for the configuration.xml? Because the
<emphasis>/conf</emphasis> directory is used by the
<classname>RootContainer</classname> and the
/<emphasis>conf/portal</emphasis> directory is used by the
<classname>PortalContainer</classname>. Later you will see more details about
these containers.
- </para>
+ </itemizedlist>
+ <para>
+ Of course, there are many more services, in fact a lot of these jar files are
services. To find out you have to open the jar file and then look into its
<emphasis>/conf</emphasis> or <emphasis>/conf/portal</emphasis>
directory. Only if there is a file named
<emphasis>configuration.xml</emphasis>, you are sure to have found a service.
+ </para>
+ <note>
+ <para>
+ Why are there 2 different places to look for the configuration.xml?
Because the <emphasis>/conf</emphasis> directory is used by the
<classname>RootContainer</classname> and the
/<emphasis>conf/portal</emphasis> directory is used by the
<classname>PortalContainer</classname>. Later you will see more details about
these containers.
+ </para>
- </note>
- <para>
- <emphasis role="bold">Interface - Implementation</emphasis>
It's important to get the idea that you separate the interface and implementation for
a service. That is a good concept to reduce dependencies on specific implementations. This
concept is well known for JDBC. If you use standard JDBC (=interface), you can connect any
database (=implementation) to your application. In a similar way any service in eXo is
defined by a java interface and may have many different implementations. The service
implementation is then <emphasis>injected</emphasis> by a
<emphasis>container</emphasis> into the application.
- </para>
- <para>
- <emphasis role="bold">Singleton</emphasis> Each service has to
be implemented as a <ulink
url="http://en.wikipedia.org/wiki/Singleton_pattern">singlet...;,
which means that each service is created only once - in one single instance.
- </para>
- <para>
- <emphasis role="bold">Service = Component</emphasis> You always
read about services, and you imagine a service as a large application which does big
things, but that's not true, a service can be just a little
<emphasis>component</emphasis> that reads or transforms a document, therefore
the term component is often used instead of service - so bear in mind: <emphasis>a
service and a component can safely be considered to be the same thing</emphasis>.
- </para>
+ </note>
+ <para>
+ <emphasis role="bold">Interface -
Implementation</emphasis> It's important to get the idea that you separate the
interface and implementation for a service. That is a good concept to reduce dependencies
on specific implementations. This concept is well known for JDBC. If you use standard JDBC
(=interface), you can connect any database (=implementation) to your application. In a
similar way any service in eXo is defined by a java interface and may have many different
implementations. The service implementation is then
<emphasis>injected</emphasis> by a <emphasis>container</emphasis>
into the application.
+ </para>
+ <para>
+ <emphasis role="bold">Singleton</emphasis> Each service
has to be implemented as a <ulink
url="http://en.wikipedia.org/wiki/Singleton_pattern">singlet...;,
which means that each service is created only once - in one single instance.
+ </para>
+ <para>
+ <emphasis role="bold">Service = Component</emphasis>
You always read about services, and you imagine a service as a large application which
does big things, but that's not true, a service can be just a little
<emphasis>component</emphasis> that reads or transforms a document, therefore
the term component is often used instead of service - so bear in mind: <emphasis>a
service and a component can safely be considered to be the same thing</emphasis>.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Configuration_File">
- <title>Configuration File</title>
- <para>
- The jar file of a service should contain a default configuration, you find this
configuration in the configuration.xml file which comes with the jar. A configuration file
can specify several services, as well as there can be several services in one jar file.
- </para>
- <para>
- For example open the
<package>exo.kernel.component.cache-2.0.5.jar</package> file and inside this
jar open /conf/portal/configuration.xml. You will see:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Configuration_File">
+ <title>Configuration File</title>
+ <para>
+ The jar file of a service should contain a default configuration, you find
this configuration in the configuration.xml file which comes with the jar. A configuration
file can specify several services, as well as there can be several services in one jar
file.
+ </para>
+ <para>
+ For example open the
<package>exo.kernel.component.cache-2.0.5.jar</package> file and inside this
jar open /conf/portal/configuration.xml. You will see:
+ </para>
+
<programlisting language="XML" role="XML">
<component>
<key>org.exoplatform.services.cache.CacheService</key>
<type>org.exoplatform.services.cache.impl.CacheServiceImpl</type>
...</programlisting>
- <para>
- Here you will note that a service is specified between the
<parameter><component></parameter> tags. Each service has got a
key, which defines the kind of service. As you imagine the content of the
<parameter><key></parameter> tag matches the
<emphasis>qualified java interface name</emphasis>
(<classname>org.exoplatform.services.cache.CacheService</classname>) of the
service. The specific implementation class of the
<classname>CacheService</classname> is defined in the
<parameter><type></parameter> tag.
- </para>
- <para>
- <emphasis role="bold">Parameters</emphasis> You have already
opened some configuration files and seen that there are more than just
<parameter><key></parameter> and
<parameter><type></parameter> tags. You can provide your service
with init parameters. The parameters can be simple parameters, properties, or
object-params. There are also <emphasis>plugins</emphasis> and they are
special because the container calls the setters of your service in order to
<emphasis>inject</emphasis> your plugin in your service (called
<emphasis>setter injection</emphasis>) see <xref
linkend="sect-Reference_Guide-Service_Configuration_in_Detail" />. In general
your service is free to use init parameters, they are not required.
- </para>
- <para>
- If you ever need to create your own service, the minimum is to create an empty
interface, an empty class and a constructor for your class - that's all. Ok, you also
should put your class and the interface in a jar file and add a default configuration
file.
- </para>
+ <para>
+ Here you will note that a service is specified between the
<parameter><component></parameter> tags. Each service has got a
key, which defines the kind of service. As you imagine the content of the
<parameter><key></parameter> tag matches the
<emphasis>qualified java interface name</emphasis>
(<classname>org.exoplatform.services.cache.CacheService</classname>) of the
service. The specific implementation class of the
<classname>CacheService</classname> is defined in the
<parameter><type></parameter> tag.
+ </para>
+ <para>
+ <emphasis role="bold">Parameters</emphasis> You have
already opened some configuration files and seen that there are more than just
<parameter><key></parameter> and
<parameter><type></parameter> tags. You can provide your service
with init parameters. The parameters can be simple parameters, properties, or
object-params. There are also <emphasis>plugins</emphasis> and they are
special because the container calls the setters of your service in order to
<emphasis>inject</emphasis> your plugin in your service (called
<emphasis>setter injection</emphasis>) see <xref
linkend="sect-Reference_Guide-Service_Configuration_in_Detail" />. In general
your service is free to use init parameters, they are not required.
+ </para>
+ <para>
+ If you ever need to create your own service, the minimum is to create an
empty interface, an empty class and a constructor for your class - that's all. Ok, you
also should put your class and the interface in a jar file and add a default configuration
file.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Execution_Modes">
- <title>Execution Modes</title>
- <para>
- One important thing to understand concerns execution modes. There are only two modes:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Portal mode: The service runs embedded in the eXo Portal. In this mode a
<classname>PortalContainer</classname> is used.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Execution_Modes">
+ <title>Execution Modes</title>
+ <para>
+ One important thing to understand concerns execution modes. There are only
two modes:
+ </para>
- </listitem>
- <listitem>
- <para>
- Standalone mode: The service runs without the portal. For example, the JCR service
can run standalone, and also the eXo Portlet Container. This mode is used by eXo
developers for unit tests. As the name suggests a
<classname>StandaloneContainer</classname> is used.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Containers">
+ <title>Containers</title>
+ <para>
+ In order to access to a service you need to use a Container. Just open
<ulink
url="https://anonsvn.jboss.org/repos/exo-jcr/kernel/trunk/exo.kernel...;.
+ </para>
+ <para>
+ Among the classes you see in this directory, you only will be interested in
these two container types:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ RootContainer: This is a base container. This container plays an
important role during startup, but you should not use it directly.
+ </para>
- </listitem>
+ </listitem>
+ <listitem>
+ <para>
+ PortalContainer: Created at the startup of the portal web application
(in the init() method of the PortalController servlet)
+ </para>
- </itemizedlist>
-
- </section>
-
- <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Containers">
- <title>Containers</title>
- <para>
- In order to access to a service you need to use a Container. Just open <ulink
url="https://anonsvn.jboss.org/repos/exo-jcr/kernel/trunk/exo.kernel...;.
- </para>
- <para>
- Among the classes you see in this directory, you only will be interested in these
three container types:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- RootContainer: This is a base container. This container plays an important role
during startup, but you should not use it directly.
- </para>
-
- </listitem>
- <listitem>
- <para>
- PortalContainer: Created at the startup of the portal web application (in the init()
method of the PortalController servlet)
- </para>
-
- </listitem>
- <listitem>
- <para>
- StandaloneContainer: A context independent eXo Container. The
<classname>StandaloneContainer</classname> is also used for unit tests.
- </para>
-
- </listitem>
-
- </itemizedlist>
- <para>
- <emphasis role="bold">Use only one container</emphasis> Even if
there are several container types you always use exactly one. The RootContainer is never
directly used and it depends on the execution mode if you use the PortalContainer or the
StandaloneContainer. You will ask how to find out the execution mode in my application and
how to manage these two modes. It's easy, you don't have to worry about it because
the ExoContainerContext class provides a static method that allows you to get the right
container from anywhere (see info box).
- </para>
- <para>
- <emphasis role="bold">PicoContainer</emphasis> All containers
inherit from the ExoContainer class which itself inherits from a
<classname>PicoContainer</classname>. <ulink
url="http://www.picocontainer.org/">PicoContainer</ulink> is a
framework which allows eXo to apply the IoC (<xref
linkend="sect-Reference_Guide-Inversion_Of_Control" />) principles. The
precise implementations of any service is unknown at compile time. Various implementations
can be used, eXo supplies different implementations but they also may be delivered by
other vendors. The decision which service to use during runtime is made in configuration
files.
- </para>
- <para>
- These configuration files are read by the container, the container adds all services
to a list or more exactly a java HashTable. It's completely correct to suppose that
the configuration.xml you already saw plays an important role. But there are more places
where a configuration for a service can be defined as you see in the next section.
- </para>
- <note>
- <para>
- "In your java code you have to use
- </para>
-
+ </listitem>
+ </itemizedlist>
+ <para>
+ <emphasis role="bold">Use only one container</emphasis>
Even if there are several container types you always use exactly one. The RootContainer is
never directly used and it depends on the execution mode if you use the PortalContainer.
You will ask how to find out the execution mode in my application and how to manage these
two modes. It's easy, you don't have to worry about it because the
ExoContainerContext class provides a static method that allows you to get the right
container from anywhere (see info box).
+ </para>
+ <para>
+ <emphasis role="bold">PicoContainer</emphasis> All
containers inherit from the ExoContainer class which itself inherits from a
<classname>PicoContainer</classname>. <ulink
url="http://www.picocontainer.org/">PicoContainer</ulink> is a
framework which allows eXo to apply the IoC (<xref
linkend="sect-Reference_Guide-Inversion_Of_Control" />) principles. The
precise implementations of any service is unknown at compile time. Various implementations
can be used, eXo supplies different implementations but they also may be delivered by
other vendors. The decision which service to use during runtime is made in configuration
files.
+ </para>
+ <para>
+ These configuration files are read by the container, the container adds all
services to a list or more exactly a java HashTable. It's completely correct to
suppose that the configuration.xml you already saw plays an important role. But there are
more places where a configuration for a service can be defined as you see in the next
section.
+ </para>
+ <note>
+ <para>
+ "In your java code you have to use
+ </para>
+
<programlisting language="Java" role="Java">ExoContainer
myContainer = ExoContainerContext.getCurrentContainer();</programlisting>
- <para>
- in order to access to the current container. It doesn't greatly matter to your
application if the current container is a
<classname>PortalContainer</classname> or a
<classname>StandaloneContainer</classname>. Once you have your container you
may access to any service registered in this container using
- </para>
-
+ <para>
+ in order to access to the current container. Once you have your container
you may access to any service registered in this container using
+ </para>
+
<programlisting language="Java" role="Java">MyService myService
= (MyService) myContainer.getComponentInstance(MyService.class);</programlisting>
- <para>
- You easily realize that <classname>MyService.class</classname> is the
name of the service interface.
- </para>
+ <para>
+ You easily realize that
<classname>MyService.class</classname> is the name of the service interface.
+ </para>
- </note>
+ </note>
- </section>
-
- <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Configuration_Retrieval">
- <title>Configuration Retrieval</title>
- <para>
- The configuration you find inside the jar file is considered as the default
configuration. If you want to override this default configuration you can do it in
different places outside the jar. When the container finds several configurations for the
same service, the configuration which is found later replaces completely the one found
previously. Let's call this the <emphasis>configuration override
mechanism</emphasis>.
- </para>
- <section
id="sect-Reference_Guide-Configuration_Retrieval-RootContainer">
- <title>RootContainer</title>
- <para>
- As both containers, PortalContainer and StandaloneContainer, depend on the
RootContainer, we will start by looking into this one.
- </para>
- <para>
- The retrieval sequence in short:
- </para>
- <orderedlist>
- <listitem>
- <para>
- Services default <classname>RootContainer</classname> configurations
from JAR files <emphasis>/conf/configuration.xml</emphasis>
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Configuration_Retrieval">
+ <title>Configuration Retrieval</title>
+ <para>
+ The configuration you find inside the jar file is considered as the default
configuration. If you want to override this default configuration you can do it in
different places outside the jar. When the container finds several configurations for the
same service, the configuration which is found later replaces completely the one found
previously. Let's call this the <emphasis>configuration override
mechanism</emphasis>.
+ </para>
+ <section
id="sect-Reference_Guide-Configuration_Retrieval-RootContainer">
+ <title>RootContainer</title>
+ <para>
+ As PortalContainer depends on the RootContainer, we will start by looking
into this one.
+ </para>
+ <para>
+ The retrieval sequence in short:
+ </para>
+ <orderedlist>
+ <listitem>
+ <para>
+ Services default <classname>RootContainer</classname>
configurations from JAR files <emphasis>/conf/configuration.xml</emphasis>
+ </para>
- </listitem>
- <listitem>
- <para>
- External <classname>RootContainer</classname> configuration, to be
found at <emphasis>exo-tomcat/exo-conf/configuration.xml</emphasis>
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ External <classname>RootContainer</classname>
configuration, to be found at
<emphasis>exo-tomcat/exo-conf/configuration.xml</emphasis>
+ </para>
- </listitem>
+ </listitem>
- </orderedlist>
- <note>
- <para>
- Naturally you always have to replace <parameter>exo-tomcat</parameter>
by your own folder name. In case of a Java Standalone application you have to use the
<parameter>user.dir</parameter> JVM system property value.
- </para>
+ </orderedlist>
+ <note>
+ <para>
+ Naturally you always have to replace
<parameter>exo-tomcat</parameter> by your own folder name.
+ </para>
- </note>
- <para>
- <emphasis role="bold">HashTable</emphasis> The
<classname>RootContainer</classname> creates a java
<classname>HashTable</classname> which contains key-value pairs for the
services. The qualified interface name of each service is used as key for the hashtable.
Hopefully you still remember that the
<parameter><key></parameter> tag of the configuration file
contains the interface name? The value of each hashtable pair is an object that contains
the service configuration (yes, this means the whole structure between the
<parameter><component></parameter> tags of your
<filename>configuration.xml</filename> file).
- </para>
- <para>
- The <classname>RootContainer</classname> runs over all jar files you find
in <emphasis>exo-tomcat/lib</emphasis> and looks if there is a configuration
file at <emphasis>/conf/configuration.xml</emphasis>, the services configured
in this file are added to the hashtable. That way - at the end of this process - the
default configurations for all services are stored in the hashtable.
- </para>
- <note>
- <para>
- What happens if the same service - recognized by the same qualified interface name -
is configured in different jars? As the service only can exist one time the configuration
of the jar found later overrides the previous configuration. You know that the loading
<emphasis role="bold">order of the jars is unpredictable</emphasis>
you <emphasis role="bold">must not depend on this</emphasis>.
- </para>
+ </note>
+ <para>
+ <emphasis role="bold">HashTable</emphasis> The
<classname>RootContainer</classname> creates a java
<classname>HashTable</classname> which contains key-value pairs for the
services. The qualified interface name of each service is used as key for the hashtable.
Hopefully you still remember that the
<parameter><key></parameter> tag of the configuration file
contains the interface name? The value of each hashtable pair is an object that contains
the service configuration (yes, this means the whole structure between the
<parameter><component></parameter> tags of your
<filename>configuration.xml</filename> file).
+ </para>
+ <para>
+ The <classname>RootContainer</classname> runs over all jar
files you find in <emphasis>exo-tomcat/lib</emphasis> and looks if there is a
configuration file at <emphasis>/conf/configuration.xml</emphasis>, the
services configured in this file are added to the hashtable. That way - at the end of this
process - the default configurations for all services are stored in the hashtable.
+ </para>
+ <note>
+ <para>
+ What happens if the same service - recognized by the same qualified
interface name - is configured in different jars? As the service only can exist one time
the configuration of the jar found later overrides the previous configuration. You know
that the loading <emphasis role="bold">order of the jars is
unpredictable</emphasis> you <emphasis role="bold">must not depend
on this</emphasis>.
+ </para>
- </note>
- <para>
- If you wish to provide your own configurations for one or several services, you can
do it in a general configuration file that has to be placed at
<emphasis>exo-tomcat/exo-conf/configuration.xml</emphasis>. Do not search for
such a file on your computer - you won't find one, because this option is not used in
the default installation. Here again the same rule applies: <emphasis>The posterior
configuration replaces the previous one</emphasis>.
- </para>
- <para>
- The further configuration retrieval depends on the container type.
- </para>
+ </note>
+ <para>
+ If you wish to provide your own configurations for one or several
services, you can do it in a general configuration file that has to be placed at
<emphasis>exo-tomcat/exo-conf/configuration.xml</emphasis>. Do not search for
such a file on your computer - you won't find one, because this option is not used in
the default installation. Here again the same rule applies: <emphasis>The posterior
configuration replaces the previous one</emphasis>.
+ </para>
+ <para>
+ The further configuration retrieval depends on the container type.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Configuration_Retrieval-PortalContainer">
- <title>PortalContainer</title>
- <para>
- The PortalContainer takes the hashtable filled by the RootContainer and continues to
look in some more places. Here you get the opportunity to replace RootContainer
configurations by those which are specific to your portal. Again, the configurations are
overridden whenever necessary.
- </para>
- <para>
- In short PortalContainer configurations are retrieved in the following lookup
sequence :
- </para>
- <orderedlist>
- <listitem>
- <para>
- Take over the configurations of the RootContainer
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Configuration_Retrieval-PortalContainer">
+ <title>PortalContainer</title>
+ <para>
+ The PortalContainer takes the hashtable filled by the RootContainer and
continues to look in some more places. Here you get the opportunity to replace
RootContainer configurations by those which are specific to your portal. Again, the
configurations are overridden whenever necessary.
+ </para>
+ <para>
+ In short PortalContainer configurations are retrieved in the following
lookup sequence :
+ </para>
+ <orderedlist>
+ <listitem>
+ <para>
+ Take over the configurations of the RootContainer
+ </para>
- </listitem>
- <listitem>
- <para>
- Default PortalContainer configurations from all JAR files (folder
<emphasis>/conf/portal/configuration.xml</emphasis>)
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Default PortalContainer configurations from all JAR files (folder
<emphasis>/conf/portal/configuration.xml</emphasis>)
+ </para>
- </listitem>
- <listitem>
- <para>
- Web application configurations from the portal.war file - or the
<emphasis>portal</emphasis> weppapp (folder
<emphasis>/WEB-INF/conf/configuration.xml</emphasis>)
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Web application configurations from the portal.war file - or the
<emphasis>portal</emphasis> weppapp (folder
<emphasis>/WEB-INF/conf/configuration.xml</emphasis>)
+ </para>
- </listitem>
- <listitem>
- <para>
- External configuration for services of a named portal, it will be found at
<emphasis>exo-tomcat/exo-conf/portal/$portal_name/configuration.xml</emphasis>
(as of Portal 2.5)
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ External configuration for services of a named portal, it will be
found at
<emphasis>exo-tomcat/exo-conf/portal/$portal_name/configuration.xml</emphasis>
(as of Portal 2.5)
+ </para>
- </listitem>
+ </listitem>
- </orderedlist>
- <para>
- You see, here the <emphasis>/conf/portal/configuration.xml</emphasis>
file of each jar enters the game, they are searched at first. Next, there is nearly always
a configuration.xml in the portal.war file (or in the portal webapp folder), you find this
file at <emphasis>/WEB-INF/conf/configuration.xml</emphasis>. If you open it,
you will find a lot of import statements that point to other configuration files in the
same portal.war (or portal webapp).
- </para>
- <para>
- <emphasis role="bold">Multiple Portals</emphasis> Be aware that
you might set up several different portals ("admin", "mexico", etc.),
and each of these portals will use a different PortalContainer. And each of these
PortalContainers can be configured separately. As of eXo Portal 2.5 you also will be able
to provide configurations from outside the jars and wars or webapps. Put a configuration
file in
<emphasis>exo-tomcat/exo-conf/portal/$portal_name/configuration.xml</emphasis>
where <parameter>$portal_name</parameter> is the name of the portal you want
to configure for . But normally you only have one portal which is called
"portal" so you use
<emphasis>exo-tomcat/exo-conf/portal/portal/configuration.xml</emphasis>.
- </para>
- <note>
- <para>
- As of eXo Portal 2.5 you can override the external configuration location with the
system property <emphasis>exo.conf.dir</emphasis>. If the property exists its
value will be used as path to the eXo configuration directory, that means this is an
alternative to <emphasis>exo-tomcat/exo-conf</emphasis>. Just put this
property in the command line: <emphasis>java
-Dexo.conf.dir=/path/to/exo/conf</emphasis> or use eXo.bat or eXo.sh. In this
particular use case, you have no need to use any prefixes in your configuration file to
import other files. For example, if your configuration file is
<emphasis>exo-tomcat/exo-conf/portal/PORTAL_NAME/configuration.xml</emphasis>
and you want to import the configuration file
<emphasis>exo-tomcat/exo-conf/portal/PORTAL_NAME/mySubConfDir/myConfig.xml</emphasis>,
you can do it by adding
<emphasis><import>mySubConfDir/myConfig.xml</import></emphasis>
to your configuration file.
- </para>
+ </orderedlist>
+ <para>
+ You see, here the
<emphasis>/conf/portal/configuration.xml</emphasis> file of each jar enters
the game, they are searched at first. Next, there is nearly always a configuration.xml in
the portal.war file (or in the portal webapp folder), you find this file at
<emphasis>/WEB-INF/conf/configuration.xml</emphasis>. If you open it, you will
find a lot of import statements that point to other configuration files in the same
portal.war (or portal webapp).
+ </para>
+ <para>
+ <emphasis role="bold">Multiple Portals</emphasis>
Be aware that you might set up several different portals ("admin",
"mexico", etc.), and each of these portals will use a different PortalContainer.
And each of these PortalContainers can be configured separately. As of eXo Portal 2.5 you
also will be able to provide configurations from outside the jars and wars or webapps. Put
a configuration file in
<emphasis>exo-tomcat/exo-conf/portal/$portal_name/configuration.xml</emphasis>
where <parameter>$portal_name</parameter> is the name of the portal you want
to configure for . But normally you only have one portal which is called
"portal" so you use
<emphasis>exo-tomcat/exo-conf/portal/portal/configuration.xml</emphasis>.
+ </para>
+ <note>
+ <para>
+ As of eXo Portal 2.5 you can override the external configuration
location with the system property <emphasis>exo.conf.dir</emphasis>. If the
property exists its value will be used as path to the eXo configuration directory, that
means this is an alternative to <emphasis>exo-tomcat/exo-conf</emphasis>. Just
put this property in the command line: <emphasis>java
-Dexo.conf.dir=/path/to/exo/conf</emphasis> or use eXo.bat or eXo.sh. In this
particular use case, you have no need to use any prefixes in your configuration file to
import other files. For example, if your configuration file is
<emphasis>exo-tomcat/exo-conf/portal/PORTAL_NAME/configuration.xml</emphasis>
and you want to import the configuration file
<emphasis>exo-tomcat/exo-conf/portal/PORTAL_NAME/mySubConfDir/myConfig.xml</emphasis>,
you can do it by adding
<emphasis><import>mySubConfDir/myConfig.xml</import></emphasis>
to your configuration file.
+ </para>
- </note>
- <note>
- <para>
- Under <emphasis role="bold">JBoss</emphasis> application
server <emphasis>exo-conf</emphasis> will be looked up in directory described
by JBoss System property <emphasis>jboss.server.config.url</emphasis>. If the
property is not found or empty <emphasis>exo-jboss/exo-conf</emphasis> will be
asked (since kernel 2.0.4).
- </para>
+ </note>
+ <note>
+ <para>
+ Under <emphasis role="bold">JBoss</emphasis>
application server <emphasis>exo-conf</emphasis> will be looked up in
directory described by JBoss System property
<emphasis>jboss.server.config.url</emphasis>. If the property is not found or
empty <emphasis>exo-jboss/exo-conf</emphasis> will be asked (since kernel
2.0.4).
+ </para>
- </note>
+ </note>
- </section>
-
- <section
id="sect-Reference_Guide-Configuration_Retrieval-StandaloneContainer">
- <title>StandaloneContainer</title>
- <para>
- In the same way as the PortalContainer the StandaloneContainer <emphasis>takes
over the configuration of the RootContainer</emphasis>. After that our configuration
gets a little bit more tricky because standalone containers can be initialized using an
URL. This URL contains a link to an external configuration. As you probably never need a
standalone configuration you can safely jump over the remaining confusing words of this
section.
- </para>
- <para>
- After taking over RootContainer's configuration, there are three cases which
depend on the URL initialization, :
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <emphasis role="bold">Independent configuration by
URL</emphasis> No other configuration file is taken in consideration. The
configuration provided by the URL is used without any default configs. That means that the
container creates a new empty hashtable and not any bit of previous configuration is used.
Apply the following code to do this:
- </para>
-
-<programlisting language="Java"
role="Java">StandaloneContainer.setConfigurationURL(containerConf);</programlisting>
-
- </listitem>
- <listitem>
- <para>
- <emphasis role="bold">Additional configuration by
URL</emphasis> The StandaloneContainer is initialized very similar to the
PortalContainer, but the last step is slightly different. A configuration file that is
provided by the URL is used to replace some of the service configurations.The code looks
like this:
- </para>
-
-<programlisting language="Java"
role="Java">StandaloneContainer.addConfigurationURL(containerConf);</programlisting>
- <orderedlist>
- <listitem>
- <para>
- Take over the configurations of the RootContainer
- </para>
-
- </listitem>
- <listitem>
- <para>
- Default <emphasis>StandaloneContainer</emphasis> configurations from
JAR files (folder <emphasis>/conf/portal/configuration.xml</emphasis>)
- </para>
-
- </listitem>
- <listitem>
- <para>
- Web application configurations from WAR files (folder
<emphasis>/WEB-INF/conf/configuration.xml</emphasis>)
- </para>
-
- </listitem>
- <listitem>
- <para>
- Configuration from added URL <emphasis>containerConf</emphasis>
overrides only services configured in the file
- </para>
-
- </listitem>
-
- </orderedlist>
-
- </listitem>
- <listitem>
- <para>
- <emphasis role="bold">File based configuration</emphasis> No
URL is involved, in this case the sequence is:
- </para>
- <orderedlist>
- <listitem>
- <para>
- Take over the configurations of the RootContainer
- </para>
-
- </listitem>
- <listitem>
- <para>
- Default <emphasis>StandaloneContainer</emphasis> configurations from
JAR files (folder <emphasis>/conf/portal/configuration.xml</emphasis>)
- </para>
-
- </listitem>
- <listitem>
- <para>
- Web applications configurations from WAR files (folder
<emphasis>/WEB-INF/conf/configuration.xml</emphasis>)
- </para>
-
- </listitem>
- <listitem>
- <para>
- External configuration for <emphasis>StandaloneContainer</emphasis>
services, it will be found at
<emphasis>$user_home/exo-configuration.xml</emphasis>. If
<emphasis>$user_home/exo-configuration.xml</emphasis> doesn't exist and
the <emphasis>StandaloneContainer</emphasis> instance obtained with the
dedicated configuration classloader the container will try to retrieve the resource
<emphasis>conf/exo-configuration.xml</emphasis> within the given classloader
(user_home is your home directory like "C:/Documents and Settings/Smith").
- </para>
-
- </listitem>
-
- </orderedlist>
-
- </listitem>
-
- </itemizedlist>
-
- </section>
-
-
- </section>
-
- <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Service_instantiation">
- <title>Service instantiation</title>
- <para>
- As you have already learned the services are all singletons, so that the container
creates only one single instance of each container. The services are created by calling
the constructors (called <emphasis>constructor injection</emphasis>). If there
are only zero-arguments constructors (<code>Foo public Foo(){}</code>) there
are no problems to be expected. That's easy.
- </para>
- <para>
- But now look at <ulink
url="https://anonsvn.jboss.org/repos/exo-jcr/core/trunk/exo.core.com...
- </para>
- <para>
- This JDBC implementation of BaseOrganizationService interface has only one
constructor:
- </para>
-
+ </section>
+
+ </section>
+
+ <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Service_instantiation">
+ <title>Service instantiation</title>
+ <para>
+ As you have already learned the services are all singletons, so that the
container creates only one single instance of each container. The services are created by
calling the constructors (called <emphasis>constructor injection</emphasis>).
If there are only zero-arguments constructors (<code>Foo public
Foo(){}</code>) there are no problems to be expected. That's easy.
+ </para>
+ <para>
+ But now look at <ulink
url="https://anonsvn.jboss.org/repos/exo-jcr/core/trunk/exo.core.com...
+ </para>
+ <para>
+ This JDBC implementation of BaseOrganizationService interface has only one
constructor:
+ </para>
+
<programlisting language="Java" role="Java">public
OrganizationServiceImpl(ListenerService listenerService, DatabaseService
dbService);</programlisting>
- <para>
- You see this service depends on two other services. In order to be able to call this
constructor the container first needs a <classname>ListenerService</classname>
and a <classname>DatabaseService</classname>. Therefore these services must be
instantiated before <classname>BaseOrganizationService</classname>, because
<classname>BaseOrganizationService</classname> depends on them.
- </para>
- <para>
- For this purpose the container first looks at the constructors of all services and
creates a matrix of service dependencies in order to call the services in a proper order.
If for any reason there are interdependencies or circular dependencies you will get a java
<classname>Exception</classname>. <emphasis>In this way the dependencies
are injected by the container</emphasis>.
- </para>
- <note>
- <para>
- What happens if one service has more than one constructor? The container always tries
first to use the constructor with a maximum of arguments, if this is not possible the
container continues step by step with constructors that have less arguments until arriving
at the zero-argument constructor (if there is one).
- </para>
+ <para>
+ You see this service depends on two other services. In order to be able to
call this constructor the container first needs a
<classname>ListenerService</classname> and a
<classname>DatabaseService</classname>. Therefore these services must be
instantiated before <classname>BaseOrganizationService</classname>, because
<classname>BaseOrganizationService</classname> depends on them.
+ </para>
+ <para>
+ For this purpose the container first looks at the constructors of all
services and creates a matrix of service dependencies in order to call the services in a
proper order. If for any reason there are interdependencies or circular dependencies you
will get a java <classname>Exception</classname>. <emphasis>In this way
the dependencies are injected by the container</emphasis>.
+ </para>
+ <note>
+ <para>
+ What happens if one service has more than one constructor? The container
always tries first to use the constructor with a maximum of arguments, if this is not
possible the container continues step by step with constructors that have less arguments
until arriving at the zero-argument constructor (if there is one).
+ </para>
- </note>
+ </note>
- </section>
-
- <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Miscellaneous">
- <title>Miscellaneous</title>
- <section id="sect-Reference_Guide-Miscellaneous-Startable_interface">
- <title>Startable interface</title>
- <para>
- Your service can implement the <emphasis>startable</emphasis> interface
which defines a <emphasis>start()</emphasis> and a
<emphasis>stop()</emphasis> method. These methods are called by the container
at the beginning and the end of the container's lifecycle. This way the lifecycle of
your service is managed by the container.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Miscellaneous">
+ <title>Miscellaneous</title>
+ <section
id="sect-Reference_Guide-Miscellaneous-Startable_interface">
+ <title>Startable interface</title>
+ <para>
+ Your service can implement the <emphasis>startable</emphasis>
interface which defines a <emphasis>start()</emphasis> and a
<emphasis>stop()</emphasis> method. These methods are called by the container
at the beginning and the end of the container's lifecycle. This way the lifecycle of
your service is managed by the container.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Miscellaneous-Inversion_of_Control">
- <title>Inversion of Control</title>
- <para>
- <emphasis role="bold">Retrospection</emphasis> Do you remember
your last project where you had some small components and several larger services? How was
this organized? Some services had their own configuration files, others had static values
in the source code. Most components were probably tightly coupled to the main application,
or you called static methods whenever you needed a service in your java class. Presumably
you even copied the source code of an earlier project in order to adapt the implementation
to your needs. In short:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Each of your service had a proprietary configuration mechanism.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Miscellaneous-Inversion_of_Control">
+ <title>Inversion of Control</title>
+ <para>
+ <emphasis role="bold">Retrospection</emphasis> Do
you remember your last project where you had some small components and several larger
services? How was this organized? Some services had their own configuration files, others
had static values in the source code. Most components were probably tightly coupled to the
main application, or you called static methods whenever you needed a service in your java
class. Presumably you even copied the source code of an earlier project in order to adapt
the implementation to your needs. In short:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Each of your service had a proprietary configuration mechanism.
+ </para>
- </listitem>
- <listitem>
- <para>
- The service lifecycles were managed inside of each service or were arbitrary.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The service lifecycles were managed inside of each service or
were arbitrary.
+ </para>
- </listitem>
- <listitem>
- <para>
- The dependencies between your services were implementation-dependent and tightly
coupled in your source code.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The dependencies between your services were
implementation-dependent and tightly coupled in your source code.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- <emphasis role="bold">New Approach</emphasis> You have seen
that eXo uses the <emphasis>Inversion of Control</emphasis> (IoC) pattern
which means that the control of the services is given to an independent outside entity, in
this case a <emphasis>container</emphasis>. Now the container takes care of
everything:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- The <emphasis>configuration is injected</emphasis> by external
configuration files.
- </para>
+ </itemizedlist>
+ <para>
+ <emphasis role="bold">New Approach</emphasis> You
have seen that eXo uses the <emphasis>Inversion of Control</emphasis> (IoC)
pattern which means that the control of the services is given to an independent outside
entity, in this case a <emphasis>container</emphasis>. Now the container takes
care of everything:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The <emphasis>configuration is injected</emphasis> by
external configuration files.
+ </para>
- </listitem>
- <listitem>
- <para>
- The <emphasis>lifecycle is managed from outside</emphasis>, because the
constructors are called by the container. You can achieve an even finer lifecycle
management if you use the startable interface.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The <emphasis>lifecycle is managed from
outside</emphasis>, because the constructors are called by the container. You can
achieve an even finer lifecycle management if you use the startable interface.
+ </para>
- </listitem>
- <listitem>
- <para>
- The <emphasis>dependencies are injected</emphasis> by the service
instantiation process.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ The <emphasis>dependencies are injected</emphasis> by
the service instantiation process.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- <emphasis role="bold">Dependency Injection</emphasis> You also
saw two types of dependency injections:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Constructor injection: The constructor is called by the container.
- </para>
+ </itemizedlist>
+ <para>
+ <emphasis role="bold">Dependency
Injection</emphasis> You also saw two types of dependency injections:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Constructor injection: The constructor is called by the
container.
+ </para>
- </listitem>
- <listitem>
- <para>
- Setter injection: Whenever you use
<emphasis>external-plugins</emphasis> to provide your service with plugins
(see <xref linkend="sect-Reference_Guide-Service_Configuration_in_Detail"
/>.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ Setter injection: Whenever you use
<emphasis>external-plugins</emphasis> to provide your service with plugins
(see <xref linkend="sect-Reference_Guide-Service_Configuration_in_Detail"
/>.
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
- </section>
-
- <section id="sect-Reference_Guide-Miscellaneous-More_Containers">
- <title>More Containers</title>
- <para>
- There are two more Containers called
<classname>RepositoryContainer</classname> and
<classname>WorkspaceContainer</classname>. These are specificities of eXo JCR,
for the sake of simplicity. You don't need them.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Miscellaneous-More_Containers">
+ <title>More Containers</title>
+ <para>
+ There are two more Containers called
<classname>RepositoryContainer</classname> and
<classname>WorkspaceContainer</classname>. These are specificities of eXo JCR,
for the sake of simplicity. You don't need them.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Miscellaneous-Single_Implementation_Services">
- <title>Single Implementation Services</title>
- <para>
- In some case the developer of a service does not expect that there will be several
implementations for his service. Therefore he does not create an interface. In this case
the configuration looks like this:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-Miscellaneous-Single_Implementation_Services">
+ <title>Single Implementation Services</title>
+ <para>
+ In some case the developer of a service does not expect that there will
be several implementations for his service. Therefore he does not create an interface. In
this case the configuration looks like this:
+ </para>
+
<programlisting language="XML"
role="XML"><key>org.exoplatform.services.database.jdbc.DBSchemaCreator</key>
<type>org.exoplatform.services.database.jdbc.DBSchemaCreator</type></programlisting>
- <para>
- The key and type tags contain equally the qualified class name.
- </para>
+ <para>
+ The key and type tags contain equally the qualified class name.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Miscellaneous-Configuration_properties">
- <title>Configuration properties</title>
- <para>
- Since kernel 2.0.7 and 2.1, it is possible to use system properties in literal values
of component configuration meta data. Thus it is possible to resolve properties at runtime
instead of providing a value at packaging time.
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-Miscellaneous-Configuration_properties">
+ <title>Configuration properties</title>
+ <para>
+ Since kernel 2.0.7 and 2.1, it is possible to use system properties in
literal values of component configuration meta data. Thus it is possible to resolve
properties at runtime instead of providing a value at packaging time.
+ </para>
+
<programlisting language="XML"
role="XML"><component>
...
<init-params>
@@ -590,19 +477,19 @@
</init-params>
</component></programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-Miscellaneous-Configuration_Logging">
- <title>Configuration Logging</title>
- <para>
- In case you need to solve problems with your service configuration, you have to know
from which JAR/WAR causes your troubles. Add the JVM system property
<parameter>org.exoplatform.container.configuration.debug</parameter> to your
eXo.bat or eXo.sh file (exo-tomcat/bin/).
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-Miscellaneous-Configuration_Logging">
+ <title>Configuration Logging</title>
+ <para>
+ In case you need to solve problems with your service configuration, you
have to know from which JAR/WAR causes your troubles. Add the JVM system property
<parameter>org.exoplatform.container.configuration.debug</parameter> to your
eXo.bat or eXo.sh file (exo-tomcat/bin/).
+ </para>
+
<programlisting>set
EXO_CONFIG_OPTS="-Dorg.exoplatform.container.configuration.debug"</programlisting>
- <para>
- If this property is set the container configuration manager reports during startup
the configuration retrieval process to the standard output (System.out).
- </para>
-
+ <para>
+ If this property is set the container configuration manager reports
during startup the configuration retrieval process to the standard output (System.out).
+ </para>
+
<programlisting>......
Add configuration
jar:file:/D:/Projects/eXo/dev/exo-working/exo-tomcat/lib/exo.kernel.container-trunk.jar!/conf/portal/configuration.xml
Add configuration
jar:file:/D:/Projects/eXo/dev/exo-working/exo-tomcat/lib/exo.kernel.component.cache-trunk.jar!/conf/portal/configuration.xml
@@ -611,21 +498,21 @@
import jndi:/localhost/portal/WEB-INF/conf/jcr/jcr-configuration.xml
......</programlisting>
- </section>
-
+ </section>
+
- </section>
-
- <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Further_Reading">
- <title>Further Reading</title>
- <para>
- Do you feel an expert now? Not yet. Get a deeper look and read this <xref
linkend="sect-Reference_Guide-Services_Wiring" /> article. You read so much
about configuration, that you should wonder what the <xref
linkend="sect-Reference_Guide-Container_Configuration-Kernel_configuration_namespace"
/> looks like.
- </para>
- <para>
- If you wish to see a examples of service configurations you should study the <xref
linkend="sect-Reference_Guide-eXo_Core" /> Where you find descriptions of
some eXo's core services. Finally you might wish to read more about <ulink
url="http://www.picocontainer.org/">PicoContainer</ulink>.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Service_Configuration_for_Beginners-Further_Reading">
+ <title>Further Reading</title>
+ <para>
+ Do you feel an expert now? Not yet. Get a deeper look and read this <xref
linkend="sect-Reference_Guide-Services_Wiring" /> article. You read so much
about configuration, that you should wonder what the <xref
linkend="sect-Reference_Guide-Container_Configuration-Kernel_configuration_namespace"
/> looks like.
+ </para>
+ <para>
+ If you wish to see a examples of service configurations you should study the
<xref linkend="sect-Reference_Guide-eXo_Core" /> Where you find
descriptions of some eXo's core services. Finally you might wish to read more about
<ulink
url="http://www.picocontainer.org/">PicoContainer</ulink>.
+ </para>
- </section>
+ </section>
</section>
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/service-configuration-in-detail.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/service-configuration-in-detail.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/service-configuration-in-detail.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -4,86 +4,86 @@
%BOOK_ENTITIES;
]>
<section id="sect-Reference_Guide-Service_Configuration_in_Detail">
- <title>Service Configuration in Detail</title>
- <para>
- <emphasis role="bold">Related documents</emphasis>
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <xref linkend="sect-Reference_Guide-Service_Configuration_for_Beginners"
/>
- </para>
+ <title>Service Configuration in Detail</title>
+ <para>
+ <emphasis role="bold">Related documents</emphasis>
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <xref
linkend="sect-Reference_Guide-Service_Configuration_for_Beginners" />
+ </para>
- </listitem>
- <listitem>
- <para>
- <xref linkend="sect-Reference_Guide-Services_Wiring" />
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <xref linkend="sect-Reference_Guide-Services_Wiring" />
+ </para>
- </listitem>
- <listitem>
- <para>
- <xref
linkend="sect-Reference_Guide-Container_Configuration-Kernel_configuration_namespace"
/>
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <xref
linkend="sect-Reference_Guide-Container_Configuration-Kernel_configuration_namespace"
/>
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <section
id="sect-Reference_Guide-Service_Configuration_in_Detail-Objectives">
- <title>Objectives</title>
- <para>
- This article shows how to setup a sample service with some configurations and how to
access to the configuration parameters. The later sections describe all details of the
configuration file (parameters, object-params, plugins, imports, etc.), it also shows how
to access the configuration values. You may consider this article as a <emphasis
role="bold">reference</emphasis>, but you can also use this article as
a <emphasis role="bold">tutorial</emphasis> and read it from the
beginning to the end.
- </para>
+ </itemizedlist>
+ <section
id="sect-Reference_Guide-Service_Configuration_in_Detail-Objectives">
+ <title>Objectives</title>
+ <para>
+ This article shows how to setup a sample service with some configurations and
how to access to the configuration parameters. The later sections describe all details of
the configuration file (parameters, object-params, plugins, imports, etc.), it also shows
how to access the configuration values. You may consider this article as a <emphasis
role="bold">reference</emphasis>, but you can also use this article as
a <emphasis role="bold">tutorial</emphasis> and read it from the
beginning to the end.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Service_Configuration_in_Detail-Requirements">
- <title>Requirements</title>
- <para>
- You should have read and understood <xref
linkend="sect-Reference_Guide-Service_Configuration_for_Beginners" />.
Obviously you should know java and xml. We are working with examples that are created for
teaching reasons only and you will see extracts from the eXo Products default
installation. When reading this article, you do not forget that the terms service and
component are interchangeable in eXo Products.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Service_Configuration_in_Detail-Requirements">
+ <title>Requirements</title>
+ <para>
+ You should have read and understood <xref
linkend="sect-Reference_Guide-Service_Configuration_for_Beginners" />.
Obviously you should know java and xml. We are working with examples that are created for
teaching reasons only and you will see extracts from the eXo Products default
installation. When reading this article, you do not forget that the terms service and
component are interchangeable in eXo Products.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Service_Configuration_in_Detail-Sample_Service">
- <title>Sample Service</title>
- <section id="sect-Reference_Guide-Sample_Service-Java_Class">
- <title>Java Class</title>
- <para>
- Imagine that you are working for a publishing company called "La Verdad"
that is going to use eXo platform. Your boss asks you be able to calculate the number of
sentences of an article.
- </para>
- <para>
- You remember in eXo product everything is a <emphasis
role="bold">service</emphasis> so you decide to create a simple class.
In the future, you want to be able to plug different implementations of your service, so
that you should define an <emphasis role="bold">interface</emphasis>
that defines your service.
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-Service_Configuration_in_Detail-Sample_Service">
+ <title>Sample Service</title>
+ <section id="sect-Reference_Guide-Sample_Service-Java_Class">
+ <title>Java Class</title>
+ <para>
+ Imagine that you are working for a publishing company called "La
Verdad" that is going to use eXo platform. Your boss asks you be able to calculate
the number of sentences of an article.
+ </para>
+ <para>
+ You remember in eXo product everything is a <emphasis
role="bold">service</emphasis> so you decide to create a simple class.
In the future, you want to be able to plug different implementations of your service, so
that you should define an <emphasis role="bold">interface</emphasis>
that defines your service.
+ </para>
+
<programlisting language="Java" role="Java">package
com.laverdad.services;
public interface ArticleStatsService {
public abstract int calcSentences(String article);
}</programlisting>
- <para>
- A very simple implementation:
- </para>
-
+ <para>
+ A very simple implementation:
+ </para>
+
<programlisting language="Java" role="Java">public class
ArticleStatsServiceImpl implements ArticleStatsService {
public int calcSentences(String article) {
throw new RuntimeException("Not implemented");
}
}</programlisting>
- <para>
- That's it! You see there are no special prerequisites for a service.
- </para>
- <para>
- You should already have prepared your working environment, where you have a base
folder (let's call it our service base folder). If you wish to try out this example
create this class in the com/laverdad/services/ArticleStatsService subfolder.
- </para>
+ <para>
+ That's it! You see there are no special prerequisites for a service.
+ </para>
+ <para>
+ You should already have prepared your working environment, where you have
a base folder (let's call it our service base folder). If you wish to try out this
example create this class in the com/laverdad/services/ArticleStatsService subfolder.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Sample_Service-First_configuration_file">
- <title>First configuration file</title>
- <para>
- When creating a service, you also should declare its existence to the <emphasis
role="bold">Container</emphasis>, therefore you create a first simple
configuration file. Copy the following code to a file called "configuration.xml"
and place this file in a /conf subdirectory of your service base folder. As you already
know the container looks for a "/conf/configuration.xml" file in each jar-file.
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-Sample_Service-First_configuration_file">
+ <title>First configuration file</title>
+ <para>
+ When creating a service, you also should declare its existence to the
<emphasis role="bold">Container</emphasis>, therefore you create a
first simple configuration file. Copy the following code to a file called
"configuration.xml" and place this file in a /conf subdirectory of your service
base folder. As you already know the container looks for a
"/conf/configuration.xml" file in each jar-file.
+ </para>
+
<programlisting language="XML" role="XML"><?xml
version="1.0" encoding="UTF8"?>
<configuration
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -94,27 +94,27 @@
<type>com.laverdad.services.ArticleStatsServiceImpl</type>
</component>
</configuration></programlisting>
- <note>
- <para>
- You are correctly using the namespace of the configuration schema (
<
uri>http://www.exoplaform.org/xml/ns/kernel_1_1.xsd</uri>). Most of the
configuration schema is explained in this article, therefore you do not need to open and
understand the schema. For backward compatibility it is not necessary to declare the
schema.
- </para>
- <para>
- When eXo kernel reads a configuration, it loads the file from the kernel jar using
the classloader and does not use an internet connection to resolve the file.
- </para>
+ <note>
+ <para>
+ You are correctly using the namespace of the configuration schema (
<
uri>http://www.exoplaform.org/xml/ns/kernel_1_1.xsd</uri>). Most of the
configuration schema is explained in this article, therefore you do not need to open and
understand the schema. For backward compatibility it is not necessary to declare the
schema.
+ </para>
+ <para>
+ When eXo kernel reads a configuration, it loads the file from the
kernel jar using the classloader and does not use an internet connection to resolve the
file.
+ </para>
- </note>
+ </note>
- </section>
-
- <section id="sect-Reference_Guide-Sample_Service-Init_Parameters">
- <title>Init Parameters</title>
- <para>
- You see your service has a configuration file, but you wonder how the file could
possibly access to its configuration. Imagine that you are asked to implement two
different calculation methods: fast and exact.
- </para>
- <para>
- You create one init parameter containing the calculation methods. For the exact
method, you wish to configure more details for the service. Let's enhance the word
service configuration file:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-Sample_Service-Init_Parameters">
+ <title>Init Parameters</title>
+ <para>
+ You see your service has a configuration file, but you wonder how the
file could possibly access to its configuration. Imagine that you are asked to implement
two different calculation methods: fast and exact.
+ </para>
+ <para>
+ You create one init parameter containing the calculation methods. For the
exact method, you wish to configure more details for the service. Let's enhance the
word service configuration file:
+ </para>
+
<programlisting language="XML" role="XML">
<component>
<key>com.laverdad.services.ArticleStatsService</key>
<type>com.laverdad.services.ArticleStatsServiceImpl</type>
@@ -132,16 +132,16 @@
</properties-param>
</init-params>
</component></programlisting>
- <note>
- <para>
- When configuring your service, you are <emphasis role="bold">totally
free</emphasis>. You can provide as many <emphasis
role="bold">value-param</emphasis>, <emphasis
role="bold">property-param</emphasis>, and <emphasis
role="bold">properties</emphasis> you wish and you can give them any
names or values. You only must respect the xml structure.
- </para>
+ <note>
+ <para>
+ When configuring your service, you are <emphasis
role="bold">totally free</emphasis>. You can provide as many
<emphasis role="bold">value-param</emphasis>, <emphasis
role="bold">property-param</emphasis>, and <emphasis
role="bold">properties</emphasis> you wish and you can give them any
names or values. You only must respect the xml structure.
+ </para>
- </note>
- <para>
- Now let's see how our service can read this configuration. The implementation of
the calcSentences() method serves just as a simple example. It's up to your
imagination to implement the exact method.
- </para>
-
+ </note>
+ <para>
+ Now let's see how our service can read this configuration. The
implementation of the calcSentences() method serves just as a simple example. It's up
to your imagination to implement the exact method.
+ </para>
+
<programlisting language="Java" role="Java">public class
ArticleStatsServiceImpl implements ArticleStatsService {
private String calcMethod = "fast";
@@ -173,60 +173,57 @@
throw new RuntimeException("Not implemented");
}
}</programlisting>
- <para>
- You see you just have to declare a parameter of
org.exoplatform.container.xml.InitParams in your constructor. The container provides an
InitParams object that correspond to the xml tree of init-param.
- </para>
+ <para>
+ You see you just have to declare a parameter of
org.exoplatform.container.xml.InitParams in your constructor. The container provides an
InitParams object that correspond to the xml tree of init-param.
+ </para>
- </section>
-
- <section id="sect-Reference_Guide-Sample_Service-Service_Access">
- <title>Service Access</title>
- <para>
- As you want to follow the principle of <emphasis
role="bold">Inversion of Control,</emphasis> you <emphasis
role="bold">must not</emphasis> access the service directly. You need a
<emphasis role="bold">Container</emphasis> to access the service.
- </para>
- <para>
- With this command you get your current container:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <emphasis role="bold">ExoContainer myContainer =
ExoContainerContext.getCurrentContainer();</emphasis>
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Sample_Service-Service_Access">
+ <title>Service Access</title>
+ <para>
+ As you want to follow the principle of <emphasis
role="bold">Inversion of Control,</emphasis> you <emphasis
role="bold">must not</emphasis> access the service directly. You need a
<emphasis role="bold">Container</emphasis> to access the service.
+ </para>
+ <para>
+ With this command you get your current container:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <emphasis role="bold">ExoContainer myContainer =
ExoContainerContext.getCurrentContainer();</emphasis>
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- This might be a PortalContainer or a StandaloneContainer, dependant on the <xref
linkend="sect-Reference_Guide-Service_Configuration_for_Beginners-Execution_Modes"
/> in which you are running your application.
- </para>
- <para>
- Whenever you need one of the services that you have configured use the method:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <emphasis
role="bold">myContainer.getComponentInstance(class)</emphasis>
- </para>
+ </itemizedlist>
+ <para>
+ Whenever you need one of the services that you have configured use the
method:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <emphasis
role="bold">myContainer.getComponentInstance(class)</emphasis>
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- In our case:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <emphasis role="bold">ArticleStatsService statsService =
(ArticleStatsService)
myContainer.getComponentInstance(ArticleStatsService.class);</emphasis>
- </para>
+ </itemizedlist>
+ <para>
+ In our case:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <emphasis role="bold">ArticleStatsService
statsService = (ArticleStatsService)
myContainer.getComponentInstance(ArticleStatsService.class);</emphasis>
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- Recapitulation:
- </para>
-
+ </itemizedlist>
+ <para>
+ Recapitulation:
+ </para>
+
<programlisting language="Java" role="Java">package
com.laverdad.common;
import org.exoplatform.container.ExoContainer;
@@ -251,23 +248,20 @@
System.out.println("Number of sentences: " + stats.makeStatistics(newText));
}
}</programlisting>
- <para>
- If you test this sample in standalone mode, you need to put all jars of eXo Kernel in
your buildpath, furthermore picoContainer is needed.
- </para>
+
+ </section>
+
- </section>
-
-
- </section>
-
- <section
id="sect-Reference_Guide-Service_Configuration_in_Detail-Parameters">
- <title>Parameters</title>
- <section id="sect-Reference_Guide-Parameters-Value_Param">
- <title>Value-Param</title>
- <para>
- There is an value-param example:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-Service_Configuration_in_Detail-Parameters">
+ <title>Parameters</title>
+ <section id="sect-Reference_Guide-Parameters-Value_Param">
+ <title>Value-Param</title>
+ <para>
+ There is an value-param example:
+ </para>
+
<programlisting language="XML" role="XML">
<component>
<key>org.exoplatform.portal.config.UserACL</key>
<type>org.exoplatform.portal.config.UserACL</type>
@@ -280,10 +274,10 @@
</value-param>
...
</component></programlisting>
- <para>
- The UserACL class accesses to the <emphasis
role="bold">value-param</emphasis> in its constructor.
- </para>
-
+ <para>
+ The UserACL class accesses to the <emphasis
role="bold">value-param</emphasis> in its constructor.
+ </para>
+
<programlisting language="Java" role="Java">package
org.exoplatform.portal.config;
public class UserACL {
@@ -293,17 +287,17 @@
if(accessControlWorkspaceParam != null)
md.setAccessControlWorkspace(accessControlWorkspaceParam.getValue());
...</programlisting>
- </section>
-
- <section id="sect-Reference_Guide-Parameters-Properties_Param">
- <title>Properties-Param</title>
- <para>
- Properties are name-value pairs. Both the name and the value are Java Strings.
- </para>
- <para>
- Here you see the hibernate configuration example:
- </para>
-
+ </section>
+
+ <section id="sect-Reference_Guide-Parameters-Properties_Param">
+ <title>Properties-Param</title>
+ <para>
+ Properties are name-value pairs. Both the name and the value are Java
Strings.
+ </para>
+ <para>
+ Here you see the hibernate configuration example:
+ </para>
+
<programlisting language="XML" role="XML">
<component>
<key>org.exoplatform.services.database.HibernateService</key>
<type>org.exoplatform.services.database.impl.HibernateServiceImpl</type>
@@ -319,10 +313,10 @@
</properties-param>
</init-params>
</component></programlisting>
- <para>
- In the org.exoplatform.services.database.impl.HibernateServiceImpl you will find that
the name "hibernate.properties" of the properties-param is used to access the
properties.
- </para>
-
+ <para>
+ In the org.exoplatform.services.database.impl.HibernateServiceImpl you
will find that the name "hibernate.properties" of the properties-param is used
to access the properties.
+ </para>
+
<programlisting language="Java" role="Java">package
org.exoplatform.services.database.impl;
public class HibernateServiceImpl implements HibernateService, ComponentRequestLifecycle
{
@@ -331,14 +325,14 @@
...
}</programlisting>
- </section>
-
- <section id="sect-Reference_Guide-Parameters-Object_Param">
- <title>Object-Param</title>
- <para>
- Let's have a look at the configuration of the LDAPService. It's not important
to know LDAP, we only discuss the parameters.
- </para>
-
+ </section>
+
+ <section id="sect-Reference_Guide-Parameters-Object_Param">
+ <title>Object-Param</title>
+ <para>
+ Let's have a look at the configuration of the LDAPService. It's
not important to know LDAP, we only discuss the parameters.
+ </para>
+
<programlisting language="XML"
role="XML"><component>
<key>org.exoplatform.services.ldap.LDAPService</key>
<type>org.exoplatform.services.ldap.impl.LDAPServiceImpl</type>
@@ -359,13 +353,13 @@
</object-param>
</init-params>
</component></programlisting>
- <para>
- You see here an <emphasis role="bold">object-param</emphasis>
is being used to pass the parameters inside an object (actually a java bean). It consists
of a <emphasis role="bold">name</emphasis>, a <emphasis
role="bold">description</emphasis> and exactly one <emphasis
role="bold">object</emphasis>. The object defines the <emphasis
role="bold">type</emphasis> and a number of <emphasis
role="bold">fields</emphasis>.
- </para>
- <para>
- Here you see how the service accesses the object:
- </para>
-
+ <para>
+ You see here an <emphasis
role="bold">object-param</emphasis> is being used to pass the
parameters inside an object (actually a java bean). It consists of a <emphasis
role="bold">name</emphasis>, a <emphasis
role="bold">description</emphasis> and exactly one <emphasis
role="bold">object</emphasis>. The object defines the <emphasis
role="bold">type</emphasis> and a number of <emphasis
role="bold">fields</emphasis>.
+ </para>
+ <para>
+ Here you see how the service accesses the object:
+ </para>
+
<programlisting language="Java" role="Java">package
org.exoplatform.services.ldap.impl;
public class LDAPServiceImpl implements LDAPService {
@@ -374,10 +368,10 @@
LDAPConnectionConfig config = (LDAPConnectionConfig)
params.getObjectParam("ldap.config")
.getObject();
...</programlisting>
- <para>
- The passed object is LDAPConnectionConfig which is a classic <emphasis
role="bold">java bean</emphasis>. It contains all fields and also the
appropriate getters and setters (not listed here). You also can provide default values.
The container creates a new instance of your bean and calls all setters whose values are
configured in the configuration file.
- </para>
-
+ <para>
+ The passed object is LDAPConnectionConfig which is a classic <emphasis
role="bold">java bean</emphasis>. It contains all fields and also the
appropriate getters and setters (not listed here). You also can provide default values.
The container creates a new instance of your bean and calls all setters whose values are
configured in the configuration file.
+ </para>
+
<programlisting language="Java" role="Java">package
org.exoplatform.services.ldap.impl;
public class LDAPConnectionConfig {
@@ -391,36 +385,36 @@
private int maxConnection;
private String referralMode = "follow";
...</programlisting>
- <para>
- You see that the types (String, int) of the fields in the configuration correspond
with the bean. A short glance in the kernel_1_0.xsd file let us discover more simple
types:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <emphasis role="bold">string, int, long, boolean, date,
double</emphasis>
- </para>
+ <para>
+ You see that the types (String, int) of the fields in the configuration
correspond with the bean. A short glance in the kernel_1_0.xsd file let us discover more
simple types:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <emphasis role="bold">string, int, long, boolean,
date, double</emphasis>
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- Have a look on this type test xml file: <ulink
url="https://anonsvn.jboss.org/repos/exo-jcr/kernel/trunk/exo.kernel...;.
- </para>
+ </itemizedlist>
+ <para>
+ Have a look on this type test xml file: <ulink
url="https://anonsvn.jboss.org/repos/exo-jcr/kernel/trunk/exo.kernel...;.
+ </para>
- </section>
-
- <section id="sect-Reference_Guide-Parameters-Collection">
- <title>Collection</title>
- <para>
- You also can use java collections to configure your service. In order to see an
example, let's open the database-organization-configuration.xml file. This file
defines a default user organization (users, groups, memberships/roles) of your portal.
They use component-plugins which are explained later. You wil see that object-param is
used again.
- </para>
- <para>
- There are two collections: The first collection is an <emphasis
role="bold">ArrayList</emphasis>. This ArrayList contains only one
value, but there could be more. The only value is an object which defines the field of the
NewUserConfig$JoinGroup bean.
- </para>
- <para>
- The second collection is a <emphasis
role="bold">HashSet</emphasis> that is a set of strings.
- </para>
-
+ </section>
+
+ <section id="sect-Reference_Guide-Parameters-Collection">
+ <title>Collection</title>
+ <para>
+ You also can use java collections to configure your service. In order to
see an example, let's open the database-organization-configuration.xml file. This file
defines a default user organization (users, groups, memberships/roles) of your portal.
They use component-plugins which are explained later. You wil see that object-param is
used again.
+ </para>
+ <para>
+ There are two collections: The first collection is an <emphasis
role="bold">ArrayList</emphasis>. This ArrayList contains only one
value, but there could be more. The only value is an object which defines the field of the
NewUserConfig$JoinGroup bean.
+ </para>
+ <para>
+ The second collection is a <emphasis
role="bold">HashSet</emphasis> that is a set of strings.
+ </para>
+
<programlisting language="XML" role="XML">
<component-plugin>
<name>new.user.event.listener</name>
<set-method>addListenerPlugin</set-method>
@@ -454,10 +448,10 @@
</object-param>
</init-params>
</component-plugin></programlisting>
- <para>
- Let's look at the org.exoplatform.services.organization.impl.NewUserConfig bean:
- </para>
-
+ <para>
+ Let's look at the
org.exoplatform.services.organization.impl.NewUserConfig bean:
+ </para>
+
<programlisting language="Java" role="Java">public class
NewUserConfig {
private List role;
private List group;
@@ -475,33 +469,33 @@
public String membership;
...
}</programlisting>
- <para>
- You see the values of the HashSet are set one by one by the container, and it's
the responsibility of the bean to add these values to its HashSet.
- </para>
- <para>
- The JoinGroup object is just an inner class and implements a bean of its own. It can
be accessed like any other inner class using NewUserConfig.JoinGroup.
- </para>
+ <para>
+ You see the values of the HashSet are set one by one by the container,
and it's the responsibility of the bean to add these values to its HashSet.
+ </para>
+ <para>
+ The JoinGroup object is just an inner class and implements a bean of its
own. It can be accessed like any other inner class using NewUserConfig.JoinGroup.
+ </para>
- </section>
-
+ </section>
+
- </section>
-
- <section
id="sect-Reference_Guide-Service_Configuration_in_Detail-External_Plugin">
- <title>External Plugin</title>
- <para>
- The External Plugin allows you to add configuration on the fly.
- </para>
- <para>
- As you have carefully read <xref
linkend="sect-Reference_Guide-Service_Configuration_for_Beginners" /> you
know that <emphasis role="bold">normally</emphasis> newer
configurations always <emphasis role="bold">replaces</emphasis>
previous configurations. An external plugin allows you to <emphasis
role="bold">add</emphasis> configuration without replacing previous
configurations.
- </para>
- <para>
- That can be interesting if you adapt a service configuration for your project-specific
needs (country, language, branch, project, etc.).
- </para>
- <para>
- Let's have a look at the configuration of the TaxonomyPlugin of the
CategoriesService:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-Service_Configuration_in_Detail-External_Plugin">
+ <title>External Plugin</title>
+ <para>
+ The External Plugin allows you to add configuration on the fly.
+ </para>
+ <para>
+ As you have carefully read <xref
linkend="sect-Reference_Guide-Service_Configuration_for_Beginners" /> you
know that <emphasis role="bold">normally</emphasis> newer
configurations always <emphasis role="bold">replaces</emphasis>
previous configurations. An external plugin allows you to <emphasis
role="bold">add</emphasis> configuration without replacing previous
configurations.
+ </para>
+ <para>
+ That can be interesting if you adapt a service configuration for your
project-specific needs (country, language, branch, project, etc.).
+ </para>
+ <para>
+ Let's have a look at the configuration of the TaxonomyPlugin of the
CategoriesService:
+ </para>
+
<programlisting language="XML" role="XML">
<external-component-plugins>
<target-component>org.exoplatform.services.cms.categories.CategoriesService</target-component>
<component-plugin>
@@ -542,81 +536,65 @@
</init-params>
</component-plugin>
<external-component-plugins></programlisting>
- <para>
- The <emphasis
role="bold"><target-component></emphasis> defines the
service for which the plugin is defined. The configuration is injected by the container
using a method that is defined in <emphasis
role="bold"><set-method></emphasis>. The method has
exactly one argument of the type
org.exoplatform.services.cms.categories.impl.TaxonomyPlugin:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- addTaxonomyPlugin(org.exoplatform.services.cms.categories.impl.TaxonomyPlugin
plugin)
- </para>
+ <para>
+ The <emphasis
role="bold"><target-component></emphasis> defines the
service for which the plugin is defined. The configuration is injected by the container
using a method that is defined in <emphasis
role="bold"><set-method></emphasis>. The method has
exactly one argument of the type
org.exoplatform.services.cms.categories.impl.TaxonomyPlugin:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+
addTaxonomyPlugin(org.exoplatform.services.cms.categories.impl.TaxonomyPlugin plugin)
+ </para>
- </listitem>
+ </listitem>
- </itemizedlist>
- <para>
- The content of <emphasis
role="bold"><init-params></emphasis> corresponds to the
structure of the TaxonomyPlugin object.
- </para>
- <note>
- <para>
- You can configure the component CategoriesService using the addTaxonomyPlugin as
often as you wish, you can also call addTaxonomyPlugin in different configuration files.
The method addTaxonomyPlugin is then called several times, everything else depends on the
implementation of the method.
- </para>
+ </itemizedlist>
+ <para>
+ The content of <emphasis
role="bold"><init-params></emphasis> corresponds to the
structure of the TaxonomyPlugin object.
+ </para>
+ <note>
+ <para>
+ You can configure the component CategoriesService using the
addTaxonomyPlugin as often as you wish, you can also call addTaxonomyPlugin in different
configuration files. The method addTaxonomyPlugin is then called several times, everything
else depends on the implementation of the method.
+ </para>
- </note>
+ </note>
- </section>
-
- <section
id="sect-Reference_Guide-Service_Configuration_in_Detail-Import">
- <title>Import</title>
- <para>
- The import tag allows to link to other configuration files. These imported files can
be placed anywhere. If you write a default configuration which is part of your jar file
you should not import files from outside your jar.
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <emphasis role="bold">war</emphasis>: Imports from
<emphasis role="bold">portal.war/WEB-INF</emphasis>
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Service_Configuration_in_Detail-Import">
+ <title>Import</title>
+ <para>
+ The import tag allows to link to other configuration files. These imported
files can be placed anywhere. If you write a default configuration which is part of your
jar file you should not import files from outside your jar.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <emphasis role="bold">war</emphasis>: Imports
from <emphasis role="bold">portal.war/WEB-INF</emphasis>
+ </para>
- </listitem>
- <listitem>
- <para>
- <emphasis role="bold">jar</emphasis> or <emphasis
role="bold">classpath</emphasis>: Uses the <emphasis
role="bold">classloader</emphasis>, you can use this prefix in the
default configuration for importing an other configuration file which is accessible by the
classloader.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">jar</emphasis> or
<emphasis role="bold">classpath</emphasis>: Uses the <emphasis
role="bold">classloader</emphasis>, you can use this prefix in the
default configuration for importing an other configuration file which is accessible by the
classloader.
+ </para>
- </listitem>
- <listitem>
- <para>
- <emphasis role="bold">file</emphasis>: Uses an <emphasis
role="bold">absolute path</emphasis>, you also can put a <emphasis
role="bold">URL</emphasis>.
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">file</emphasis>: Uses an
<emphasis role="bold">absolute path</emphasis>, you also can put a
<emphasis role="bold">URL</emphasis>.
+ </para>
- </listitem>
- <listitem>
- <para>
- <emphasis role="bold">without any prefix</emphasis>:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Standalone mode: <emphasis role="bold">user
directory</emphasis>
- </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">without any
prefix</emphasis>:
+ </para>
+ </listitem>
- </listitem>
- <listitem>
- <para>
- Portal mode: $AS-HOME, that means the application server home, for example "
<emphasis role="bold">exo-tomcat</emphasis>".
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </listitem>
-
- </itemizedlist>
- <para>
- If you open the
"portal/trunk/web/portal/src/main/webapp/WEB-INF/conf.configuration.xml" you
will see that it consists only of imports:
- </para>
-
+ </itemizedlist>
+ <para>
+ If you open the
"portal/trunk/web/portal/src/main/webapp/WEB-INF/conf.configuration.xml" you
will see that it consists only of imports:
+ </para>
+
<programlisting language="XML"
role="XML"><import>war:/conf/common/common-configuration.xml</import>
<import>war:/conf/common/logs-configuration.xml</import>
<import>war:/conf/database/database-configuration.xml</import>
@@ -624,17 +602,17 @@
<import>war:/conf/common/portlet-container-configuration.xml</import>
...</programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-Service_Configuration_in_Detail-System_properties">
- <title>System properties</title>
- <para>
- Since kernel 2.0.7 and 2.1, it is possible to use system properties in literal values
of component configuration meta data. This makes it possible to resolve properties at
runtime instead of providing a value at packaging time.
- </para>
- <para>
- In
portal/trunk/web/portal/src/main/webapp/WEB-INF/conf/database/database-configuration.tmpl.xml
you find an example for system properties:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-Service_Configuration_in_Detail-System_properties">
+ <title>System properties</title>
+ <para>
+ Since kernel 2.0.7 and 2.1, it is possible to use system properties in
literal values of component configuration meta data. This makes it possible to resolve
properties at runtime instead of providing a value at packaging time.
+ </para>
+ <para>
+ In
portal/trunk/web/portal/src/main/webapp/WEB-INF/conf/database/database-configuration.tmpl.xml
you find an example for system properties:
+ </para>
+
<programlisting language="XML" role="XML">
<component>
<key>org.exoplatform.services.database.HibernateService</key>
<jmx-name>database:type=HibernateService</jmx-name>
@@ -653,11 +631,11 @@
</properties-param>
</init-params>
</component></programlisting>
- <para>
- As these are system properties you use the -D command: <emphasis
role="bold">java -DconnectionUrl=jdbc:hsqldb:file:../temp/data/exodb
-DdriverClass=org.hsqldb.jdbcDriver</emphasis> Or better use the parameters of
eXo.bat / eXo.sh when you start eXo Portal: <emphasis role="bold">set
EXO_OPTS="-DconnectionUrl=jdbc:hsqldb:file:../temp/data/exodb
-DdriverClass=org.hsqldb.jdbcDriver"</emphasis>
- </para>
+ <para>
+ As these are system properties you use the -D command: <emphasis
role="bold">java -DconnectionUrl=jdbc:hsqldb:file:../temp/data/exodb
-DdriverClass=org.hsqldb.jdbcDriver</emphasis> Or better use the parameters of
eXo.bat / eXo.sh when you start eXo Portal: <emphasis role="bold">set
EXO_OPTS="-DconnectionUrl=jdbc:hsqldb:file:../temp/data/exodb
-DdriverClass=org.hsqldb.jdbcDriver"</emphasis>
+ </para>
- </section>
+ </section>
</section>
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/transaction-service.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/transaction-service.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/kernel/transaction-service.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -4,111 +4,92 @@
%BOOK_ENTITIES;
]>
<section id="sect-Reference_Guide-TransactionService">
- <title>TransactionService</title>
- <section
id="sect-Reference_Guide-TransactionService-Base_information">
- <title>Base information</title>
- <para>
- TransactionServices provides access to the TransactionManager and the UserTransaction
(See JTA specification for details).
- </para>
- <table id="tabl-Reference_Guide-Base_information-List_methods">
- <title>List methods</title>
- <tgroup cols="2">
- <tbody>
- <row>
- <entry>
- getTransactionManager()
- </entry>
- <entry>
- Get used TransactionManager
- </entry>
+ <title>TransactionService</title>
+ <section
id="sect-Reference_Guide-TransactionService-Base_information">
+ <title>Base information</title>
+ <para>
+ TransactionServices provides access to the TransactionManager and the
UserTransaction (See JTA specification for details).
+ </para>
+ <table id="tabl-Reference_Guide-Base_information-List_methods">
+ <title>List methods</title>
+ <tgroup cols="2">
+ <tbody>
+ <row>
+ <entry>
+ getTransactionManager()
+ </entry>
+ <entry>
+ Get used TransactionManager
+ </entry>
- </row>
- <row>
- <entry>
- getUserTransaction()
- </entry>
- <entry>
- Get UserTransaction on TransactionManager
- </entry>
+ </row>
+ <row>
+ <entry>
+ getUserTransaction()
+ </entry>
+ <entry>
+ Get UserTransaction on TransactionManager
+ </entry>
- </row>
- <row>
- <entry>
- getDefaultTimeout()
- </entry>
- <entry>
- Return default TimeOut
- </entry>
+ </row>
+ <row>
+ <entry>
+ getDefaultTimeout()
+ </entry>
+ <entry>
+ Return default TimeOut
+ </entry>
- </row>
- <row>
- <entry>
- setTransactionTimeout(int seconds)
- </entry>
- <entry>
- Set TimeOut in second
- </entry>
+ </row>
+ <row>
+ <entry>
+ setTransactionTimeout(int seconds)
+ </entry>
+ <entry>
+ Set TimeOut in second
+ </entry>
- </row>
- <row>
- <entry>
- enlistResource(XAResource xares)
- </entry>
- <entry>
- Enlist XA resource in TransactionManager
- </entry>
+ </row>
+ <row>
+ <entry>
+ enlistResource(XAResource xares)
+ </entry>
+ <entry>
+ Enlist XA resource in TransactionManager
+ </entry>
- </row>
- <row>
- <entry>
- delistResource(XAResource xares)
- </entry>
- <entry>
- Delist XA resource from TransactionManager
- </entry>
+ </row>
+ <row>
+ <entry>
+ delistResource(XAResource xares)
+ </entry>
+ <entry>
+ Delist XA resource from TransactionManager
+ </entry>
- </row>
+ </row>
- </tbody>
+ </tbody>
- </tgroup>
+ </tgroup>
- </table>
+ </table>
- </section>
-
- <section
id="sect-Reference_Guide-TransactionService-Existing_TransactionService_implementations">
- <title>Existing TransactionService implementations</title>
- <para>
- eXo JCR proposes out of the box several implementations, they all implement the
abstract class
<emphasis>org.exoplatform.services.transaction.impl.AbstractTransactionService</emphasis>.
This main class implement the biggest part of all the methods proposed by the
<emphasis>TransactionService</emphasis>. For each sub-class of
<emphasis>AbstractTransactionService</emphasis>, you can set the transaction
timeout by configuration using the value parameter
<emphasis>timeout</emphasis> that is expressed in seconds.
- </para>
- <section
id="sect-Reference_Guide-Existing_TransactionService_implementations-JOTM_in_standalone_mode">
- <title>JOTM in standalone mode</title>
- <para>
- To use JOTM as TransactionManager in standalone mode, simply add the following
component configuration:
- </para>
-
-<programlisting> <component>
-
<key>org.exoplatform.services.transaction.TransactionService</key>
-
<type>org.exoplatform.services.transaction.impl.jotm.TransactionServiceJotmImpl</type>
- <!-- Uncomment the lines below if you want to set default transaction
timeout that is expressed in seconds -->
- <!--init-params>
- <value-param>
- <name>timeout</name>
- <value>60</value>
- </value-param>
- </init-params-->
- </component></programlisting>
-
- </section>
-
- <section
id="sect-Reference_Guide-Existing_TransactionService_implementations-Generic_TransactionService_based_on_the_TransactionManagerLookup_of_JBoss_Cache">
- <title>Generic TransactionService based on the TransactionManagerLookup of JBoss
Cache</title>
- <para>
- If you intend to use JBoss Cache, you can use a generic TransactionService based on
its TransactionManagerLookup which is able to automatically find the TransactionManager of
several Application Servers thanks to a set of JNDI lookups. This generic
TransactionService covers mainly the TransactionManager lookups, the UserTransaction is
actually simply the TransactionManager instance that has been wrapped. See below an
example of configuration:
- </para>
-
-<programlisting> <!-- Configuration of the TransactionManagerLookup
-->
+ </section>
+
+ <section
id="sect-Reference_Guide-TransactionService-Existing_TransactionService_implementations">
+ <title>Existing TransactionService implementations</title>
+ <para>
+ eXo JCR proposes out of the box several implementations, they all implement
the abstract class
<emphasis>org.exoplatform.services.transaction.impl.AbstractTransactionService</emphasis>.
This main class implement the biggest part of all the methods proposed by the
<emphasis>TransactionService</emphasis>. For each sub-class of
<emphasis>AbstractTransactionService</emphasis>, you can set the transaction
timeout by configuration using the value parameter
<emphasis>timeout</emphasis> that is expressed in seconds.
+ </para>
+
+ <section
id="sect-Reference_Guide-Existing_TransactionService_implementations-Generic_TransactionService_based_on_the_TransactionManagerLookup_of_JBoss_Cache">
+ <title>Generic TransactionService based on the TransactionManagerLookup
of JBoss Cache</title>
+ <para>
+ If you intend to use JBoss Cache, you can use a generic
TransactionService based on its TransactionManagerLookup which is able to automatically
find the TransactionManager of several Application Servers thanks to a set of JNDI
lookups. This generic TransactionService covers mainly the TransactionManager lookups, the
UserTransaction is actually simply the TransactionManager instance that has been wrapped.
See below an example of configuration:
+ </para>
+
+<programlisting> <![CDATA[ <!-- Configuration of the
TransactionManagerLookup -->
<component>
<key>org.jboss.cache.transaction.TransactionManagerLookup</key>
<type>org.jboss.cache.transaction.GenericTransactionManagerLookup</type>
@@ -124,94 +105,17 @@
<value>60</value>
</value-param>
</init-params-->
- </component></programlisting>
-
- </section>
-
- <section
id="sect-Reference_Guide-Existing_TransactionService_implementations-Specific_GenericTransactionService_for_JBoss_Cache_and_Arjuna">
- <title>Specific GenericTransactionService for JBoss Cache and
Arjuna</title>
- <para>
- If you intend to use JBoss Cache with Arjuna, you can use a more specific
GenericTransactionService, it is mostly interesting in case you want to use the real
UserTransaction. See below an example of configuration:
- </para>
-
-<programlisting> <!-- Configuration of the TransactionManagerLookup
-->
- <component>
-
<key>org.jboss.cache.transaction.TransactionManagerLookup</key>
-
<type>org.jboss.cache.transaction.JBossStandaloneJTAManagerLookup</type>
</component>
- <!-- Configuration of the TransactionService -->
- <component>
-
<key>org.exoplatform.services.transaction.TransactionService</key>
-
<type>org.exoplatform.services.transaction.jbosscache.JBossTransactionsService</type>
- <!-- Uncomment the lines below if you want to set default transaction
timeout that is expressed in seconds -->
- <!--init-params>
- <value-param>
- <name>timeout</name>
- <value>60</value>
- </value-param>
- </init-params-->
- </component></programlisting>
+]]></programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-Existing_TransactionService_implementations-Generic_TransactionService_based_on_the_TransactionManagerLookup_of_Infinispan">
- <title>Generic TransactionService based on the TransactionManagerLookup of
Infinispan</title>
- <para>
- If you intend to use Infinispan, you can use a generic TransactionService based on
its TransactionManagerLookup which is able to automatically find the TransactionManager of
several Application Servers thanks to a set of JNDI lookups. This generic
TransactionService covers mainly the TransactionManager lookups, the UserTransaction is
actually simply the TransactionManager instance that has been wrapped. See below an
example of configuration:
- </para>
-
-<programlisting> <!-- Configuration of the TransactionManagerLookup
-->
- <component>
-
<key>org.infinispan.transaction.lookup.TransactionManagerLookup</key>
-
<type>org.infinispan.transaction.lookup.GenericTransactionManagerLookup</type>
- </component>
- <!-- Configuration of the TransactionService -->
- <component>
-
<key>org.exoplatform.services.transaction.TransactionService</key>
-
<type>org.exoplatform.services.transaction.infinispan.GenericTransactionService</type>
- <!-- Uncomment the lines below if you want to set default transaction
timeout that is expressed in seconds -->
- <!--init-params>
- <value-param>
- <name>timeout</name>
- <value>60</value>
- </value-param>
- </init-params-->
- </component></programlisting>
-
- </section>
-
- <section
id="sect-Reference_Guide-Existing_TransactionService_implementations-Specific_GenericTransactionService_for_Infinispan_and_Arjuna">
- <title>Specific GenericTransactionService for Infinispan and
Arjuna</title>
- <para>
- If you intend to use Infinispan with Arjuna, you can use a more specific
GenericTransactionService, it is mostly interesting in case you want to use the real
UserTransaction. See below an example of configuration:
- </para>
-
-<programlisting> <!-- Configuration of the TransactionManagerLookup
-->
- <component>
-
<key>org.infinispan.transaction.lookup.TransactionManagerLookup</key>
-
<type>org.infinispan.transaction.lookup.JBossStandaloneJTAManagerLookup</type>
- </component>
- <!-- Configuration of the TransactionService -->
- <component>
-
<key>org.exoplatform.services.transaction.TransactionService</key>
-
<type>org.exoplatform.services.transaction.infinispan.JBossTransactionsService</type>
- <!-- Uncomment the lines below if you want to set default transaction
timeout that is expressed in seconds -->
- <!--init-params>
- <value-param>
- <name>timeout</name>
- <value>60</value>
- </value-param>
- </init-params-->
- </component></programlisting>
-
- </section>
-
- <section
id="sect-Reference_Guide-Existing_TransactionService_implementations-A_very_specific_TransactionService_for_JBoss_AS">
- <title>A very specific TransactionService for JBoss AS</title>
- <para>
- If you intend to use JBoss AS with JBoss Cache and Infinispan, you can use a very
specific TransactionService for JBoss AS. See below an example of configuration:
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-Existing_TransactionService_implementations-A_very_specific_TransactionService_for_JBoss_AS">
+ <title>A very specific TransactionService for JBoss AS</title>
+ <para>
+ If you intend to use JBoss AS with JBoss Cache and Infinispan, you can
use a very specific TransactionService for JBoss AS. See below an example of
configuration:
+ </para>
+
<programlisting> <component>
<key>org.exoplatform.services.transaction.TransactionService</key>
<type>org.exoplatform.services.transaction.impl.jboss.JBossTransactionService</type>
@@ -224,31 +128,11 @@
</init-params-->
</component></programlisting>
- </section>
-
- <section
id="sect-Reference_Guide-Existing_TransactionService_implementations-TransactionsEssentials_in_standalone_mode">
- <title>TransactionsEssentials in standalone mode</title>
- <para>
- To use TransactionsEssentials as TransactionManager in standalone mode, simply add
the following component configuration:
- </para>
-
-<programlisting> <component>
-
<key>org.exoplatform.services.transaction.TransactionService</key>
-
<type>org.exoplatform.services.transaction.impl.atomikos.TransactionsEssentialsTransactionService</type>
- <!-- Uncomment the lines below if you want to set default transaction
timeout that is expressed in seconds -->
- <!--init-params>
- <value-param>
- <name>timeout</name>
- <value>60</value>
- </value-param>
- </init-params-->
- </component></programlisting>
+ </section>
+
- </section>
-
+ </section>
- </section>
-
</section>
Deleted:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/ws.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/ws.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR/ws.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -1,17 +0,0 @@
-<?xml version='1.0' encoding='utf-8' ?>
-<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % BOOK_ENTITIES SYSTEM "Reference_Guide.ent">
-%BOOK_ENTITIES;
-]>
-<section id="sect-Reference_Guide-eXoWS">
- <title>eXoWS</title>
- <xi:include href="ws/ws.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="ws/introduction-to-rest.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="ws/overwrite-default-providers.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="ws/restservicelist-service.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="ws/groovy-scripts-as-rest-services.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="ws/framework-for-cross-domain-ajax.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
-
-</section>
-
-
Modified:
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR.xml 2011-09-27
00:32:49 UTC (rev 7507)
+++
epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/en-US/modules/Advanced/eXoJCR.xml 2011-09-27
04:38:00 UTC (rev 7508)
@@ -4,12 +4,12 @@
%BOOK_ENTITIES;
]>
<chapter id="chap-Reference_Guide-eXo_JCR">
- <title>eXo JCR</title>
- <xi:include href="eXoJCR/jcr.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="eXoJCR/kernel.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="eXoJCR/core.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="eXoJCR/ws.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="eXoJCR/faq.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="eXoJCR/jcr-with-gatein.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <title>eXo JCR</title>
+ <xi:include href="eXoJCR/jcr.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="eXoJCR/kernel.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <!--<xi:include href="eXoJCR/core.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />-->
+ <!--<xi:include href="eXoJCR/ws.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />-->
+ <xi:include href="eXoJCR/faq.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="eXoJCR/jcr-with-gatein.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
</chapter>
Modified: epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/publican.cfg
===================================================================
--- epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/publican.cfg 2011-09-27 00:32:49 UTC
(rev 7507)
+++ epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14/publican.cfg 2011-09-27 04:38:00 UTC
(rev 7508)
@@ -1,11 +1,13 @@
# Config::Simple 4.59
-# Wed Nov 11 11:32:13 2009
+# Tue Sep 27 14:25:48 2011
-xml_lang: en-US
+cvs_root: ":ext:cvs.devel.redhat.com:/cvs/dist"
+cvs_branch: "DOCS-RHEL-6"
+show_remarks: 1
+cvs_pkg: "JBoss_Enterprise_Portal_Platform-Reference_Guide-5.2-web-__LANG__"
+xml_lang: "en-US"
+mainfile: Reference_Guide
+brand: JBoss
+debug: 1
type: Book
-brand: JBoss
-debug:1
-show_remarks: 1
-cvs_branch: DOCS-RHEL-6
-cvs_root: :ext:cvs.devel.redhat.com:/cvs/dist
-cvs_pkg: JBoss_Enterprise_Portal_Platform-Reference_Guide-5.2-web-__LANG__
\ No newline at end of file
+