[gatein-commits] gatein SVN: r7508 - in epp/docs/branches/5.2/Reference_Guide-eXoJCR-1.14: en-US and 9 other directories.

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">&lt;container class="org.exoplatform.services.jcr.impl.storage.jdbc.optimisation.CQJDBCWorkspaceDataContainer"&gt; &lt;properties&gt; &lt;property name="source-name" value="jdbcjcr" /&gt; @@ -191,11 +191,11 @@ &lt;property name="check-sns-new-connection" value="false" /&gt; &lt;/properties&gt;</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">&lt;component&gt; - &lt;key&gt;org.jboss.cache.transaction.TransactionManagerLookup&lt;/key&gt; - &lt;type&gt;org.jboss.cache.GenericTransactionManagerLookup&lt;/type&gt; -&lt;/component&gt; - -&lt;component&gt; - &lt;key&gt;org.exoplatform.services.transaction.TransactionService&lt;/key&gt; - &lt;type&gt;org.exoplatform.services.transaction.jbosscache.JBossTransactionsService&lt;/type&gt; - &lt;init-params&gt; - &lt;value-param&gt; - &lt;name&gt;timeout&lt;/name&gt; - &lt;value&gt;300&lt;/value&gt; - &lt;/value-param&gt; - &lt;/init-params&gt; -&lt;/component&gt;</programlisting> - <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. &lt;cache&gt;, &lt;query-handler&gt; and &lt;lock-manager&gt;. - </para> - <itemizedlist> - <listitem> - <para> - &lt;cache&gt; configuration should look like this: - </para> - -<programlisting language="XML" role="XML">&lt;cache enabled="true" - class="org.exoplatform.services.jcr.impl.dataflow.persistent.jbosscache.JBossCacheWorkspaceStorageCache"&gt; - &lt;properties&gt; - &lt;property name="jbosscache-configuration" value="test-jbosscache-data.xml" /&gt; - &lt;property name="jgroups-configuration" value="udp-mux.xml" /&gt; - &lt;property name="jgroups-multiplexer-stack" value="true" /&gt; - &lt;property name="jbosscache-cluster-name" value="JCR-cluster-db1-ws" /&gt; - &lt;/properties&gt; -&lt;/cache&gt;</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.: &lt;repository_name&gt;-&lt;ws_name&gt;-&lt;component(cache\|lock\|index)&gt; - </para> - - </listitem> - - </itemizedlist> - - </listitem> - - </itemizedlist> - <itemizedlist> - <listitem> - <para> - &lt;query-handler&gt; configuration - </para> - <itemizedlist> - <listitem> - <para> - You must replace or add in &lt;query-handler&gt; block the "changesfilter-class" parameter equals with: - </para> - -<programlisting language="XML" role="XML">&lt;property name="changesfilter-class" value="org.exoplatform.services.jcr.impl.core.query.jbosscache.JBossCacheIndexChangesFilter"/&gt;</programlisting> - - </listitem> - <listitem> - <para> - add JBossCache-oriented configuration: - </para> - -<programlisting language="XML" role="XML">&lt;property name="jbosscache-configuration" value="test-jbosscache-indexer.xml" /&gt; -&lt;property name="jgroups-configuration" value="udp-mux.xml" /&gt; -&lt;property name="jgroups-multiplexer-stack" value="true" /&gt; -&lt;property name="jbosscache-cluster-name" value="JCR-cluster-indexer-db1-ws" /&gt; -&lt;property name="max-volatile-time" value="60" /&gt;</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> - &lt;lock-manager&gt; 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"> -&lt;lock-manager class="org.exoplatform.services.jcr.impl.core.lock.jbosscache.CacheableLockManagerImpl"&gt; - &lt;properties&gt; - &lt;property name="time-out" value="15m" /&gt; - &lt;property name="jbosscache-configuration" value="test-jbosscache-lock.xml" /&gt; - &lt;property name="jgroups-configuration" value="udp-mux.xml" /&gt; - &lt;property name="jgroups-multiplexer-stack" value="true" /&gt; - &lt;property name="jbosscache-cluster-name" value="JCR-cluster-locks-db1-ws" /&gt; - &lt;property name="jbosscache-cl-cache.jdbc.table.name" value="jcrlocks_db1_ws" /&gt; - &lt;property name="jbosscache-cl-cache.jdbc.table.create" value="true" /&gt; - &lt;property name="jbosscache-cl-cache.jdbc.table.drop" value="false" /&gt; - &lt;property name="jbosscache-cl-cache.jdbc.table.primarykey" value="jcrlocks_db1_ws_pk" /&gt; - &lt;property name="jbosscache-cl-cache.jdbc.fqn.column" value="fqn" /&gt; - &lt;property name="jbosscache-cl-cache.jdbc.node.column" value="node" /&gt; - &lt;property name="jbosscache-cl-cache.jdbc.parent.column" value="parent" /&gt; - &lt;property name="jbosscache-cl-cache.jdbc.datasource" value="jdbcjcr" /&gt; - &lt;/properties&gt; -&lt;/lock-manager&gt; - -</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">&lt;query-handler class="org.exoplatform.services.jcr.impl.core.query.lucene.SearchIndex"&gt; &lt;properties&gt; ... @@ -465,56 +249,56 @@ &lt;/properties&gt; &lt;/query-handler&gt;</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">&lt;query-handler class="org.exoplatform.services.jcr.impl.core.query.lucene.SearchIndex"&gt; &lt;properties&gt; ... @@ -525,134 +309,134 @@ &lt;/properties&gt; &lt;/query-handler&gt;</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:&amp;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:&amp;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">&lt;component&gt; &lt;type&gt;org.exoplatform.services.jcr.webdav.WebDavServiceImpl&lt;/type&gt; &lt;init-params&gt; @@ -664,79 +448,79 @@ &lt;component&gt; </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 "&lt;?xml version='1.0' encoding='UTF-8' ?&gt; &lt;D:searchrequest xmlns:D='DAV:'&gt; &lt;D:sql&gt;SELECT * FROM nt:base WHERE contains(*, 'text')&lt;/D:sql&gt; &lt;/D:searchrequest&gt;"</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">&lt;component&gt; &lt;key&gt;org.exoplatform.services.jcr.config.RepositoryServiceConfiguration&lt;/key&gt; &lt;type&gt;org.exoplatform.services.jcr.impl.config.RepositoryServiceConfigurationImpl&lt;/type&gt; @@ -18,31 +17,30 @@ &lt;value-param&gt; &lt;name&gt;conf-path&lt;/name&gt; &lt;description&gt;JCR configuration file&lt;/description&gt; - &lt;value&gt;/conf/standalone/exo-jcr-config.xml&lt;/value&gt; + &lt;value&gt;war:/conf/jcr/repository-configuration.xml&lt;/value&gt; &lt;/value-param&gt; &lt;/init-params&gt; &lt;/component&gt;</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">&lt;component&gt; &lt;key&gt;org.exoplatform.services.jcr.config.RepositoryServiceConfiguration&lt;/key&gt; &lt;type&gt;org.exoplatform.services.jcr.impl.config.RepositoryServiceConfigurationImpl&lt;/type&gt; @@ -50,7 +48,7 @@ &lt;value-param&gt; &lt;name&gt;conf-path&lt;/name&gt; &lt;description&gt;JCR configuration file&lt;/description&gt; - &lt;value&gt;/conf/standalone/exo-jcr-config.xml&lt;/value&gt; + &lt;value&gt;war:/conf/jcr/repository-configuration.xml&lt;/value&gt; &lt;/value-param&gt; &lt;properties-param&gt; &lt;name&gt;working-conf&lt;/name&gt; @@ -62,34 +60,34 @@ &lt;/init-params&gt; &lt;/component&gt; </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">&lt;component&gt; &lt;key&gt;org.exoplatform.services.naming.InitialContextInitializer&lt;/key&gt; &lt;type&gt;org.exoplatform.services.naming.InitialContextInitializer&lt;/type&gt; @@ -376,73 +357,73 @@ &lt;/init-params&gt; &lt;/component&gt; </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">&lt;workspaces&gt; &lt;workspace name="ws" auto-init-root-nodetype="nt:unstructured"&gt; &lt;container class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer"&gt; @@ -506,60 +487,60 @@ &lt;/workspace&gt; &lt;/workspaces&gt; </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">&lt;external-component-plugins&gt; &lt;target-component&gt;org.exoplatform.services.naming.InitialContextInitializer&lt;/target-component&gt; &lt;component-plugin&gt; @@ -594,13 +575,13 @@ &lt;/component-plugin&gt; &lt;/external-component-plugins&gt; </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">&lt;workspaces&gt; &lt;workspace name="ws" auto-init-root-nodetype="nt:unstructured"&gt; &lt;container class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer"&gt; @@ -659,39 +640,39 @@ &lt;/workspace&gt; &lt;/workspaces&gt; </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">&lt;workspace name="ws" auto-init-root-nodetype="nt:unstructured"&gt; &lt;container class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer"&gt; &lt;properties&gt; @@ -702,46 +683,46 @@ &lt;property name="password" value=""/&gt; ......</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">&lt;workspaces&gt; &lt;workspace name="ws" auto-init-root-nodetype="nt:unstructured"&gt; &lt;container class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer"&gt; @@ -749,90 +730,90 @@ &lt;/workspace&gt; &lt;/worksapces&gt; </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">&lt;workspaces&gt; &lt;workspace name="ws" auto-init-root-nodetype="nt:unstructured"&gt; &lt;container class="org.exoplatform.services.jcr.impl.storage.jdbc.optimisation.CQJDBCWorkspaceDataContainer"&gt; ... &lt;/workspace&gt; &lt;/worksapces&gt;</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">&lt;workspace name="ws" auto-init-root-nodetype="nt:unstructured"&gt; &lt;container class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer"&gt; &lt;properties&gt; &lt;property name="dialect" value="oracle"/&gt; &lt;property name="force.query.hints" value="true" /&gt; ......</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">&lt;property name="jbosscache-configuration" value="conf/standalone/test-jbosscache-lock-db1-ws1.xml" /&gt;</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-&lt;parameter name&gt;} 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">&lt;property name="jbosscache-configuration" value="conf/<remark>standalone</remark>/test-jbosscache-lock-db1-ws1.xml" /&gt;</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-&lt;parameter name&gt;} 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">... &lt;clustering mode="replication" clusterName="${jbosscache-cluster-name}"&gt; &lt;stateRetrieval timeout="20000" fetchInMemoryState="false" /&gt; ...</programlisting> - <para> - and JCR configuration file: - </para> - + <para> + and JCR configuration file: + </para> + <programlisting language="XML" role="XML">... &lt;property name="jbosscache-configuration" value="jar:/conf/portal/jbosscache-lock.xml" /&gt; &lt;property name="jbosscache-cluster-name" value="JCR-cluster-locks-db1-ws" /&gt; ...</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">&lt;property name="jgroups-configuration" value="your/path/to/modified-udp.xml" /&gt;</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">&lt;property name="jgroups-configuration" value="jar:/conf/portal/udp-mux.xml" /&gt; &lt;property name="jgroups-multiplexer-stack" value="true" /&gt;</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">&lt;property name="jbosscache-shareable" value="true" /&gt;</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-&lt;parameter name&gt;} 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-&lt;parameter name&gt;} 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-&lt;parameter name&gt;} 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-&lt;parameter name&gt;} 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">&lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.1"&gt; @@ -96,42 +96,42 @@ &lt;/default&gt; &lt;/eviction&gt; &lt;/jbosscache&gt;</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">&lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.1"&gt; @@ -163,100 +163,100 @@ &lt;/loader&gt; &lt;/loaders&gt; &lt;/jbosscache&gt;</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">&lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.1"&gt; &lt;locking useLockStriping="false" concurrencyLevel="50000" lockParentForChildInsertRemove="false" @@ -274,36 +274,36 @@ &lt;/default&gt; &lt;/eviction&gt; &lt;/jbosscache&gt;</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>&lt;connection-factories&gt; &lt;tx-connection-factory&gt; &lt;jndi-name&gt;jcr/repository&lt;/jndi-name&gt; @@ -118,7 +118,7 @@ &lt;/tx-connection-factory&gt; &lt;/connection-factories&gt;</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 &gt;2s - </entry> - <entry> - Responses &gt;4s - </entry> + </mediaobject> + <table> + <title></title> + <tgroup cols="4"> + <thead> + <row> + <entry> + Nodes count + </entry> + <entry> + tps + </entry> + <entry> + Responses &gt;2s + </entry> + <entry> + Responses &gt;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 &gt;2s - </entry> - <entry> - Responses &gt;4s - </entry> + </mediaobject> + <table> + <title></title> + <tgroup cols="4"> + <thead> + <row> + <entry> + Nodes count + </entry> + <entry> + tps + </entry> + <entry> + Responses &gt;2s + </entry> + <entry> + Responses &gt;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"> &lt;clustering mode="replication" clusterName="${jbosscache-cluster-name}"&gt; ... &lt;sync replTimeout="60000" /&gt; &lt;/clustering&gt; </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">&lt;workspace name="ws"&gt; &lt;query-handler class="org.exoplatform.services.jcr.impl.core.query.lucene.SearchIndex"&gt; &lt;properties&gt; @@ -78,150 +66,130 @@ &lt;/query-handler&gt; &lt;/workspace&gt; </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">&lt;workspace name="ws"&gt; &lt;query-handler class="org.exoplatform.services.jcr.impl.core.query.lucene.SearchIndex"&gt; &lt;properties&gt; - &lt;property name="index-dir" value="shareddir/index/db1/ws" /&gt; - &lt;property name="max-volatile-time" value="60" /&gt; - &lt;property name="rdbms-reindexing" value="true" /&gt; - &lt;property name="reindexing-page-size" value="1000" /&gt; - &lt;property name="index-recovery-mode" value="from-coordinator" /&gt; - &lt;/properties&gt; - &lt;/query-handler&gt; -&lt;/workspace&gt;</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">&lt;workspace name="ws"&gt; - &lt;query-handler class="org.exoplatform.services.jcr.impl.core.query.lucene.SearchIndex"&gt; - &lt;properties&gt; &lt;property name="index-dir" value="/mnt/nfs_drive/index/db1/ws" /&gt; &lt;property name="changesfilter-class" value="org.exoplatform.services.jcr.impl.core.query.jbosscache.JBossCacheIndexChangesFilter" /&gt; @@ -236,10 +204,10 @@ &lt;/properties&gt; &lt;/query-handler&gt; &lt;/workspace&gt;</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">&lt;workspace name="ws"&gt; &lt;query-handler class="org.exoplatform.services.jcr.impl.core.query.lucene.SearchIndex"&gt; &lt;properties&gt; @@ -259,24 +227,24 @@ &lt;/workspace&gt; </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">&lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.1"&gt; &lt;locking useLockStriping="false" concurrencyLevel="50000" lockParentForChildInsertRemove="false" lockAcquisitionTimeout="20000" /&gt; &lt;!-- Configure the TransactionManager --&gt; - &lt;transaction transactionManagerLookupClass="org.jboss.cache.transaction.JBossStandaloneJTAManagerLookup" /&gt; + &lt;transaction transactionManagerLookupClass="org.jboss.cache.transaction.JBoss<remark>Standalone</remark>JTAManagerLookup" /&gt; &lt;clustering mode="replication" clusterName="${jbosscache-cluster-name}"&gt; &lt;stateRetrieval timeout="20000" fetchInMemoryState="false" /&gt; @@ -292,14 +260,14 @@ &lt;/eviction&gt; &lt;/jbosscache&gt;</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">&lt;component&gt; &lt;key&gt;org.exoplatform.services.jcr.ext.backup.BackupManager&lt;/key&gt; &lt;type&gt;org.exoplatform.services.jcr.ext.backup.impl.BackupManagerImpl&lt;/type&gt; @@ -125,7 +119,7 @@ &lt;init-params&gt; &lt;value-param&gt; &lt;name&gt;jgroups-configuration&lt;/name&gt; - &lt;value&gt;jar:/conf/standalone/udp-mux.xml&lt;/value&gt; + &lt;value&gt;jar:/conf/cluster/udp-mux.xml&lt;/value&gt; &lt;/value-param&gt; &lt;value-param&gt; &lt;name&gt;jgroups-cluster-name&lt;/name&gt; @@ -150,21 +144,21 @@ &lt;/value-param&gt; &lt;/init-params&gt; &lt;/component&gt;</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"> &lt;component&gt; &lt;key&gt;org.jboss.cache.transaction.TransactionManagerLookup&lt;/key&gt; - &lt;type&gt;org.jboss.cache.transaction.JBossStandaloneJTAManagerLookup&lt;/type&gt; + &lt;type&gt;org.jboss.cache.transaction.GenericTransactionManagerLookup&lt;/type&gt; &lt;/component&gt;</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">&lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" @@ -543,89 +543,89 @@ &lt;/component-plugin&gt; &lt;/external-component-plugins&gt; &lt;/configuration&gt;</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">&lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" @@ -653,150 +653,150 @@ &lt;/init-params&gt; &lt;/component&gt; &lt;/configuration&gt;</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">&lt;?xml version="1.0" encoding="ISO-8859-1" ?&gt; &lt;!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"&gt; @@ -856,17 +856,17 @@ &lt;/servlet-mapping&gt; &lt;/web-app&gt;</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">&lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" @@ -936,130 +936,130 @@ &lt;/external-component-plugins&gt; &lt;/configuration&gt;</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">&lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" @@ -1126,58 +1126,58 @@ &lt;/component-plugin&gt; &lt;/external-component-plugins&gt; &lt;/configuration&gt;</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">&lt;?xml version="1.0" encoding="ISO-8859-1"?&gt; &lt;configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" @@ -1189,14 +1189,14 @@ &lt;import&gt;war:/conf/sample-ext/web/web-inf-extension-configuration.xml&lt;/import&gt; &lt;/configuration&gt;</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">&lt;?xml version="1.0" encoding="ISO-8859-1"?&gt; &lt;configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" @@ -1227,38 +1227,38 @@ &lt;/component&gt; &lt;/configuration&gt;</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">&lt;?xml version="1.0" encoding="ISO-8859-1"?&gt; &lt;configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" @@ -1284,10 +1284,10 @@ &lt;/component-plugin&gt; &lt;/external-component-plugins&gt; &lt;/configuration&gt;</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">&lt;repository-service default-repository="repository"&gt; &lt;repositories&gt; &lt;repository name="repository" system-workspace="system" default-workspace="portal-system"&gt; @@ -1347,25 +1347,25 @@ &lt;/repository&gt; &lt;/repositories&gt; &lt;/repository-service&gt;</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">&lt;?xml version="1.0" encoding="ISO-8859-1"?&gt; &lt;configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" @@ -1403,34 +1403,34 @@ &lt;/external-component-plugins&gt; &lt;/configuration&gt;</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">&lt;?xml version="1.0" encoding="ISO-8859-1"?&gt; &lt;configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" @@ -1554,17 +1554,17 @@ &lt;/external-component-plugins&gt; &lt;/configuration&gt;</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">&lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" @@ -1601,12 +1601,12 @@ &lt;/component-plugin&gt; &lt;/external-component-plugins&gt; &lt;/configuration&gt;</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&lt;PortalContainer, HttpSessionEvent&gt;_If you want to listen to \_org.exoplatform.web.GenericHttpListener.sessionDestroyed_, you will need to create a Listener that extends _Listener&lt;PortalContainer, HttpSessionEvent&gt;_If you want to listen to \_org.exoplatform.web.GenericHttpListener.contextInitialized_, you will need to create a Listener that extends _Listener&lt;PortalContainer, ServletContextEvent&gt;_If you want to listen to \_org.exoplatform.web.GenericHttpListener.contextDestroyed_, you will need to create a Listener that extends <emphasis>Listener&lt;PortalContainer, ServletContextEvent&gt;</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&lt;PortalContainer, HttpSessionEvent&gt;_If you want to listen to \_org.exoplatform.web.GenericHttpListener.sessionDestroyed_, you will need to create a Listener that extends _Listener&lt;PortalContainer, HttpSessionEvent&gt;_If you want to listen to \_org.exoplatform.web.GenericHttpListener.contextInitialized_, you will need to create a Listener that extends _Listener&lt;PortalContainer, ServletContextEvent&gt;_If you want to listen to \_org.exoplatform.web.GenericHttpListener.contextDestroyed_, you will need to create a Listener that extends <emphasis>Listener&lt;PortalContainer, ServletContextEvent&gt;</emphasis> + </para> + <para> + <emphasis role="underline">See an example of configuration below:</emphasis> + </para> + <programlisting language="XML" role="XML">&lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" @@ -1720,12 +1720,12 @@ &lt;/component-plugin&gt; &lt;/external-component-plugins&gt; &lt;/configuration&gt;</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"> &lt;application-policy name="exo-domain-sample-portal"&gt; &lt;authentication&gt; &lt;login-module code="org.exoplatform.web.security.PortalLoginModule" flag="required"&gt; @@ -2010,76 +2010,76 @@ &lt;/login-module&gt; &lt;/authentication&gt; &lt;/application-policy&gt;</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">&lt;Context path='/sample-portal' docBase='sample-portal' debug='0' reloadable='true' crossContext='true' privileged='true'&gt; &lt;Logger className='org.apache.catalina.logger.SystemOutLogger' prefix='localhost_portal_log.' suffix='.txt' timestamp='true'/&gt; @@ -2117,19 +2117,19 @@ debug='0' cache='false'/&gt; &lt;Valve className='org.apache.catalina.authenticator.FormAuthenticator' characterEncoding='UTF-8'/&gt;&lt;/Context&gt;</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">&lt;Context path="/rest-sample-portal" docBase="rest-sample-portal" reloadable="true" crossContext="false"&gt; &lt;Logger className='org.apache.catalina.logger.SystemOutLogger' @@ -2142,100 +2142,100 @@ debug='0' cache='false'/&gt; &lt;/Context&gt;</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">&lt;configuration&gt; - &lt;component&gt; - &lt;key&gt;org.exoplatform.services.cache.ExoCacheFactory&lt;/key&gt; - &lt;type&gt;org.exoplatform.services.cache.impl.infinispan.ExoCacheFactoryImpl&lt;/type&gt; - &lt;init-params&gt; - &lt;value-param&gt; - &lt;name&gt;cache.config.template&lt;/name&gt; - &lt;value&gt;jar:/conf/portal/cache-configuration-template.xml&lt;/value&gt; - &lt;/value-param&gt; - &lt;/init-params&gt; - &lt;/component&gt; -&lt;/configuration&gt;</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">&lt;configuration&gt; - ... - &lt;external-component-plugins&gt; - &lt;target-component&gt;org.exoplatform.services.cache.ExoCacheFactory&lt;/target-component&gt; - &lt;component-plugin&gt; - &lt;name&gt;addConfig&lt;/name&gt; - &lt;set-method&gt;addConfig&lt;/set-method&gt; - &lt;type&gt;org.exoplatform.services.cache.impl.infinispan.ExoCacheFactoryConfigPlugin&lt;/type&gt; - &lt;description&gt;add Custom Configurations&lt;/description&gt; - &lt;init-params&gt; - &lt;value-param&gt; - &lt;name&gt;myCustomCache&lt;/name&gt; - &lt;value&gt;jar:/conf/portal/custom-cache-configuration.xml&lt;/value&gt; - &lt;/value-param&gt; - &lt;/init-params&gt; - &lt;/component-plugin&gt; - &lt;/external-component-plugins&gt; - ... -&lt;/configuration&gt;</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&lt;Serializable, Object&gt; create(ExoCacheConfig config, Configuration cacheConfig, Callable&lt;Cache&lt;Serializable, Object&gt;&gt; cacheGetter) throws ExoCacheInitException; - - /** - * Returns the type of {@link org.exoplatform.services.cache.ExoCacheConfig} expected by the creator - * @return the expected type - */ - public Class&lt;? extends ExoCacheConfig&gt; 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&lt;String&gt; 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"> &lt;external-component-plugins&gt; - &lt;target-component&gt;org.exoplatform.services.cache.ExoCacheFactory&lt;/target-component&gt; - &lt;component-plugin&gt; - &lt;name&gt;addCreator&lt;/name&gt; - &lt;set-method&gt;addCreator&lt;/set-method&gt; - &lt;type&gt;org.exoplatform.services.cache.impl.infinispan.ExoCacheCreatorPlugin&lt;/type&gt; - &lt;description&gt;add Exo Cache Creator&lt;/description&gt; - &lt;init-params&gt; - &lt;object-param&gt; - &lt;name&gt;Test&lt;/name&gt; - &lt;description&gt;The cache creator for testing purpose&lt;/description&gt; - &lt;object type="org.exoplatform.services.cache.impl.infinispan.TestExoCacheCreator"&gt;&lt;/object&gt; - &lt;/object-param&gt; - &lt;/init-params&gt; - &lt;/component-plugin&gt; - &lt;/external-component-plugins&gt;</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">.. -&lt;object-param&gt; - &lt;name&gt;GENERIC&lt;/name&gt; - &lt;description&gt;The generic cache creator&lt;/description&gt; - &lt;object type="org.exoplatform.services.cache.impl.infinispan.generic.GenericExoCacheCreator"&gt; - &lt;field name="implementations"&gt; - &lt;collection type="java.util.HashSet"&gt; - &lt;value&gt; - &lt;string&gt;NONE&lt;/string&gt; - &lt;/value&gt; - &lt;value&gt; - &lt;string&gt;FIFO&lt;/string&gt; - &lt;/value&gt; - &lt;value&gt; - &lt;string&gt;LRU&lt;/string&gt; - &lt;/value&gt; - &lt;value&gt; - &lt;string&gt;UNORDERED&lt;/string&gt; - &lt;/value&gt; - &lt;value&gt; - &lt;string&gt;LIRS&lt;/string&gt; - &lt;/value&gt; - &lt;/collection&gt; - &lt;/field&gt; - &lt;field name="defaultStrategy"&gt;&lt;string&gt;${my-value}&lt;/string&gt;&lt;/field&gt; - &lt;field name="defaultMaxIdle"&gt;&lt;long&gt;${my-value}&lt;/long&gt;&lt;/field&gt; - &lt;field name="defaultWakeUpInterval"&gt;&lt;long&gt;${my-value}&lt;/long&gt;&lt;/field&gt; - &lt;/object&gt; -&lt;/object-param&gt; -...</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">... - &lt;object-param&gt; - &lt;name&gt;myCache&lt;/name&gt; - &lt;description&gt;My cache configuration&lt;/description&gt; - &lt;object type="org.exoplatform.services.cache.impl.infinispan.generic.GenericExoCacheConfig"&gt; - &lt;field name="name"&gt;&lt;string&gt;myCacheName&lt;/string&gt;&lt;/field&gt; - &lt;field name="strategy"&gt;&lt;int&gt;${my-value}&lt;/int&gt;&lt;/field&gt; - &lt;field name="maxEntries"&gt;&lt;long&gt;${my-value}&lt;/long&gt;&lt;/field&gt; - &lt;field name="lifespan"&gt;&lt;long&gt;${my-value}&lt;/long&gt;&lt;/field&gt; - &lt;field name="maxIdle"&gt;&lt;long&gt;${my-value}&lt;/long&gt;&lt;/field&gt; - &lt;field name="wakeUpInterval"&gt;&lt;long&gt;${my-value}&lt;/long&gt;&lt;/field&gt; - &lt;/object&gt; - &lt;/object-param&gt; -...</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">... - &lt;object-param&gt; - &lt;name&gt;myCache&lt;/name&gt; - &lt;description&gt;My cache configuration&lt;/description&gt; - &lt;field name="name"&gt;&lt;string&gt;lru-with-old-config&lt;/string&gt;&lt;/field&gt; - &lt;field name="maxSize"&gt;&lt;int&gt;${my-value}&lt;/int&gt;&lt;/field&gt; - &lt;field name="liveTime"&gt;&lt;long&gt;${my-value}&lt;/long&gt;&lt;/field&gt; - &lt;field name="implementation"&gt;&lt;string&gt;${my-value}&lt;/string&gt;&lt;/field&gt; - &lt;/object&gt; - &lt;/object-param&gt; -...</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"> &lt;component&gt; &lt;key&gt;org.exoplatform.services.cache.CacheService&lt;/key&gt; &lt;type&gt;org.exoplatform.services.cache.impl.CacheServiceImpl&lt;/type&gt; ...</programlisting> - <para> - Here you will note that a service is specified between the <parameter>&lt;component&gt;</parameter> tags. Each service has got a key, which defines the kind of service. As you imagine the content of the <parameter>&lt;key&gt;</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>&lt;type&gt;</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>&lt;key&gt;</parameter> and <parameter>&lt;type&gt;</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>&lt;component&gt;</parameter> tags. Each service has got a key, which defines the kind of service. As you imagine the content of the <parameter>&lt;key&gt;</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>&lt;type&gt;</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>&lt;key&gt;</parameter> and <parameter>&lt;type&gt;</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>&lt;key&gt;</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>&lt;component&gt;</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>&lt;key&gt;</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>&lt;component&gt;</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>&lt;import&gt;mySubConfDir/myConfig.xml&lt;/import&gt;</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>&lt;import&gt;mySubConfDir/myConfig.xml&lt;/import&gt;</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">&lt;key&gt;org.exoplatform.services.database.jdbc.DBSchemaCreator&lt;/key&gt; &lt;type&gt;org.exoplatform.services.database.jdbc.DBSchemaCreator&lt;/type&gt;</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">&lt;component&gt; ... &lt;init-params&gt; @@ -590,19 +477,19 @@ &lt;/init-params&gt; &lt;/component&gt;</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">&lt;?xml version="1.0" encoding="UTF8"?&gt; &lt;configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" @@ -94,27 +94,27 @@ &lt;type&gt;com.laverdad.services.ArticleStatsServiceImpl&lt;/type&gt; &lt;/component&gt; &lt;/configuration&gt;</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"> &lt;component&gt; &lt;key&gt;com.laverdad.services.ArticleStatsService&lt;/key&gt; &lt;type&gt;com.laverdad.services.ArticleStatsServiceImpl&lt;/type&gt; @@ -132,16 +132,16 @@ &lt;/properties-param&gt; &lt;/init-params&gt; &lt;/component&gt;</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"> &lt;component&gt; &lt;key&gt;org.exoplatform.portal.config.UserACL&lt;/key&gt; &lt;type&gt;org.exoplatform.portal.config.UserACL&lt;/type&gt; @@ -280,10 +274,10 @@ &lt;/value-param&gt; ... &lt;/component&gt;</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"> &lt;component&gt; &lt;key&gt;org.exoplatform.services.database.HibernateService&lt;/key&gt; &lt;type&gt;org.exoplatform.services.database.impl.HibernateServiceImpl&lt;/type&gt; @@ -319,10 +313,10 @@ &lt;/properties-param&gt; &lt;/init-params&gt; &lt;/component&gt;</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">&lt;component&gt; &lt;key&gt;org.exoplatform.services.ldap.LDAPService&lt;/key&gt; &lt;type&gt;org.exoplatform.services.ldap.impl.LDAPServiceImpl&lt;/type&gt; @@ -359,13 +353,13 @@ &lt;/object-param&gt; &lt;/init-params&gt; &lt;/component&gt;</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"> &lt;component-plugin&gt; &lt;name&gt;new.user.event.listener&lt;/name&gt; &lt;set-method&gt;addListenerPlugin&lt;/set-method&gt; @@ -454,10 +448,10 @@ &lt;/object-param&gt; &lt;/init-params&gt; &lt;/component-plugin&gt;</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"> &lt;external-component-plugins&gt; &lt;target-component&gt;org.exoplatform.services.cms.categories.CategoriesService&lt;/target-component&gt; &lt;component-plugin&gt; @@ -542,81 +536,65 @@ &lt;/init-params&gt; &lt;/component-plugin&gt; &lt;external-component-plugins&gt;</programlisting> - <para> - The <emphasis role="bold">&lt;target-component&gt;</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">&lt;set-method&gt;</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">&lt;target-component&gt;</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">&lt;set-method&gt;</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">&lt;init-params&gt;</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">&lt;init-params&gt;</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">&lt;import&gt;war:/conf/common/common-configuration.xml&lt;/import&gt; &lt;import&gt;war:/conf/common/logs-configuration.xml&lt;/import&gt; &lt;import&gt;war:/conf/database/database-configuration.xml&lt;/import&gt; @@ -624,17 +602,17 @@ &lt;import&gt;war:/conf/common/portlet-container-configuration.xml&lt;/import&gt; ...</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"> &lt;component&gt; &lt;key&gt;org.exoplatform.services.database.HibernateService&lt;/key&gt; &lt;jmx-name&gt;database:type=HibernateService&lt;/jmx-name&gt; @@ -653,11 +631,11 @@ &lt;/properties-param&gt; &lt;/init-params&gt; &lt;/component&gt;</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> &lt;component&gt; - &lt;key&gt;org.exoplatform.services.transaction.TransactionService&lt;/key&gt; - &lt;type&gt;org.exoplatform.services.transaction.impl.jotm.TransactionServiceJotmImpl&lt;/type&gt; - &lt;!-- Uncomment the lines below if you want to set default transaction timeout that is expressed in seconds --&gt; - &lt;!--init-params&gt; - &lt;value-param&gt; - &lt;name&gt;timeout&lt;/name&gt; - &lt;value&gt;60&lt;/value&gt; - &lt;/value-param&gt; - &lt;/init-params--&gt; - &lt;/component&gt;</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> &lt;!-- Configuration of the TransactionManagerLookup --&gt; + </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[ &lt;!-- Configuration of the TransactionManagerLookup --&gt; &lt;component&gt; &lt;key&gt;org.jboss.cache.transaction.TransactionManagerLookup&lt;/key&gt; &lt;type&gt;org.jboss.cache.transaction.GenericTransactionManagerLookup&lt;/type&gt; @@ -124,94 +105,17 @@ &lt;value&gt;60&lt;/value&gt; &lt;/value-param&gt; &lt;/init-params--&gt; - &lt;/component&gt;</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> &lt;!-- Configuration of the TransactionManagerLookup --&gt; - &lt;component&gt; - &lt;key&gt;org.jboss.cache.transaction.TransactionManagerLookup&lt;/key&gt; - &lt;type&gt;org.jboss.cache.transaction.JBossStandaloneJTAManagerLookup&lt;/type&gt; &lt;/component&gt; - &lt;!-- Configuration of the TransactionService --&gt; - &lt;component&gt; - &lt;key&gt;org.exoplatform.services.transaction.TransactionService&lt;/key&gt; - &lt;type&gt;org.exoplatform.services.transaction.jbosscache.JBossTransactionsService&lt;/type&gt; - &lt;!-- Uncomment the lines below if you want to set default transaction timeout that is expressed in seconds --&gt; - &lt;!--init-params&gt; - &lt;value-param&gt; - &lt;name&gt;timeout&lt;/name&gt; - &lt;value&gt;60&lt;/value&gt; - &lt;/value-param&gt; - &lt;/init-params--&gt; - &lt;/component&gt;</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> &lt;!-- Configuration of the TransactionManagerLookup --&gt; - &lt;component&gt; - &lt;key&gt;org.infinispan.transaction.lookup.TransactionManagerLookup&lt;/key&gt; - &lt;type&gt;org.infinispan.transaction.lookup.GenericTransactionManagerLookup&lt;/type&gt; - &lt;/component&gt; - &lt;!-- Configuration of the TransactionService --&gt; - &lt;component&gt; - &lt;key&gt;org.exoplatform.services.transaction.TransactionService&lt;/key&gt; - &lt;type&gt;org.exoplatform.services.transaction.infinispan.GenericTransactionService&lt;/type&gt; - &lt;!-- Uncomment the lines below if you want to set default transaction timeout that is expressed in seconds --&gt; - &lt;!--init-params&gt; - &lt;value-param&gt; - &lt;name&gt;timeout&lt;/name&gt; - &lt;value&gt;60&lt;/value&gt; - &lt;/value-param&gt; - &lt;/init-params--&gt; - &lt;/component&gt;</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> &lt;!-- Configuration of the TransactionManagerLookup --&gt; - &lt;component&gt; - &lt;key&gt;org.infinispan.transaction.lookup.TransactionManagerLookup&lt;/key&gt; - &lt;type&gt;org.infinispan.transaction.lookup.JBossStandaloneJTAManagerLookup&lt;/type&gt; - &lt;/component&gt; - &lt;!-- Configuration of the TransactionService --&gt; - &lt;component&gt; - &lt;key&gt;org.exoplatform.services.transaction.TransactionService&lt;/key&gt; - &lt;type&gt;org.exoplatform.services.transaction.infinispan.JBossTransactionsService&lt;/type&gt; - &lt;!-- Uncomment the lines below if you want to set default transaction timeout that is expressed in seconds --&gt; - &lt;!--init-params&gt; - &lt;value-param&gt; - &lt;name&gt;timeout&lt;/name&gt; - &lt;value&gt;60&lt;/value&gt; - &lt;/value-param&gt; - &lt;/init-params--&gt; - &lt;/component&gt;</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> &lt;component&gt; &lt;key&gt;org.exoplatform.services.transaction.TransactionService&lt;/key&gt; &lt;type&gt;org.exoplatform.services.transaction.impl.jboss.JBossTransactionService&lt;/type&gt; @@ -224,31 +128,11 @@ &lt;/init-params--&gt; &lt;/component&gt;</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> &lt;component&gt; - &lt;key&gt;org.exoplatform.services.transaction.TransactionService&lt;/key&gt; - &lt;type&gt;org.exoplatform.services.transaction.impl.atomikos.TransactionsEssentialsTransactionService&lt;/type&gt; - &lt;!-- Uncomment the lines below if you want to set default transaction timeout that is expressed in seconds --&gt; - &lt;!--init-params&gt; - &lt;value-param&gt; - &lt;name&gt;timeout&lt;/name&gt; - &lt;value&gt;60&lt;/value&gt; - &lt;/value-param&gt; - &lt;/init-params--&gt; - &lt;/component&gt;</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 +