cayenne-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aadamc...@apache.org
Subject svn commit: r1425991 [1/4] - in /cayenne/main/trunk/docs/docbook: cayenne-guide/src/docbkx/ getting-started-rop/src/docbkx/ getting-started/src/docbkx/ stylesheets/
Date Wed, 26 Dec 2012 18:55:53 GMT
Author: aadamchik
Date: Wed Dec 26 18:55:53 2012
New Revision: 1425991

URL: http://svn.apache.org/viewvc?rev=1425991&view=rev
Log:
CAY-1733 update docs

patch by Ilia Drabenia

(massive XML reformats are about changing tabs to spaces which is needed for proper docs display)

Modified:
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/appendix-a.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/appendix-b.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/appendix-c.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/cayenne-mapping-structure.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/cayennemodeler-application.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/current-limitations.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/customizing-cayenne-runtime.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/expressions.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/implementing-rop-server.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/including-cayenne-in-project.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/index.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/introduction-to-rop.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/lifecycle-events.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/orderings.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/part2.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/part3.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/performance-tuning.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/persistent-objects-objectcontext.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/queries.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/rop-deployment.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/rop-setup.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/setup.xml
    cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/starting-cayenne.xml
    cayenne/main/trunk/docs/docbook/getting-started-rop/src/docbkx/authentification.xml
    cayenne/main/trunk/docs/docbook/getting-started-rop/src/docbkx/web-service.xml
    cayenne/main/trunk/docs/docbook/getting-started/src/docbkx/java-classes.xml
    cayenne/main/trunk/docs/docbook/getting-started/src/docbkx/object-context.xml
    cayenne/main/trunk/docs/docbook/getting-started/src/docbkx/persistent-objects.xml
    cayenne/main/trunk/docs/docbook/getting-started/src/docbkx/webapp.xml
    cayenne/main/trunk/docs/docbook/stylesheets/common-customizations.xsl
    cayenne/main/trunk/docs/docbook/stylesheets/html.xsl
    cayenne/main/trunk/docs/docbook/stylesheets/pdf.xsl

Modified: cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/appendix-a.xml
URL: http://svn.apache.org/viewvc/cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/appendix-a.xml?rev=1425991&r1=1425990&r2=1425991&view=diff
==============================================================================
--- cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/appendix-a.xml (original)
+++ cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/appendix-a.xml Wed Dec 26 18:55:53 2012
@@ -1,168 +1,169 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <appendix xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink"
-	version="5.0" xml:id="server-configuration-properties">
-	<title>Configuration Properties</title>
-	<para>Note that the property names below are defined as constants in
-			<code>org.apache.cayenne.configuration.Constants</code> interface. </para>
-	<para>
-		<table frame="void">
-			<caption>Configuration Properties Recognized by ServerRuntime and/or ClientRuntime</caption>
-			<col width="77%"/>
-			<col width="10%"/>
-			<col width="13%"/>
-			<thead>
-				<tr>
-					<th>Property</th>
-					<th>Possible Values</th>
-					<th>Default Value</th>
-				</tr>
-			</thead>
-			<tbody>
-				<tr>
-					<td><code>cayenne.jdbc.driver[.domain_name.node_name]</code> - defines a JDBC driver class to
-						use when creating a DataSource. If domain name and optionally - node name
-						are specified, the setting overrides DataSource info just for this
-						domain/node. Otherwise the override is applied to all domains/nodes in the
-						system.</td>
-					<td/>
-					<td>none, project DataNode configuration is used</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.jdbc.url[.domain_name.node_name] </code>- defines a DB URL to use when
-						creating a DataSource. If domain name and optionally - node name are
-						specified, the setting overrides DataSource info just for this domain/node.
-						Otherwise the override is applied to all domains/nodes in the system.</td>
-					<td/>
-					<td>none, project DataNode configuration is used</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.jdbc.username[.domain_name.node_name] </code>- defines a DB user name to use
-						when creating a DataSource. If domain name and optionally - node name are
-						specified, the setting overrides DataSource info just for this domain/node.
-						Otherwise the override is applied to all domains/nodes in the system.</td>
-					<td/>
-					<td>none, project DataNode configuration is used</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.jdbc.password[.domain_name.node_name]</code> - defines a DB password to use
-						when creating a DataSource. If domain name and optionally - node name are
-						specified, the setting overrides DataSource info just for this domain/node.
-						Otherwise the override is applied to all domains/nodes in the system</td>
-					<td/>
-					<td>none, project DataNode configuration is used</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.jdbc.min_connections[.domain_name.node_name]</code> - defines the DB
-						connection pool minimal size. If domain name and optionally - node name are
-						specified, the setting overrides DataSource info just for this domain/node.
-						Otherwise the override is applied to all domains/nodes in the system</td>
-					<td/>
-					<td>none, project DataNode configuration is used</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.jdbc.max_connections[.domain_name.node_name]</code> - defines the DB
-						connection pool maximum size. If domain name and optionally - node name are
-						specified, the setting overrides DataSource info just for this domain/node.
-						Otherwise the override is applied to all domains/nodes in the system</td>
-					<td/>
-					<td>none, project DataNode configuration is used</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.querycache.size</code> - An integer defining the maximum number of entries in
-						the query cache. Note that not all QueryCache providers may respect this
-						property. MapQueryCache uses it, but the rest would use alternative
-						configuration methods.</td>
-					<td>any positive int value</td>
-					<td>2000</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.server.contexts_sync_strategy</code> - defines whether peer ObjectContexts
-						should receive snapshot events after commits from other contexts. If true
-						(default), the contexts would automatically synchronize their state with
-						peers.</td>
-					<td>true, false</td>
-					<td>true</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.server.object_retain_strategy</code> - defines fetched objects retain
-						strategy for ObjectContexts. When weak or soft strategy is used, objects
-						retained by ObjectContext that have no local changes can potetially get
-						garbage collected when JVM feels like doing it.</td>
-					<td>weak, soft, hard</td>
-					<td>weak</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.server.max_id_qualifier_size</code> - defines a maximum number of ID
-						qualifiers in the WHERE  clause of queries that are generated for paginated
-						queries and for DISJOINT_BY_ID prefetch processing. This is needed to avoid
-						hitting WHERE clause size limitations and memory usage efficiency.</td>
-					<td>any positive int</td>
-					<td>10000</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.rop.service_url</code> - defines the URL of the ROP server</td>
-					<td/>
-					<td/>
-				</tr>
-				<tr>
-					<td><code>cayenne.rop.service_username</code> - defines the user name for an ROP client to
-						login to an ROP server.</td>
-					<td/>
-				</tr>
-				<tr>
-					<td><code>cayenne.rop.service_password</code> - defines the password for an ROP client to login
-						to an ROP server.</td>
-					<td/>
-					<td/>
-				</tr>
-				<tr>
-					<td><code>cayenne.rop.shared_session_name</code>- defines the name of the shared session that
-						an ROP client wants to join on an ROP server. If omitted, a dedicated
-						session is created.</td>
-					<td/>
-					<td/>
-				</tr>
-				<tr>
-					<td><code>cayenne.rop.service.timeout</code> - a value in milliseconds for the
-						ROP client-server connection read operation timeout</td>
-					<td>any positive long value</td>
-					<td/>
-				</tr>
-				<tr>
-					<td><code>cayenne.rop.channel_events</code> - defines whether client-side DataChannel should
-						dispatch events to child ObjectContexts. If set to true, ObjectContexts will
-						receive commit events and merge changes committed by peer contexts that
-						passed through the common client DataChannel.</td>
-					<td>true, false</td>
-					<td>false</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.rop.context_change_events</code>- defines whether object property changes in
-						the client context result in firing events. Client UI components can listen
-						to these events and update the UI. Disabled by default.</td>
-					<td>true, false</td>
-					<td>false</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.rop.context_lifecycle_events</code> - defines whether object commit and
-						rollback operations in the client context result in firing events. Client UI
-						components can listen to these events and update the UI. Disabled by
-						default.</td>
-					<td>true,false</td>
-					<td>false</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.server.rop_event_bridge_factory</code> - defines the name of
-						the org.apache.cayenne.event.EventBridgeFactory that is passed from the ROP
-						server to the client. I.e. server DI would provide a name of the factory,
-						passing this name to the client via the wire. The client would instantiate
-						it to receive events from the server. Note that this property is stored in
-						"cayenne.server.rop_event_bridge_properties" map, not in the main
-						"cayenne.properties".</td>
-					<td/>
-					<td/>
-				</tr>
-			</tbody>
-		</table>
-	</para>
+    version="5.0" xml:id="server-configuration-properties">
+    <title>Configuration Properties</title>
+    <para>Note that the property names below are defined as constants in
+            <code>org.apache.cayenne.configuration.Constants</code> interface. </para>
+    <para>
+        <table frame="void">
+            <caption>Configuration Properties Recognized by ServerRuntime and/or ClientRuntime</caption>
+            <col width="67%"/>
+            <col width="15%"/>
+            <col width="18%"/>
+            <thead>
+                <tr>
+                    <th>Property</th>
+                    <th>Possible Values</th>
+                    <th>Default Value</th>
+                </tr>
+            </thead>
+            <tbody>
+                <tr>
+                    <td><code>cayenne.jdbc.driver[.domain_name.node_name]</code> - defines a JDBC driver class to
+                        use when creating a DataSource. If domain name and optionally - node name
+                        are specified, the setting overrides DataSource info just for this
+                        domain/node. Otherwise the override is applied to all domains/nodes in the
+                        system.</td>
+                    <td/>
+                    <td>none, project DataNode configuration is used</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.jdbc.url[.domain_name.node_name] </code>- defines a DB URL to use when
+                        creating a DataSource. If domain name and optionally - node name are
+                        specified, the setting overrides DataSource info just for this domain/node.
+                        Otherwise the override is applied to all domains/nodes in the system.</td>
+                    <td/>
+                    <td>none, project DataNode configuration is used</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.jdbc.username[.domain_name.node_name] </code>- defines a DB user name to use
+                        when creating a DataSource. If domain name and optionally - node name are
+                        specified, the setting overrides DataSource info just for this domain/node.
+                        Otherwise the override is applied to all domains/nodes in the system.</td>
+                    <td/>
+                    <td>none, project DataNode configuration is used</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.jdbc.password[.domain_name.node_name]</code> - defines a DB password to use
+                        when creating a DataSource. If domain name and optionally - node name are
+                        specified, the setting overrides DataSource info just for this domain/node.
+                        Otherwise the override is applied to all domains/nodes in the system</td>
+                    <td/>
+                    <td>none, project DataNode configuration is used</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.jdbc.min_connections[.domain_name.node_name]</code> - defines the DB
+                        connection pool minimal size. If domain name and optionally - node name are
+                        specified, the setting overrides DataSource info just for this domain/node.
+                        Otherwise the override is applied to all domains/nodes in the system</td>
+                    <td/>
+                    <td>none, project DataNode configuration is used</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.jdbc.max_connections[.domain_name.node_name]</code> - defines the DB
+                        connection pool maximum size. If domain name and optionally - node name are
+                        specified, the setting overrides DataSource info just for this domain/node.
+                        Otherwise the override is applied to all domains/nodes in the system</td>
+                    <td/>
+                    <td>none, project DataNode configuration is used</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.querycache.size</code> - An integer defining the maximum number of entries in
+                        the query cache. Note that not all QueryCache providers may respect this
+                        property. MapQueryCache uses it, but the rest would use alternative
+                        configuration methods.</td>
+                    <td>any positive int value</td>
+                    <td>2000</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.server.contexts_sync_strategy</code> - defines whether peer ObjectContexts
+                        should receive snapshot events after commits from other contexts. If true
+                        (default), the contexts would automatically synchronize their state with
+                        peers.</td>
+                    <td>true, false</td>
+                    <td>true</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.server.object_retain_strategy</code> - defines fetched objects retain
+                        strategy for ObjectContexts. When weak or soft strategy is used, objects
+                        retained by ObjectContext that have no local changes can potetially get
+                        garbage collected when JVM feels like doing it.</td>
+                    <td>weak, soft, hard</td>
+                    <td>weak</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.server.max_id_qualifier_size</code> - defines a maximum number of ID
+                        qualifiers in the WHERE  clause of queries that are generated for paginated
+                        queries and for DISJOINT_BY_ID prefetch processing. This is needed to avoid
+                        hitting WHERE clause size limitations and memory usage efficiency.</td>
+                    <td>any positive int</td>
+                    <td>10000</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.rop.service_url</code> - defines the URL of the ROP server</td>
+                    <td/>
+                    <td/>
+                </tr>
+                <tr>
+                    <td><code>cayenne.rop.service_username</code> - defines the user name for an ROP client to
+                        login to an ROP server.</td>
+                    <td/>
+                    <td/>
+                </tr>
+                <tr>
+                    <td><code>cayenne.rop.service_password</code> - defines the password for an ROP client to login
+                        to an ROP server.</td>
+                    <td/>
+                    <td/>
+                </tr>
+                <tr>
+                    <td><code>cayenne.rop.shared_session_name</code>- defines the name of the shared session that
+                        an ROP client wants to join on an ROP server. If omitted, a dedicated
+                        session is created.</td>
+                    <td/>
+                    <td/>
+                </tr>
+                <tr>
+                    <td><code>cayenne.rop.service.timeout</code> - a value in milliseconds for the
+                        ROP client-server connection read operation timeout</td>
+                    <td>any positive long value</td>
+                    <td/>
+                </tr>
+                <tr>
+                    <td><code>cayenne.rop.channel_events</code> - defines whether client-side DataChannel should
+                        dispatch events to child ObjectContexts. If set to true, ObjectContexts will
+                        receive commit events and merge changes committed by peer contexts that
+                        passed through the common client DataChannel.</td>
+                    <td>true, false</td>
+                    <td>false</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.rop.context_change_events</code>- defines whether object property changes in
+                        the client context result in firing events. Client UI components can listen
+                        to these events and update the UI. Disabled by default.</td>
+                    <td>true, false</td>
+                    <td>false</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.rop.context_lifecycle_events</code> - defines whether object commit and
+                        rollback operations in the client context result in firing events. Client UI
+                        components can listen to these events and update the UI. Disabled by
+                        default.</td>
+                    <td>true,false</td>
+                    <td>false</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.server.rop_event_bridge_factory</code> - defines the name of
+                        the org.apache.cayenne.event.EventBridgeFactory that is passed from the ROP
+                        server to the client. I.e. server DI would provide a name of the factory,
+                        passing this name to the client via the wire. The client would instantiate
+                        it to receive events from the server. Note that this property is stored in
+                        "cayenne.server.rop_event_bridge_properties" map, not in the main
+                        "cayenne.properties".</td>
+                    <td/>
+                    <td/>
+                </tr>
+            </tbody>
+        </table>
+    </para>
 </appendix>

Modified: cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/appendix-b.xml
URL: http://svn.apache.org/viewvc/cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/appendix-b.xml?rev=1425991&r1=1425990&r2=1425991&view=diff
==============================================================================
--- cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/appendix-b.xml (original)
+++ cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/appendix-b.xml Wed Dec 26 18:55:53 2012
@@ -1,65 +1,65 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <appendix xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink"
-	version="5.0" xml:id="client-configuration-properties">
-	<title>Service Collections</title>
-	<para>Note that the collection keys below are
-				defined as constants in <code>org.apache.cayenne.configuration.Constants</code>
-				interface.</para>
-	<para>
-		<table frame="void">
-			<caption>Service Collection Keys Present in ServerRuntime and/or ClientRuntime</caption>
-			<col width="100%"/>
-			<tbody>
-				<tr>
-					<td><code>cayenne.properties</code> - Map&lt;String,String> of properties used by built-in
-						Cayenne services. The keys in this map are the property names from the table
-						in Appendix A. Separate copies of this map exist on the server and ROP
-						client.</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.server.adapter_detectors</code> - List&lt;DbAdapterDetector> that contains
-						objects that can discover the type of current database and install the
-						correct DbAdapter in runtime.</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.server.domain_filters</code> - List&lt;DataChannelFilter> storing DataDomain
-						filters.</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.server.project_locations</code> - List&lt;String> storing
-						locations of the one of more project configuration files.</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.server.default_types</code> - List&lt;ExtendedType> storing
-						default adapter-agnostic ExtendedTypes. Default ExtendedTypes can be
-						overridden / extended by DB-specific DbAdapters as well as by user-provided
-						types configured in another colltecion (see
-						"cayenne.server.user_types").</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.server.user_types</code> - List&lt;ExtendedType> storing a
-						user-provided ExtendedTypes. This collection will be merged into a full list
-						of ExtendedTypes and would override any ExtendedTypes defined in a default
-						list, or by a DbAdapter.</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.server.type_factories</code> - List&lt;ExtendedTypeFactory>
-						storing default and user-provided ExtendedTypeFactories. ExtendedTypeFactory
-						allows to define ExtendedTypes dynamically for the whole group of Java
-						classes. E.g. Cayenne supplies a factory to map all Enums regardless of
-						their type.</td>
-				</tr>
-				<tr>
-					<td><code>cayenne.server.rop_event_bridge_properties</code> -  Map&lt;String,
-						String> storing event bridge properties passed to the ROP client on
-						bootstrap. This means that the map is configured by server DI, and passed to
-						the client via the wire. The properties in this map are specific to
-						EventBridgeFactory implementation (e.g JMS or XMPP connection prameters).
-						One common property is "cayenne.server.rop_event_bridge_factory" that
-						defines the type of the factory.</td>
-				</tr>
-			</tbody>
-		</table>
-	</para>
-	
+    version="5.0" xml:id="client-configuration-properties">
+    <title>Service Collections</title>
+    <para>Note that the collection keys below are
+                defined as constants in <code>org.apache.cayenne.configuration.Constants</code>
+                interface.</para>
+    <para>
+        <table frame="none">
+            <caption>Service Collection Keys Present in ServerRuntime and/or ClientRuntime</caption>
+            <col width="100%"/>
+            <tbody>
+                <tr>
+                    <td><code>cayenne.properties</code> - Map&lt;String,String> of properties used by built-in
+                        Cayenne services. The keys in this map are the property names from the table
+                        in Appendix A. Separate copies of this map exist on the server and ROP
+                        client.</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.server.adapter_detectors</code> - List&lt;DbAdapterDetector> that contains
+                        objects that can discover the type of current database and install the
+                        correct DbAdapter in runtime.</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.server.domain_filters</code> - List&lt;DataChannelFilter> storing DataDomain
+                        filters.</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.server.project_locations</code> - List&lt;String> storing
+                        locations of the one of more project configuration files.</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.server.default_types</code> - List&lt;ExtendedType> storing
+                        default adapter-agnostic ExtendedTypes. Default ExtendedTypes can be
+                        overridden / extended by DB-specific DbAdapters as well as by user-provided
+                        types configured in another colltecion (see
+                        "cayenne.server.user_types").</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.server.user_types</code> - List&lt;ExtendedType> storing a
+                        user-provided ExtendedTypes. This collection will be merged into a full list
+                        of ExtendedTypes and would override any ExtendedTypes defined in a default
+                        list, or by a DbAdapter.</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.server.type_factories</code> - List&lt;ExtendedTypeFactory>
+                        storing default and user-provided ExtendedTypeFactories. ExtendedTypeFactory
+                        allows to define ExtendedTypes dynamically for the whole group of Java
+                        classes. E.g. Cayenne supplies a factory to map all Enums regardless of
+                        their type.</td>
+                </tr>
+                <tr>
+                    <td><code>cayenne.server.rop_event_bridge_properties</code> -  Map&lt;String,
+                        String> storing event bridge properties passed to the ROP client on
+                        bootstrap. This means that the map is configured by server DI, and passed to
+                        the client via the wire. The properties in this map are specific to
+                        EventBridgeFactory implementation (e.g JMS or XMPP connection prameters).
+                        One common property is "cayenne.server.rop_event_bridge_factory" that
+                        defines the type of the factory.</td>
+                </tr>
+            </tbody>
+        </table>
+    </para>
+
 </appendix>

Modified: cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/appendix-c.xml
URL: http://svn.apache.org/viewvc/cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/appendix-c.xml?rev=1425991&r1=1425990&r2=1425991&view=diff
==============================================================================
--- cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/appendix-c.xml (original)
+++ cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/appendix-c.xml Wed Dec 26 18:55:53 2012
@@ -58,8 +58,10 @@ TOKENS
  * Integer or real Numeric literal, whose object value is stored in the token manager's
  * "literalValue" field.
  */&lt;DEFAULT> TOKEN : {
-&lt;INT_LITERAL: ("0" (["0"-"7"])* | ["1"-"9"] (["0"-"9"])* | "0" ["x","X"] (["0"-"9","a"-"f","A"-"F"])+) (["l","L","h","H"])?> : {
-| &lt;FLOAT_LITERAL: &lt;DEC_FLT> (&lt;EXPONENT>)? (&lt;FLT_SUFF>)? | &lt;DEC_DIGITS> &lt;EXPONENT> (&lt;FLT_SUFF>)? | &lt;DEC_DIGITS> &lt;FLT_SUFF>> : {
+&lt;INT_LITERAL: ("0" (["0"-"7"])* | ["1"-"9"] (["0"-"9"])* | "0" ["x","X"] (["0"-"9","a"-"f","A"-"F"])+)
+        (["l","L","h","H"])?> : {
+| &lt;FLOAT_LITERAL: &lt;DEC_FLT> (&lt;EXPONENT>)? (&lt;FLT_SUFF>)? | &lt;DEC_DIGITS> &lt;EXPONENT> (&lt;FLT_SUFF>)?
+| &lt;DEC_DIGITS> &lt;FLT_SUFF>> : {
 | &lt;#DEC_FLT: (["0"-"9"])+ "." (["0"-"9"])* | "." (["0"-"9"])+>
 | &lt;#DEC_DIGITS: (["0"-"9"])+>
 | &lt;#EXPONENT: ["e","E"] (["+","-"])? (["0"-"9"])+>
@@ -67,14 +69,14 @@ TOKENS
 }
 
 NON-TERMINALS
-	expression	:=	orCondition &lt;EOF>
-	orCondition	:=	andCondition ( "or" andCondition )*
-	andCondition	:=	notCondition ( "and" notCondition )*
-	notCondition	:=	( "not" | "!" ) simpleCondition
-		|	simpleCondition
-	simpleCondition	:=	&lt;TRUE>
-		|	&lt;FALSE>
-		|	scalarConditionExpression 
+    expression    :=    orCondition &lt;EOF>
+    orCondition    :=    andCondition ( "or" andCondition )*
+    andCondition    :=    notCondition ( "and" notCondition )*
+    notCondition    :=    ( "not" | "!" ) simpleCondition
+        |    simpleCondition
+    simpleCondition    :=    &lt;TRUE>
+        |    &lt;FALSE>
+        |    scalarConditionExpression
              ( simpleNotCondition 
                | ( "=" | "==" ) scalarExpression 
                | ( "!=" | "&lt;>" ) scalarExpression 
@@ -86,39 +88,39 @@ NON-TERMINALS
                | "in" ( namedParameter | "(" scalarCommaList ")" ) 
                | "between" scalarExpression "and" scalarExpression 
              )?
-	simpleNotCondition	:=	( "not" | "!" ) 
+    simpleNotCondition    :=    ( "not" | "!" )
              ( "like" scalarExpression 
                | "likeIgnoreCase" scalarExpression 
                | "in" ( namedParameter | "(" scalarCommaList ")" ) 
                | "between" scalarExpression "and" scalarExpression 
              )
-	scalarCommaList	:=	( scalarConstExpression ( "," scalarConstExpression )* )
-	scalarConditionExpression	:=	scalarNumericExpression
-		|	&lt;SINGLE_QUOTED_STRING> 
-		|	&lt;DOUBLE_QUOTED_STRING> 
-		|	&lt;NULL>
-	scalarExpression	:=	scalarConditionExpression
-		|	&lt;TRUE> 
-		|	&lt;FALSE> 
-	scalarConstExpression	:=	&lt;SINGLE_QUOTED_STRING> 
-		|	&lt;DOUBLE_QUOTED_STRING> 
-		|	namedParameter
-		|	&lt;INT_LITERAL> 
-		|	&lt;FLOAT_LITERAL> 
-		|	&lt;TRUE> 
-		|	&lt;FALSE> 
-	scalarNumericExpression	:=	multiplySubtractExp 
+    scalarCommaList    :=    ( scalarConstExpression ( "," scalarConstExpression )* )
+    scalarConditionExpression    :=    scalarNumericExpression
+        |    &lt;SINGLE_QUOTED_STRING>
+        |    &lt;DOUBLE_QUOTED_STRING>
+        |    &lt;NULL>
+    scalarExpression    :=    scalarConditionExpression
+        |    &lt;TRUE>
+        |    &lt;FALSE>
+    scalarConstExpression    :=    &lt;SINGLE_QUOTED_STRING>
+        |    &lt;DOUBLE_QUOTED_STRING>
+        |    namedParameter
+        |    &lt;INT_LITERAL>
+        |    &lt;FLOAT_LITERAL>
+        |    &lt;TRUE>
+        |    &lt;FALSE>
+    scalarNumericExpression    :=    multiplySubtractExp
              ( "+" multiplySubtractExp | "-" multiplySubtractExp )*
-	multiplySubtractExp	:=	numericTerm ( "*" numericTerm | "/" numericTerm )*
-	numericTerm	:=	( "+" )? numericPrimary
-		|	"-" numericPrimary
-	numericPrimary	:=	"(" orCondition ")"
-		|	pathExpression
-		|	namedParameter
-		|	&lt;INT_LITERAL> 
-		|	&lt;FLOAT_LITERAL> 
-	namedParameter	:=	"$" &lt;PROPERTY_PATH> 
-	pathExpression	:=	( &lt;PROPERTY_PATH>  
+    multiplySubtractExp    :=    numericTerm ( "*" numericTerm | "/" numericTerm )*
+    numericTerm    :=    ( "+" )? numericPrimary
+        |    "-" numericPrimary
+    numericPrimary    :=    "(" orCondition ")"
+        |    pathExpression
+        |    namedParameter
+        |    &lt;INT_LITERAL>
+        |    &lt;FLOAT_LITERAL>
+    namedParameter    :=    "$" &lt;PROPERTY_PATH>
+    pathExpression    :=    ( &lt;PROPERTY_PATH>
                             | "obj:" &lt;PROPERTY_PATH>  
                             | "db:" &lt;PROPERTY_PATH>  
                             | "enum:" &lt;PROPERTY_PATH>  )

Modified: cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/cayenne-mapping-structure.xml
URL: http://svn.apache.org/viewvc/cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/cayenne-mapping-structure.xml?rev=1425991&r1=1425990&r2=1425991&view=diff
==============================================================================
--- cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/cayenne-mapping-structure.xml (original)
+++ cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/cayenne-mapping-structure.xml Wed Dec 26 18:55:53 2012
@@ -1,35 +1,35 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink"
-	version="5.0" xml:id="cayenne-mapping-structure">
-	<title>Cayenne Mapping Structure</title>
-	<section xml:id="cayenne-project">
-		<title>Cayenne Project</title>
-	</section>
-	<section xml:id="datamap">
-		<title>DataMap</title>
-	</section>
-	<section xml:id="datanode">
-		<title>DataNode</title>
-	</section>
-	<section xml:id="dbentity">
-		<title>DbEntity</title>
-	</section>
-	<section xml:id="objentity">
-		<title>ObjEntity</title>
-		<section xml:id="mapping-objattributes-to-custom-classes">
-			<title>Mapping ObjAttributes to Custom Classes</title>
-		</section>
-	</section>
-	<section xml:id="embeddable">
-		<title>Embeddable</title>
-	</section>
-	<section xml:id="procedure">
-		<title>Procedure</title>
-	</section>
-	<section xml:id="query">
-		<title>Query</title>
-	</section>
-	<section xml:id="listeners-and-callbacks">
-		<title>Listeners and Callbacks</title>
-	</section>
+    version="5.0" xml:id="cayenne-mapping-structure">
+    <title>Cayenne Mapping Structure</title>
+    <section xml:id="cayenne-project">
+        <title>Cayenne Project</title>
+    </section>
+    <section xml:id="datamap">
+        <title>DataMap</title>
+    </section>
+    <section xml:id="datanode">
+        <title>DataNode</title>
+    </section>
+    <section xml:id="dbentity">
+        <title>DbEntity</title>
+    </section>
+    <section xml:id="objentity">
+        <title>ObjEntity</title>
+        <section xml:id="mapping-objattributes-to-custom-classes">
+            <title>Mapping ObjAttributes to Custom Classes</title>
+        </section>
+    </section>
+    <section xml:id="embeddable">
+        <title>Embeddable</title>
+    </section>
+    <section xml:id="procedure">
+        <title>Procedure</title>
+    </section>
+    <section xml:id="query">
+        <title>Query</title>
+    </section>
+    <section xml:id="listeners-and-callbacks">
+        <title>Listeners and Callbacks</title>
+    </section>
 </chapter>

Modified: cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/cayennemodeler-application.xml
URL: http://svn.apache.org/viewvc/cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/cayennemodeler-application.xml?rev=1425991&r1=1425990&r2=1425991&view=diff
==============================================================================
--- cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/cayennemodeler-application.xml (original)
+++ cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/cayennemodeler-application.xml Wed Dec 26 18:55:53 2012
@@ -1,42 +1,42 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink"
-	version="5.0" xml:id="cayennemodeler-application">
-	<title>CayenneModeler Application</title>
-	<section xml:id="working-with-mapping-projects">
-		<title>Working with Mapping Projects</title>
-	</section>
-	<section xml:id="reverse-engineering-database">
-		<title>Reverse Engineering Database</title>
-	</section>
-	<section xml:id="generating-database-schema">
-		<title>Generating Database Schema</title>
-	</section>
-	<section xml:id="migrations">
-		<title>Migrations</title>
-	</section>
-	<section xml:id="generating-java-classes">
-		<title>Generating Java Classes</title>
-	</section>
-	<section xml:id="modeling-inheritance">
-		<title>Modeling Inheritance</title>
-	</section>
-	<section xml:id="modeling-generic-persistence-classes">
-		<title>Modeling Generic Persistent Classes</title>
-		<para>Normally each ObjEntity is mapped to a specific Java class (such as Artist or
-			Painting) that explicitly declare all entity properties as pairs of getters and setters.
-			However Cayenne allows to map a completly generic class to any number of entities. The
-			only expectation is that a generic class implements
-				<emphasis>org.apache.cayenne.DataObject</emphasis>. So an ideal candidate for a
-			generic class is CayenneDataObject, or some custom subclass of CayenneDataObject.</para>
-		<para>If you don't enter anything for Java Class of an ObjEntity, Cayenne assumes generic
-			mapping and uses the following implicit rules to determine a class of a generic object.
-			If DataMap "Custom Superclass" is set, runtime uses this class to instantiate new
-			objects. If not, org.apache.cayenne.CayenneDataObject is used.</para>
-		<para>Class generation procedures (either done in the Modeler or with Ant or Maven) would
-			skip entities that are mapped to CayenneDataObject explicitly or have no class
-			mapping.</para>
-	</section>
-	<section xml:id="modeling-pk-generation-strategy">
-		<title>Modeling Primary Key Generation Strategy</title>
-	</section>
+    version="5.0" xml:id="cayennemodeler-application">
+    <title>CayenneModeler Application</title>
+    <section xml:id="working-with-mapping-projects">
+        <title>Working with Mapping Projects</title>
+    </section>
+    <section xml:id="reverse-engineering-database">
+        <title>Reverse Engineering Database</title>
+    </section>
+    <section xml:id="generating-database-schema">
+        <title>Generating Database Schema</title>
+    </section>
+    <section xml:id="migrations">
+        <title>Migrations</title>
+    </section>
+    <section xml:id="generating-java-classes">
+        <title>Generating Java Classes</title>
+    </section>
+    <section xml:id="modeling-inheritance">
+        <title>Modeling Inheritance</title>
+    </section>
+    <section xml:id="modeling-generic-persistence-classes">
+        <title>Modeling Generic Persistent Classes</title>
+        <para>Normally each ObjEntity is mapped to a specific Java class (such as Artist or
+            Painting) that explicitly declare all entity properties as pairs of getters and setters.
+            However Cayenne allows to map a completly generic class to any number of entities. The
+            only expectation is that a generic class implements
+                <emphasis>org.apache.cayenne.DataObject</emphasis>. So an ideal candidate for a
+            generic class is CayenneDataObject, or some custom subclass of CayenneDataObject.</para>
+        <para>If you don't enter anything for Java Class of an ObjEntity, Cayenne assumes generic
+            mapping and uses the following implicit rules to determine a class of a generic object.
+            If DataMap "Custom Superclass" is set, runtime uses this class to instantiate new
+            objects. If not, org.apache.cayenne.CayenneDataObject is used.</para>
+        <para>Class generation procedures (either done in the Modeler or with Ant or Maven) would
+            skip entities that are mapped to CayenneDataObject explicitly or have no class
+            mapping.</para>
+    </section>
+    <section xml:id="modeling-pk-generation-strategy">
+        <title>Modeling Primary Key Generation Strategy</title>
+    </section>
 </chapter>

Modified: cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/current-limitations.xml
URL: http://svn.apache.org/viewvc/cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/current-limitations.xml?rev=1425991&r1=1425990&r2=1425991&view=diff
==============================================================================
--- cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/current-limitations.xml (original)
+++ cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/current-limitations.xml Wed Dec 26 18:55:53 2012
@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink"
-	version="5.0" xml:id="current-limitations">
-	<title>Current Limitations</title>
+    version="5.0" xml:id="current-limitations">
+    <title>Current Limitations</title>
 </chapter>

Modified: cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/customizing-cayenne-runtime.xml
URL: http://svn.apache.org/viewvc/cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/customizing-cayenne-runtime.xml?rev=1425991&r1=1425990&r2=1425991&view=diff
==============================================================================
--- cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/customizing-cayenne-runtime.xml (original)
+++ cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/customizing-cayenne-runtime.xml Wed Dec 26 18:55:53 2012
@@ -1,108 +1,108 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="customizing-cayenne-runtime">
-	<title>Customizing Cayenne Runtime</title>
-	<section xml:id="depdendency-injection-container">
-		<title>Dependency Injection Container</title>
-		<para>Cayenne runtime is built around a small powerful dependency injection (DI) container. Just
-			like other popular DI technologies, such as Spring or Guice, Cayenne DI container
-			manages sets of interdependent objects  and allows users to configure them. These
-			objects are regular Java objects. We are calling them "services" in this document to
-			distinguish from all other objects that are not configured in the container and are not
-			managed. DI container is responsible for service instantiation, injecting correct
-			dependencies, maintaining service instances scope, and dispatching scope events to
-			services. </para>
-		<para>The services are configured in special Java classes called "modules". Each module
-			defines binding of service interfaces to implementation instances, implementation types
-			or providers of implementation instances. There are no XML configuration files, and all
-			the bindings are type-safe. The container supports injection into instance variables and
-			constructor parameters based on the <code>@Inject</code> annotation. This mechanism is
-			very close to Google Guice.</para>
-		<para>The discussion later in this chapter demonstrates a standalone DI container. But keep in
-			mind that Cayenne already has a built-in Injector, and a set of default modules. A
-			Cayenne user would normally only use the API below to write custom extension modules
-			that will be loaded in that existing container when creating ServerRuntime. See
-			"Starting and Stopping ServerRuntime" chapter for an example of passing an extension
-			module to Cayenne.</para>
-		<para>Cayenne DI probably has ~80% of the features expected in a DI container and has no
-			dependency on the rest of Cayenne, so in theory can be used as an application-wide DI
-			engine. But it's primary purpose is still to serve Cayenne. Hence there are no plans to
-			expand it beyond Cayenne needs. It is an ideal "embedded" DI that does not interfere
-			with Spring, Guice or any other such framework present elsewhere in the
-			application.</para>
-		<section xml:id="di-bindings-api">
-			<title>DI Bindings API</title>
-			<para>To have a working DI container, we need three things: service interfaces and
-				classes, a module that describes service bindings, a container that loads the
-				module, and resolves the depedencies. Let's start with service interfaces and
-				classes:<programlisting language="java">public interface Service1 {
-	public String getString();
+    <title>Customizing Cayenne Runtime</title>
+    <section xml:id="depdendency-injection-container">
+        <title>Dependency Injection Container</title>
+        <para>Cayenne runtime is built around a small powerful dependency injection (DI) container. Just
+            like other popular DI technologies, such as Spring or Guice, Cayenne DI container
+            manages sets of interdependent objects  and allows users to configure them. These
+            objects are regular Java objects. We are calling them "services" in this document to
+            distinguish from all other objects that are not configured in the container and are not
+            managed. DI container is responsible for service instantiation, injecting correct
+            dependencies, maintaining service instances scope, and dispatching scope events to
+            services. </para>
+        <para>The services are configured in special Java classes called "modules". Each module
+            defines binding of service interfaces to implementation instances, implementation types
+            or providers of implementation instances. There are no XML configuration files, and all
+            the bindings are type-safe. The container supports injection into instance variables and
+            constructor parameters based on the <code>@Inject</code> annotation. This mechanism is
+            very close to Google Guice.</para>
+        <para>The discussion later in this chapter demonstrates a standalone DI container. But keep in
+            mind that Cayenne already has a built-in Injector, and a set of default modules. A
+            Cayenne user would normally only use the API below to write custom extension modules
+            that will be loaded in that existing container when creating ServerRuntime. See
+            "Starting and Stopping ServerRuntime" chapter for an example of passing an extension
+            module to Cayenne.</para>
+        <para>Cayenne DI probably has ~80% of the features expected in a DI container and has no
+            dependency on the rest of Cayenne, so in theory can be used as an application-wide DI
+            engine. But it's primary purpose is still to serve Cayenne. Hence there are no plans to
+            expand it beyond Cayenne needs. It is an ideal "embedded" DI that does not interfere
+            with Spring, Guice or any other such framework present elsewhere in the
+            application.</para>
+        <section xml:id="di-bindings-api">
+            <title>DI Bindings API</title>
+            <para>To have a working DI container, we need three things: service interfaces and
+                classes, a module that describes service bindings, a container that loads the
+                module, and resolves the depedencies. Let's start with service interfaces and
+                classes:<programlisting language="java">public interface Service1 {
+    public String getString();
 }</programlisting><programlisting language="java">public interface Service2 {
-	public int getInt();
+    public int getInt();
 }</programlisting></para>
-			<para>A service implementation using instance variable
-				injection:<programlisting language="java">public class Service1Impl implements Service1 {
-	@Inject
-	private Service2 service2;
-	
-	public String getString() {
-		return service2.getInt() + "_Service1Impl";
-	}
+            <para>A service implementation using instance variable
+                injection:<programlisting language="java">public class Service1Impl implements Service1 {
+    @Inject
+    private Service2 service2;
+
+    public String getString() {
+        return service2.getInt() + "_Service1Impl";
+    }
 }</programlisting>Same
-				thing, but using constructor
-				injection:<programlisting language="java">public class Service1Impl implements Service1 {
+                thing, but using constructor
+                injection:<programlisting language="java">public class Service1Impl implements Service1 {
 
-	private Service2 service2;
+    private Service2 service2;
 
-	public Service1Impl(@Inject Service2 service2) {
-		this.service2 = service2;
-	}
+    public Service1Impl(@Inject Service2 service2) {
+        this.service2 = service2;
+    }
 
-	public String getString() {
-		return service2.getInt() + "_Service1Impl";
-	}
+    public String getString() {
+        return service2.getInt() + "_Service1Impl";
+    }
 }
 </programlisting><programlisting language="java">public class Service2Impl implements Service2 {
-	private int i;
+    private int i;
 
-	public int getInt() {
-		return i++;
-	}
+    public int getInt() {
+        return i++;
+    }
 }</programlisting></para>
-			<para>Now let's create a module implementing
-					<code>org.apache.cayenne.tutorial.di.Module</code> interface that will contain
-				DI configuration. A module binds service objects to keys that are reference. Binder
-				provided by container implements fluent API to connect the key to implementation,
-				and to configure various binding options (the options, such as scope, are
-				demonstrated later in this chapter). The simplest form of a key is a Java Class
-				object representing service interface. Here is a module that binds Service1 and
-				Service2 to corresponding default implementations:</para>
-			<para>
-				<programlisting language="java">public class Module1 implements Module {
+            <para>Now let's create a module implementing
+                    <code>org.apache.cayenne.tutorial.di.Module</code> interface that will contain
+                DI configuration. A module binds service objects to keys that are reference. Binder
+                provided by container implements fluent API to connect the key to implementation,
+                and to configure various binding options (the options, such as scope, are
+                demonstrated later in this chapter). The simplest form of a key is a Java Class
+                object representing service interface. Here is a module that binds Service1 and
+                Service2 to corresponding default implementations:</para>
+            <para>
+                <programlisting language="java">public class Module1 implements Module {
 
-	public void configure(Binder binder) {
-		binder.bind(Service1.class).to(Service1Impl.class);
-		binder.bind(Service2.class).to(Service2Impl.class);
-	}
+    public void configure(Binder binder) {
+        binder.bind(Service1.class).to(Service1Impl.class);
+        binder.bind(Service2.class).to(Service2Impl.class);
+    }
 }</programlisting>
-			</para>
-			<para>Once we have at least one module, we can create a DI container.
-					<code>org.apache.cayenne.di.Injector</code> is the container class in
-				Cayenne:<programlisting language="java">Injector injector = DIBootstrap.createInjector(new Module1());</programlisting></para>
-			<para>Now that we have created the container, we can obtain services from it and call
-				their
-				methods:<programlisting language="java">Service1 s1 = injector.getInstance(Service1.class);
+            </para>
+            <para>Once we have at least one module, we can create a DI container.
+                    <code>org.apache.cayenne.di.Injector</code> is the container class in
+                Cayenne:<programlisting language="java">Injector injector = DIBootstrap.createInjector(new Module1());</programlisting></para>
+            <para>Now that we have created the container, we can obtain services from it and call
+                their
+                methods:<programlisting language="java">Service1 s1 = injector.getInstance(Service1.class);
 for (int i = 0; i &lt; 5; i++) {
-	System.out.println("S1 String: " + s1.getString());
+    System.out.println("S1 String: " + s1.getString());
 }</programlisting></para>
-			<para>This outputs the following lines, demonstrating that s1 was Service1Impl and
-				Service2 injected into it was
-				Service2Impl:<programlisting language="java">0_Service1Impl
+            <para>This outputs the following lines, demonstrating that s1 was Service1Impl and
+                Service2 injected into it was
+                Service2Impl:<programlisting language="java">0_Service1Impl
 1_Service1Impl
 2_Service1Impl
 3_Service1Impl
 4_Service1Impl</programlisting></para>
-			<para>There are more flavors of bindings:
-				<programlisting language="java">// binding to instance - allowing user to create and configure instance
+            <para>There are more flavors of bindings:
+                <programlisting language="java">// binding to instance - allowing user to create and configure instance
 // inside the module class
 binder.bind(Service2.class).toInstance(new Service2Impl());
 
@@ -119,146 +119,146 @@ binder.bind(Service1.class).toProviderIn
 // private Service2 service2;
 binder.bind(Key.get(Service2.class, "i1")).to(Service2Impl.class);
 binder.bind(Key.get(Service2.class, "i2")).to(Service2Impl.class);</programlisting></para>
-			<para>Another types of confiuguration that can be bound in the container are lists and
-				maps. They will be discussed in the following chapters. </para>
-		</section>
-		<section xml:id="managing-services-lifecycle">
-			<title>Service Lifecycle</title>
-			<para>An important feature of the Cayenne DI container is instance <emphasis role="italic"
-					>scope</emphasis>. The default scope (implicitly used in all examples above) is
-				"singleton", meaning that a binding would result in creation of only one service
-				instance, that will be repeatedly returned from
-					<code>Injector.getInstance(..)</code>, as well as injected into classes that
-				declare it as a dependency. </para>
-			<para>Singleton scope dispatches a "BeforeScopeEnd" event to interested services. This
-				event occurs before the scope is shutdown, i.e. when
-					<code>Injector.shutdown()</code> is called. Note that the built-in Cayenne
-				injector is shutdown behind the scenes when <code>ServerRuntime.shutdown()</code>
-				is invoked. Services may register as listeners for this event by annotating a
-				no-argument method with <code>@BeforeScopeEnd</code> annotation. Such method should
-				be implemented if a service needs to clean up some resources, stop threads,
-				etc.</para>
-			<para>Another useful scope is "no scope", meaning that every time a container is asked to provide
-				a service instance for a given key, a new instance will be created and
-				returned:<programlisting language="java">binder.bind(Service2.class).to(Service2Impl.class).withoutScope();</programlisting>Users
-				can also create their own scopes, e.g. a web application request scope or a session
-				scope. Most often than not custom scopes can be created as instances of
-					<code>org.apache.cayenne.di.spi.DefaultScope</code> with startup and shutdown
-				managed by the application (e.g. singleton scope is a DefaultScope managed by the
-				Injector) . </para>
-		</section>
-		<section xml:id="overriding-services">
-			<title>Overriding Services</title>
-			<para>Cayenne DI allows to override services already definied in the current module, or
-				more commonly - some other module in the the same container. Actually there's no
-				special API to override a service, you'd just bind the service key again with a new
-				implementation or provider. The last binding for a key takes precedence. This means
-				that the order of modules is important when configuring a container. The built-in
-				Cayenne injector ensures that Cayenne standard modules are loaded first, followed by
-				optional user extension modules. This way the application can override the standard
-				services in Cayenne.</para>
-		</section>
-	</section>
-	<section xml:id="ways-to-customize-runtime">
-		<title> Customization Strategies</title>
-		<para>The previous section discussed how Cayenne DI works in general terms. Since Cayenne users
-			will mostly be dealing with an existing Injector provided by ServerRuntime, it is
-			important to understand how to build custom extensions to a preconfigured container. As
-			shown in "Starting and Stopping ServerRuntime" chapter, custom extensions are done by
-			writing an aplication DI module (or multiple modules) that configures service overrides.
-			This section shows all the configuration possibilities in detail, including changing
-			properties of the existing services, contributing services to standard service lists and
-			maps, and overriding service implementations. All the code examples later in this
-			section are assumed to be placed in an application module "configure" method:</para><programlisting>public class MyExtensionsModule implements Module {
-	public void configure(Binder binder) {
-		// customizations go here...
-	}	
+            <para>Another types of confiuguration that can be bound in the container are lists and
+                maps. They will be discussed in the following chapters. </para>
+        </section>
+        <section xml:id="managing-services-lifecycle">
+            <title>Service Lifecycle</title>
+            <para>An important feature of the Cayenne DI container is instance <emphasis role="italic"
+                    >scope</emphasis>. The default scope (implicitly used in all examples above) is
+                "singleton", meaning that a binding would result in creation of only one service
+                instance, that will be repeatedly returned from
+                    <code>Injector.getInstance(..)</code>, as well as injected into classes that
+                declare it as a dependency. </para>
+            <para>Singleton scope dispatches a "BeforeScopeEnd" event to interested services. This
+                event occurs before the scope is shutdown, i.e. when
+                    <code>Injector.shutdown()</code> is called. Note that the built-in Cayenne
+                injector is shutdown behind the scenes when <code>ServerRuntime.shutdown()</code>
+                is invoked. Services may register as listeners for this event by annotating a
+                no-argument method with <code>@BeforeScopeEnd</code> annotation. Such method should
+                be implemented if a service needs to clean up some resources, stop threads,
+                etc.</para>
+            <para>Another useful scope is "no scope", meaning that every time a container is asked to provide
+                a service instance for a given key, a new instance will be created and
+                returned:<programlisting language="java">binder.bind(Service2.class).to(Service2Impl.class).withoutScope();</programlisting>Users
+                can also create their own scopes, e.g. a web application request scope or a session
+                scope. Most often than not custom scopes can be created as instances of
+                    <code>org.apache.cayenne.di.spi.DefaultScope</code> with startup and shutdown
+                managed by the application (e.g. singleton scope is a DefaultScope managed by the
+                Injector) . </para>
+        </section>
+        <section xml:id="overriding-services">
+            <title>Overriding Services</title>
+            <para>Cayenne DI allows to override services already definied in the current module, or
+                more commonly - some other module in the the same container. Actually there's no
+                special API to override a service, you'd just bind the service key again with a new
+                implementation or provider. The last binding for a key takes precedence. This means
+                that the order of modules is important when configuring a container. The built-in
+                Cayenne injector ensures that Cayenne standard modules are loaded first, followed by
+                optional user extension modules. This way the application can override the standard
+                services in Cayenne.</para>
+        </section>
+    </section>
+    <section xml:id="ways-to-customize-runtime">
+        <title> Customization Strategies</title>
+        <para>The previous section discussed how Cayenne DI works in general terms. Since Cayenne users
+            will mostly be dealing with an existing Injector provided by ServerRuntime, it is
+            important to understand how to build custom extensions to a preconfigured container. As
+            shown in "Starting and Stopping ServerRuntime" chapter, custom extensions are done by
+            writing an aplication DI module (or multiple modules) that configures service overrides.
+            This section shows all the configuration possibilities in detail, including changing
+            properties of the existing services, contributing services to standard service lists and
+            maps, and overriding service implementations. All the code examples later in this
+            section are assumed to be placed in an application module "configure" method:</para><programlisting>public class MyExtensionsModule implements Module {
+    public void configure(Binder binder) {
+        // customizations go here...
+    }
 }</programlisting><programlisting language="java">Module extensions = new MyExtensionsModule();
 ServerRuntime runtime = 
-	new ServerRuntime("com/example/cayenne-mydomain.xml", extensions);</programlisting>
-		<section xml:id="changing-properties-of-existing-services">
-			<title>Changing Properties of Existing Services</title>
-			<para>Many built-in Cayenne services change their behavior based on a value of some
-				environment property. A user may change Cayenne behavior without even knowing which
-				services are responsible for it, but setting a specific value of a known property.
-				Supported property names are listed in "Appendix A".</para>
-			<para>There are two ways to set service properties. The most obvious one is to pass it
-				to the JVM with -D flag on startup.
-				E.g.<programlisting>java -Dorg.apache.cayenne.sync_contexts=false ...</programlisting></para>
-			<para>A second one is to contribute a property to
-					<code>org.apache.cayenne.configuration.DefaultRuntimeProperties.properties
-				</code>map (see the next section on how to do that). This map contains the default
-				property values and can accept application-specific values, overrding the defaults. </para>
-			<para>Note that if a property value is a name of a Java class, when this Java class is
-				instantiated by Cayenne, the container performs injection of instance variables. So
-				even the dynamically specified Java classes can use @Inject annotation to get a hold
-				of other Cayenne services.</para>
-			<para>If the same property is specified both in the command line and in the properties
-				map, the command-line value takes precedence. The map value will be ignored. This
-				way Cayenne runtime can be reconfigured during deployment.</para>
-		</section>
-		<section xml:id="contributing-to-service-lists-maps">
-			<title>Contributing to Service Collections</title>
-			<para>Cayenne can be extended by adding custom objects to named maps or lists bound in
-				DI. We are calling these lists/maps "service collections". A service collection
-				allows things like appending a custom strategy to a list of built-in strategies.
-				E.g. an application that needs to install a custom DbAdapter for some database type
-				may contribute an instance of custom DbAdapterDetector to a
-					<code>org.apache.cayenne.configuration.server.DefaultDbAdapterFactory.detectors</code>
-				list:</para>
-			<programlisting language="java">public class MyDbAdapterDetector implements DbAdapterDetector {
-	public DbAdapter createAdapter(DatabaseMetaData md) throws SQLException {
-		// check if we support this database and retun custom adapter
-		...
-	}
+    new ServerRuntime("com/example/cayenne-mydomain.xml", extensions);</programlisting>
+        <section xml:id="changing-properties-of-existing-services">
+            <title>Changing Properties of Existing Services</title>
+            <para>Many built-in Cayenne services change their behavior based on a value of some
+                environment property. A user may change Cayenne behavior without even knowing which
+                services are responsible for it, but setting a specific value of a known property.
+                Supported property names are listed in "Appendix A".</para>
+            <para>There are two ways to set service properties. The most obvious one is to pass it
+                to the JVM with -D flag on startup.
+                E.g.<programlisting>java -Dorg.apache.cayenne.sync_contexts=false ...</programlisting></para>
+            <para>A second one is to contribute a property to
+                    <code>org.apache.cayenne.configuration.DefaultRuntimeProperties.properties
+                </code>map (see the next section on how to do that). This map contains the default
+                property values and can accept application-specific values, overrding the defaults. </para>
+            <para>Note that if a property value is a name of a Java class, when this Java class is
+                instantiated by Cayenne, the container performs injection of instance variables. So
+                even the dynamically specified Java classes can use @Inject annotation to get a hold
+                of other Cayenne services.</para>
+            <para>If the same property is specified both in the command line and in the properties
+                map, the command-line value takes precedence. The map value will be ignored. This
+                way Cayenne runtime can be reconfigured during deployment.</para>
+        </section>
+        <section xml:id="contributing-to-service-lists-maps">
+            <title>Contributing to Service Collections</title>
+            <para>Cayenne can be extended by adding custom objects to named maps or lists bound in
+                DI. We are calling these lists/maps "service collections". A service collection
+                allows things like appending a custom strategy to a list of built-in strategies.
+                E.g. an application that needs to install a custom DbAdapter for some database type
+                may contribute an instance of custom DbAdapterDetector to a
+                    <code>org.apache.cayenne.configuration.server.DefaultDbAdapterFactory.detectors</code>
+                list:</para>
+            <programlisting language="java">public class MyDbAdapterDetector implements DbAdapterDetector {
+    public DbAdapter createAdapter(DatabaseMetaData md) throws SQLException {
+        // check if we support this database and retun custom adapter
+        ...
+    }
 }</programlisting>
-			<programlisting language="java">// since build-in list for this key is a singleton, repeated
+            <programlisting language="java">// since build-in list for this key is a singleton, repeated
 // calls to 'bindList' will return the same instance 
 binder.bindList(DefaultDbAdapterFactory.DETECTORS_LIST)
        .add(MyDbAdapterDetector.class);</programlisting>
-			<para>Maps are customized using a similar "<code>bindMap</code>" method.</para>
-			<para>The names of built-in collections are listed in "Appendix B".</para>
-		</section>
-		<section xml:id="alternative-service-implementations">
-			<title>Alternative Service Implementations</title>
-			<para>As mentioned above, custom modules are loaded by ServerRuntime after the built-in
-				modules. So it is easy to redefine a built-in service in Cayenne by rebinding
-				desired implementations or providers. To do that, first we need to know what those
-				services to redefine are. While we describe some of them in the following sections,
-				the best way to get a full list is to check the source code of the Cayenne version
-				you are using and namely look in
-					<code>org.apache.cayenne.configuration.server.ServerModule</code> - the main
-				built-in module in Cayenne. </para>
-			<para>Now an example of overriding <code>QueryCache</code> service. The default
-				implementation of this service is provided by <code>MapQueryCacheProvider</code>.
-				But if we want to use <code>EhCacheQueryCache</code> (a Cayenne wrapper for the
-				EhCache framework), we can define it like
-				this:<programlisting language="java">binder.bind(QueryCache.class).to(EhCacheQueryCache.class);</programlisting></para>
-		</section>
-	</section>
-	<section xml:id="noteworthy-runtime-components">
-		<title>Noteworthy Built-in Services</title>
-		<section xml:id="jdbceventlogger">
-			<title>JdbcEventLogger</title>
-			<para><code>org.apache.cayenne.log.JdbcEventLogger</code> is the service that defines
-				logging API for Cayenne internals. It provides facilities for logging queries,
-				commits, transactions, etc. The default implementation is
-					<code>org.apache.cayenne.log.CommonsJdbcEventLogger</code> that performs logging
-				via commons-logging library. Cayenne library includes another potentially useful
-				logger - <code>org.apache.cayenne.log.FormattedCommonsJdbcEventLogger</code> that
-				produces formatted multiline SQL output that can be easier to read.</para>
-		</section>
-		<section xml:id="datasourcefactory">
-			<title>DataSourceFactory</title>
-		</section>
-		<section xml:id="datachannelfilter">
-			<title>DataChannelFilter</title>
-		</section>
-		<section xml:id="querycache">
-			<title>QueryCache</title>
-		</section>
-		<section xml:id="extendedtypes">
-			<title>ExtendedTypes</title>
-		</section>
-	</section>
+            <para>Maps are customized using a similar "<code>bindMap</code>" method.</para>
+            <para>The names of built-in collections are listed in "Appendix B".</para>
+        </section>
+        <section xml:id="alternative-service-implementations">
+            <title>Alternative Service Implementations</title>
+            <para>As mentioned above, custom modules are loaded by ServerRuntime after the built-in
+                modules. So it is easy to redefine a built-in service in Cayenne by rebinding
+                desired implementations or providers. To do that, first we need to know what those
+                services to redefine are. While we describe some of them in the following sections,
+                the best way to get a full list is to check the source code of the Cayenne version
+                you are using and namely look in
+                    <code>org.apache.cayenne.configuration.server.ServerModule</code> - the main
+                built-in module in Cayenne. </para>
+            <para>Now an example of overriding <code>QueryCache</code> service. The default
+                implementation of this service is provided by <code>MapQueryCacheProvider</code>.
+                But if we want to use <code>EhCacheQueryCache</code> (a Cayenne wrapper for the
+                EhCache framework), we can define it like
+                this:<programlisting language="java">binder.bind(QueryCache.class).to(EhCacheQueryCache.class);</programlisting></para>
+        </section>
+    </section>
+    <section xml:id="noteworthy-runtime-components">
+        <title>Noteworthy Built-in Services</title>
+        <section xml:id="jdbceventlogger">
+            <title>JdbcEventLogger</title>
+            <para><code>org.apache.cayenne.log.JdbcEventLogger</code> is the service that defines
+                logging API for Cayenne internals. It provides facilities for logging queries,
+                commits, transactions, etc. The default implementation is
+                    <code>org.apache.cayenne.log.CommonsJdbcEventLogger</code> that performs logging
+                via commons-logging library. Cayenne library includes another potentially useful
+                logger - <code>org.apache.cayenne.log.FormattedCommonsJdbcEventLogger</code> that
+                produces formatted multiline SQL output that can be easier to read.</para>
+        </section>
+        <section xml:id="datasourcefactory">
+            <title>DataSourceFactory</title>
+        </section>
+        <section xml:id="datachannelfilter">
+            <title>DataChannelFilter</title>
+        </section>
+        <section xml:id="querycache">
+            <title>QueryCache</title>
+        </section>
+        <section xml:id="extendedtypes">
+            <title>ExtendedTypes</title>
+        </section>
+    </section>
 </chapter>



Mime
View raw message