cayenne-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aadamc...@apache.org
Subject svn commit: r1425991 [3/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
Modified: cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/persistent-objects-objectcontext.xml
URL: http://svn.apache.org/viewvc/cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/persistent-objects-objectcontext.xml?rev=1425991&r1=1425990&r2=1425991&view=diff
==============================================================================
--- cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/persistent-objects-objectcontext.xml (original)
+++ cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/persistent-objects-objectcontext.xml Wed Dec 26 18:55:53 2012
@@ -1,197 +1,197 @@
 <?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="persistent-objects-objectcontext">
-	<title>Persistent Objects and ObjectContext</title>
-	<section xml:id="objectcontext">
-		<title>ObjectContext</title>
-		<para>ObjectContext is an interface that users normally work with to access the database. It
-			provides the API to execute database operations and to manage persistent objects. A
-			context is obtained from the
-			ServerRuntime:<programlisting language="java">ObjectContext context = runtime.getContext();</programlisting></para>
-		<para>The call above creates a new instance of ObjectContext that can access the database via this
-			runtime. ObjectContext is a single "work area" in Cayenne, storing persistent objects.
-			ObjectContext guarantees that for each database row with a unique ID it will contain at
-			most one instance of an object, thus ensuring object graph consistency between multiple
-			selects (a feature called "uniquing"). At the same time different ObjectContexts will
-			have independent copies of objects for each unique database row. This allows users to
-			isolate object changes from one another by using separate ObjectContexts.</para>
-		<para>These properties directly affect the strategies for scoping and sharing (or not
-			sharing) ObjectContexts. Contexts that are only used to fetch objects from the database
-			and whose objects are never modified by the application can be shared between mutliple
-			users (and multiple threads). Contexts that store modified objects should be accessed
-			only by a single user (e.g. a web application user might reuse a context instance
-			between multiple web requests in the same HttpSession, thus carrying uncommitted changes
-			to objects from request to request, until he decides to commit or rollback them). Even
-			for a single user it might make sense to use mutliple ObjectContexts (e.g.
-			request-scoped contexts to allow concurrent requests from the browser that change and
-			commit objects independently).</para>
-		<para>ObjectContext is serializable and does not permanently hold to any of the application
-			resources. So it does not have to be closed. If the context is not used anymore, it
-			should simply be allowed to go out of scope and get garbage collected, just like any
-			other Java object.</para>
-	</section>
-	<section xml:id="persistent-lifecycle">
-		<title>Persistent Object and its Lifecycle</title>
-		<para>Cayenne can persist Java objects that implement <code>org.apache.cayenne.Persistent</code>
-			interface. Generally persistent classes are generated from the model as described above,
-			so users do not have to worry about superclass and property implementation details. </para>
-		<para>Persistent interface provides access to 3 persistence-related properties - objectId,
-			persistenceState and objectContext. All 3 are initialized by Cayenne runtime framework.
-			Application code should not attempt to change them them. However it is allowed to read
-			them, which provides valuable runtime information. E.g. ObjectId can be used for quick
-			equality check of 2 objects, knowing persistence state would allow highlighting changed
-			objects, etc.</para>
-		<para>Each persistent object belongs to a single ObjectContext, and can be in one of the following
-			persistence states (as defined in <code>org.apache.cayenne.PersistenceState</code>)
-				:<table frame="void">
-				<caption>Persistence States</caption>
-				<col width="16%"/>
-				<col width="84%"/>
-				<tbody>
-					<tr>
-						<td>TRANSIENT</td>
-						<td>The object is not registered with an ObjectContext and will not be
-							persisted.</td>
-					</tr>
-					<tr>
-						<td>NEW</td>
-						<td>The object is freshly registered in an ObjectContext, but has not been
-							saved to the database yet and there is no matching database row.</td>
-					</tr>
-					<tr>
-						<td>COMMITTED</td>
-						<td>The object is registered in an ObjectContext, there is a row in the
-							database corresponding to this object, and the object state corresponds
-							to the last known state of the matching database row.</td>
-					</tr>
-					<tr>
-						<td>MODIFIED</td>
-						<td>The object is registered in an ObjectContext, there is a row in the
-							database corresponding to this object, but the object in-memory state
-							has diverged from the last known state of the matching database
-							row.</td>
-					</tr>
-					<tr>
-						<td>HOLLOW</td>
-						<td>The object is registered in an ObjectContext, there is a row in the
-							database corresponding to this object, but the object state is unknown.
-							Whenever an application tries to access a property of such object,
-							Cayenne attempts reading its values from the database and "inflate" the
-							object, turning it to COMMITED.</td>
-					</tr>
-					<tr>
-						<td>DELETED</td>
-						<td>The object is registered in an ObjectContext and has been marked for
-							deletion in-memory. The corresponding row in the database will get
-							deleted upon ObjectContext commit, and the object state will be turned
-							into TRANSIENT.</td>
-					</tr>
-				</tbody>
-			</table></para>
-	</section>
-	<section xml:id="persistent-operations">
-		<title>ObjectContext Persistence API</title>
-		<para>One of the first things users usually want to do with an ObjectContext is to select
-			some objects from a database. This is done by calling "<emphasis role="italic"
-				>performQuery</emphasis>"
-			method:<programlisting language="java">SelectQuery query = new SelectQuery(Artist.class);
+    version="5.0" xml:id="persistent-objects-objectcontext">
+    <title>Persistent Objects and ObjectContext</title>
+    <section xml:id="objectcontext">
+        <title>ObjectContext</title>
+        <para>ObjectContext is an interface that users normally work with to access the database. It
+            provides the API to execute database operations and to manage persistent objects. A
+            context is obtained from the
+            ServerRuntime:<programlisting language="java">ObjectContext context = runtime.getContext();</programlisting></para>
+        <para>The call above creates a new instance of ObjectContext that can access the database via this
+            runtime. ObjectContext is a single "work area" in Cayenne, storing persistent objects.
+            ObjectContext guarantees that for each database row with a unique ID it will contain at
+            most one instance of an object, thus ensuring object graph consistency between multiple
+            selects (a feature called "uniquing"). At the same time different ObjectContexts will
+            have independent copies of objects for each unique database row. This allows users to
+            isolate object changes from one another by using separate ObjectContexts.</para>
+        <para>These properties directly affect the strategies for scoping and sharing (or not
+            sharing) ObjectContexts. Contexts that are only used to fetch objects from the database
+            and whose objects are never modified by the application can be shared between mutliple
+            users (and multiple threads). Contexts that store modified objects should be accessed
+            only by a single user (e.g. a web application user might reuse a context instance
+            between multiple web requests in the same HttpSession, thus carrying uncommitted changes
+            to objects from request to request, until he decides to commit or rollback them). Even
+            for a single user it might make sense to use mutliple ObjectContexts (e.g.
+            request-scoped contexts to allow concurrent requests from the browser that change and
+            commit objects independently).</para>
+        <para>ObjectContext is serializable and does not permanently hold to any of the application
+            resources. So it does not have to be closed. If the context is not used anymore, it
+            should simply be allowed to go out of scope and get garbage collected, just like any
+            other Java object.</para>
+    </section>
+    <section xml:id="persistent-lifecycle">
+        <title>Persistent Object and its Lifecycle</title>
+        <para>Cayenne can persist Java objects that implement <code>org.apache.cayenne.Persistent</code>
+            interface. Generally persistent classes are generated from the model as described above,
+            so users do not have to worry about superclass and property implementation details. </para>
+        <para>Persistent interface provides access to 3 persistence-related properties - objectId,
+            persistenceState and objectContext. All 3 are initialized by Cayenne runtime framework.
+            Application code should not attempt to change them them. However it is allowed to read
+            them, which provides valuable runtime information. E.g. ObjectId can be used for quick
+            equality check of 2 objects, knowing persistence state would allow highlighting changed
+            objects, etc.</para>
+        <para>Each persistent object belongs to a single ObjectContext, and can be in one of the following
+            persistence states (as defined in <code>org.apache.cayenne.PersistenceState</code>)
+                :<table frame="void">
+                <caption>Persistence States</caption>
+                <col width="16%"/>
+                <col width="84%"/>
+                <tbody>
+                    <tr>
+                        <td>TRANSIENT</td>
+                        <td>The object is not registered with an ObjectContext and will not be
+                            persisted.</td>
+                    </tr>
+                    <tr>
+                        <td>NEW</td>
+                        <td>The object is freshly registered in an ObjectContext, but has not been
+                            saved to the database yet and there is no matching database row.</td>
+                    </tr>
+                    <tr>
+                        <td>COMMITTED</td>
+                        <td>The object is registered in an ObjectContext, there is a row in the
+                            database corresponding to this object, and the object state corresponds
+                            to the last known state of the matching database row.</td>
+                    </tr>
+                    <tr>
+                        <td>MODIFIED</td>
+                        <td>The object is registered in an ObjectContext, there is a row in the
+                            database corresponding to this object, but the object in-memory state
+                            has diverged from the last known state of the matching database
+                            row.</td>
+                    </tr>
+                    <tr>
+                        <td>HOLLOW</td>
+                        <td>The object is registered in an ObjectContext, there is a row in the
+                            database corresponding to this object, but the object state is unknown.
+                            Whenever an application tries to access a property of such object,
+                            Cayenne attempts reading its values from the database and "inflate" the
+                            object, turning it to COMMITED.</td>
+                    </tr>
+                    <tr>
+                        <td>DELETED</td>
+                        <td>The object is registered in an ObjectContext and has been marked for
+                            deletion in-memory. The corresponding row in the database will get
+                            deleted upon ObjectContext commit, and the object state will be turned
+                            into TRANSIENT.</td>
+                    </tr>
+                </tbody>
+            </table></para>
+    </section>
+    <section xml:id="persistent-operations">
+        <title>ObjectContext Persistence API</title>
+        <para>One of the first things users usually want to do with an ObjectContext is to select
+            some objects from a database. This is done by calling "<emphasis role="italic"
+                >performQuery</emphasis>"
+            method:<programlisting language="java">SelectQuery query = new SelectQuery(Artist.class);
 List&lt;Artist> artists = context.performQuery(query);</programlisting>We'll
-			discuss queries in some detail in the following chapters. The example above is
-			self-explanatory - we create a SelectQuery that matches all Artist objects present in
-			the database, and then call "performQuery", getting a list of Artist objects.</para>
-		<para>Some queries can be quite complex, returning multiple result sets or even updating the
-			database. For such queries ObjectContext provides "<emphasis role="italic"
-				>performGenericQuery</emphasis>"method. While not nearly as commonly-used as
-			"performQuery", it is nevertheless important in some situations.
-			E.g.:<programlisting language="java">Collection&lt;Query> queries = ... // multiple queries that need to be run together
+            discuss queries in some detail in the following chapters. The example above is
+            self-explanatory - we create a SelectQuery that matches all Artist objects present in
+            the database, and then call "performQuery", getting a list of Artist objects.</para>
+        <para>Some queries can be quite complex, returning multiple result sets or even updating the
+            database. For such queries ObjectContext provides "<emphasis role="italic"
+                >performGenericQuery</emphasis>"method. While not nearly as commonly-used as
+            "performQuery", it is nevertheless important in some situations.
+            E.g.:<programlisting language="java">Collection&lt;Query> queries = ... // multiple queries that need to be run together
 QueryChain query = new QueryChain(queries);
 
 QueryResponse response = context.performGenericQuery(query);</programlisting></para>
-		<para>An application might modify selected objects. E.g.:</para>
-		<programlisting language="java">Artist selectedArtist = artists.get(0);
+        <para>An application might modify selected objects. E.g.:</para>
+        <programlisting language="java">Artist selectedArtist = artists.get(0);
 selectedArtist.setName("Dali");</programlisting>
-		<para>The first time the object property is changed, the object's state is automatically set
-			to "MODIFIED" by Cayenne. Cayenne tracks all in-memory changes until a user calls
-				"<emphasis role="italic"
-			>commitChanges</emphasis>":<programlisting language="java">context.commitChanges();</programlisting>At
-			this point all in-memory changes are analyzed and a minimal set of SQL statements is
-			issued in a single transaction to synchronize the database with the in-memory state. In
-			our example "commitChanges" commits just one object, but generally it can be any number
-			of objects. </para>
-		<para>If instead of commit, we wanted to reset all changed objects to the previously
-			committed state, we'd call <emphasis>rollbackChanges</emphasis>
-			instead:<programlisting language="java">context.rollbackChanges();</programlisting></para>
-		<para>"<emphasis role="italic">newObject</emphasis>" method call creates a persistent object
-			and sets its state to
-			"NEW":<programlisting language="java">Artist newArtist = context.newObject(Artist.class);
+        <para>The first time the object property is changed, the object's state is automatically set
+            to "MODIFIED" by Cayenne. Cayenne tracks all in-memory changes until a user calls
+                "<emphasis role="italic"
+            >commitChanges</emphasis>":<programlisting language="java">context.commitChanges();</programlisting>At
+            this point all in-memory changes are analyzed and a minimal set of SQL statements is
+            issued in a single transaction to synchronize the database with the in-memory state. In
+            our example "commitChanges" commits just one object, but generally it can be any number
+            of objects. </para>
+        <para>If instead of commit, we wanted to reset all changed objects to the previously
+            committed state, we'd call <emphasis>rollbackChanges</emphasis>
+            instead:<programlisting language="java">context.rollbackChanges();</programlisting></para>
+        <para>"<emphasis role="italic">newObject</emphasis>" method call creates a persistent object
+            and sets its state to
+            "NEW":<programlisting language="java">Artist newArtist = context.newObject(Artist.class);
 newArtist.setName("Picasso");</programlisting></para>
-		<para>It will only exist in memory until "commitChanges" is issued. On commit Cayenne might
-			generate a new primary key (unless a user set it explicitly, or a PK was inferred from a
-			relationship) and issue an INSERT SQL statement to permanently store the object.</para>
-		<para><emphasis>deleteObjects</emphasis> method takes one or more Persistent objects and
-			marks them as
-			"DELETED":<programlisting language="java">context.deleteObjects(artist1);
+        <para>It will only exist in memory until "commitChanges" is issued. On commit Cayenne might
+            generate a new primary key (unless a user set it explicitly, or a PK was inferred from a
+            relationship) and issue an INSERT SQL statement to permanently store the object.</para>
+        <para><emphasis>deleteObjects</emphasis> method takes one or more Persistent objects and
+            marks them as
+            "DELETED":<programlisting language="java">context.deleteObjects(artist1);
 context.deleteObjects(artist2, artist3, artist4);</programlisting>Additionally
-			"deleteObjects" processes all  delete rules modeled for the affected objects. This may
-			result in implicitly deleting or modifying extra related objects. Same as insert and
-			update, delete operations are sent to the database only when "commitChanges" is called.
-			Similarly "rollbackChanges" will undo the effect of "newObject" and
-			"deleteObjects".</para>
-		<para><emphasis>localObject</emphasis> returns a copy of a given persistent object that is
-			"local" to a given ObjectContext:</para>
-		<para>Since an application often works with more than one context, "localObject" is a rather
-			common operation. E.g. to improve performance a user might utilize a single shared
-			context to select and cache data, and then occasionally transfer some selected objects
-			to another context to modify and commit
-			them:<programlisting language="java">ObjectContext editingContext = runtime.getContext();
+            "deleteObjects" processes all  delete rules modeled for the affected objects. This may
+            result in implicitly deleting or modifying extra related objects. Same as insert and
+            update, delete operations are sent to the database only when "commitChanges" is called.
+            Similarly "rollbackChanges" will undo the effect of "newObject" and
+            "deleteObjects".</para>
+        <para><emphasis>localObject</emphasis> returns a copy of a given persistent object that is
+            "local" to a given ObjectContext:</para>
+        <para>Since an application often works with more than one context, "localObject" is a rather
+            common operation. E.g. to improve performance a user might utilize a single shared
+            context to select and cache data, and then occasionally transfer some selected objects
+            to another context to modify and commit
+            them:<programlisting language="java">ObjectContext editingContext = runtime.getContext();
 Artist localArtist = editingContext.localObject(artist);</programlisting></para>
-		<para>Often an appliction needs to inspect mapping metadata. This information is stored in
-			the EntityResolver object, accessible via the
-			ObjectContext:<programlisting language="java">EntityResolver resolver = objectContext.getEntityResolver();</programlisting></para>
-		<para>Here we discussed the most commonly used subset of the ObjectContext API. There are
-			other useful methods, e.g. those allowing to inspect registered objects state en bulk,
-			etc. Check the latest JavaDocs for details.</para>
-	</section>
-	<section xml:id="cayenne-helper-class">
-		<title>Cayenne Helper Class</title>
-		<para>There is a useful helper class called "Cayenne" (fully-qualified name
-				<code>"org.apache.cayenne.Cayenne"</code>) that builds on ObjectContext API to
-			provide a number of very common operations. E.g. get a primary key (most entities do not
-			model PK as an object property)
-			:<programlisting language="java">long pk = Cayenne.longPKForObject(artist);</programlisting></para>
-		<para>It also provides the reverse operation - finding an object given a known
-			PK:<programlisting language="java">Artist artist = Cayenne.objectForPK(context, Artist.class, 34579);</programlisting></para>
-		<para>If a query is expected to return 0 or 1 object, Cayenne helper class can be used to find
-			this object. It throws an exception if more than one object matched the
-			query:<programlisting language="java">Artist artist = (Artist) Cayenne.objectForQuery(context, new SelectQuery(Artist.class));</programlisting></para>
-		<para>Feel free to explore Cayenne class API for other useful methods.</para>
-	</section>
-	<section xml:id="objectcontext-nesting">
-		<title>ObjectContext Nesting</title>
-		<para>In all the examples shown so far an ObjectContext would directly connect to a database
-			to select data or synchronize its state (either via commit or rollback). However another
-			context can be used in all these scenarios instead of a database. This concept is called
-			ObjectContext "nesting". Nesting is a parent/child relationship between two contexts,
-			where child is a nested context and selects or commits its objects via a parent. </para>
-		<para>Nesting is useful to create isolated object editing areas (child contexts) that need
-			to all be committed to an intermediate in-memory store (parent context), or rolled back
-			without affecting changes already recorded in the parent. Think cascading GUI dialogs,
-			or parallel AJAX requests coming to the same session.</para>
-		<para>In theory Cayenne supports any number of nesting levels, however applications should
-			generally stay with one or two, as deep hierarchies will most certainly degrade the
-			performance of the deeply nested child contexts. This is due to the fact that each
-			context in a nesting chain has to update its own objects during most operations. </para>
-		<para>Cayenne ROP is an extreme case of nesting when a child context is located in a
-			separate JVM and communicates with its parent via a web service. ROP is discussed in
-			details in the following chapters. Here we concentrate on the same-VM nesting.</para>
-		<para>To create a nested context, use an instance of ServerRuntime, passing it the desired
-			parent:<programlisting language="java">ObjectContext parent = runtime.getContext();
+        <para>Often an appliction needs to inspect mapping metadata. This information is stored in
+            the EntityResolver object, accessible via the
+            ObjectContext:<programlisting language="java">EntityResolver resolver = objectContext.getEntityResolver();</programlisting></para>
+        <para>Here we discussed the most commonly used subset of the ObjectContext API. There are
+            other useful methods, e.g. those allowing to inspect registered objects state en bulk,
+            etc. Check the latest JavaDocs for details.</para>
+    </section>
+    <section xml:id="cayenne-helper-class">
+        <title>Cayenne Helper Class</title>
+        <para>There is a useful helper class called "Cayenne" (fully-qualified name
+                <code>"org.apache.cayenne.Cayenne"</code>) that builds on ObjectContext API to
+            provide a number of very common operations. E.g. get a primary key (most entities do not
+            model PK as an object property)
+            :<programlisting language="java">long pk = Cayenne.longPKForObject(artist);</programlisting></para>
+        <para>It also provides the reverse operation - finding an object given a known
+            PK:<programlisting language="java">Artist artist = Cayenne.objectForPK(context, Artist.class, 34579);</programlisting></para>
+        <para>If a query is expected to return 0 or 1 object, Cayenne helper class can be used to find
+            this object. It throws an exception if more than one object matched the
+            query:<programlisting language="java">Artist artist = (Artist) Cayenne.objectForQuery(context, new SelectQuery(Artist.class));</programlisting></para>
+        <para>Feel free to explore Cayenne class API for other useful methods.</para>
+    </section>
+    <section xml:id="objectcontext-nesting">
+        <title>ObjectContext Nesting</title>
+        <para>In all the examples shown so far an ObjectContext would directly connect to a database
+            to select data or synchronize its state (either via commit or rollback). However another
+            context can be used in all these scenarios instead of a database. This concept is called
+            ObjectContext "nesting". Nesting is a parent/child relationship between two contexts,
+            where child is a nested context and selects or commits its objects via a parent. </para>
+        <para>Nesting is useful to create isolated object editing areas (child contexts) that need
+            to all be committed to an intermediate in-memory store (parent context), or rolled back
+            without affecting changes already recorded in the parent. Think cascading GUI dialogs,
+            or parallel AJAX requests coming to the same session.</para>
+        <para>In theory Cayenne supports any number of nesting levels, however applications should
+            generally stay with one or two, as deep hierarchies will most certainly degrade the
+            performance of the deeply nested child contexts. This is due to the fact that each
+            context in a nesting chain has to update its own objects during most operations. </para>
+        <para>Cayenne ROP is an extreme case of nesting when a child context is located in a
+            separate JVM and communicates with its parent via a web service. ROP is discussed in
+            details in the following chapters. Here we concentrate on the same-VM nesting.</para>
+        <para>To create a nested context, use an instance of ServerRuntime, passing it the desired
+            parent:<programlisting language="java">ObjectContext parent = runtime.getContext();
 ObjectContext nested = runtime.getContext((DataChannel) parent);</programlisting>From
-			here a nested context operates just like a regular context (you can perform queries,
-			create and delete objects, etc.). The only difference is that commit and rollback
-			operations can either be limited to synchronization with the parent, or cascade all the
-			way to the
-			database:<programlisting language="java">// merges nested context changes into the parent context
+            here a nested context operates just like a regular context (you can perform queries,
+            create and delete objects, etc.). The only difference is that commit and rollback
+            operations can either be limited to synchronization with the parent, or cascade all the
+            way to the
+            database:<programlisting language="java">// merges nested context changes into the parent context
 nested.commitChangesToParent();
 
 // regular 'commitChanges' cascades commit through the chain 
@@ -202,58 +202,58 @@ nested.rollbackChangesLocally();
 // regular 'rollbackChanges' cascades rollback through the chain of contexts 
 // all the way to the topmost parent
 nested.rollbackChanges();</programlisting></para>
-	</section>
-	<section xml:id="generic-persistent-objects">
-		<title>Generic Persistent Objects</title>
-		<para>As described in the CayenneModeler chapter, Cayenne supports mapping of completely
-			generic classes to specific entities. Although for conveniece most applications should
-			stick with entity-specific class mappings, the generic feature offers some interesting
-			possibilities, such as creating mappings completely on the fly in a running application,
-			etc.</para>
-		<para>Generic objects are first class citizens in Cayenne, and all common persistent
-			operations apply to them as well. There are some pecularities however, described
-			below.</para>
-		<para>When creating a new generic object, either cast your ObjectContext to DataContext
-			(that provides "newObject(String)" API), or provide your object with an explicit
-			ObjectId:<programlisting language="java">DataObject generic = ((DataContext) context).newObject("GenericEntity");</programlisting><programlisting language="java">DataObject generic = new CayenneDataObject();
+    </section>
+    <section xml:id="generic-persistent-objects">
+        <title>Generic Persistent Objects</title>
+        <para>As described in the CayenneModeler chapter, Cayenne supports mapping of completely
+            generic classes to specific entities. Although for conveniece most applications should
+            stick with entity-specific class mappings, the generic feature offers some interesting
+            possibilities, such as creating mappings completely on the fly in a running application,
+            etc.</para>
+        <para>Generic objects are first class citizens in Cayenne, and all common persistent
+            operations apply to them as well. There are some pecularities however, described
+            below.</para>
+        <para>When creating a new generic object, either cast your ObjectContext to DataContext
+            (that provides "newObject(String)" API), or provide your object with an explicit
+            ObjectId:<programlisting language="java">DataObject generic = ((DataContext) context).newObject("GenericEntity");</programlisting><programlisting language="java">DataObject generic = new CayenneDataObject();
 generic.setObjectId(new ObjectId("GenericEntity"));
 context.registerNewObject(generic);</programlisting>SelectQuery
-			for generic object should be created passing entity name String in constructor, instead
-			of a Java
-			class:<programlisting language="java">SelectQuery query = new SelectQuery("GenericEntity");</programlisting>Use
-			DataObject API to access and modify properties of a generic
-			object:<programlisting language="java">String name = (String) generic.readProperty("name");
+            for generic object should be created passing entity name String in constructor, instead
+            of a Java
+            class:<programlisting language="java">SelectQuery query = new SelectQuery("GenericEntity");</programlisting>Use
+            DataObject API to access and modify properties of a generic
+            object:<programlisting language="java">String name = (String) generic.readProperty("name");
 generic.writeProperty("name", "New Name");</programlisting>This
-			is how an application can obtain entity name of a generic
-			object:<programlisting language="java">String entityName = generic.getObjectId().getEntityName();</programlisting></para>
-	</section>
-	<section xml:id="transactions">
-		<title>Transactions</title>
-		<para>Considering how much attention is given to managing transactions in most other ORMs,
-			transactions have been conspicuously absent from the ObjectContext discussion till now.
-			The reason is that transactions are seamless in Cayenne in all but a few special cases.
-			ObjectContext is an in-memory container of objects that is disconnected from the
-			database, except when it needs to run an operation. So it does not care about any
-			surrounding transaction scope. Sure enough all database operations are transactional, so
-			when an application does a commit, all SQL execution is wrapped in a database
-			transaction. But this is done behind the scenes and is rarely a concern to the
-			application code.</para>
-		<para>Two cases where transactions need to be taken into consideration are container-managed
-			and application-managed transactions. </para>
-		<para>If you are using an EJB container (or some other JTA environment), you'll likely need
-			to switch Cayenne runtime into "external transactions mode".  This is either done in the
-			Modeler (check DataDomain > 'Container-Managed Transactions' checkbox), or in the
-			code:<programlisting language="java">runtime.getDataDomain().setUsingExternalTransactions(true);</programlisting>In
-			this case Cayenne assumes that JDBC Connections obtained by runtime whenever that might
-			happen are all coming from a transactional DataSource managed by the container. In this
-			case Cayenne does not attempt to commit or rollback the connections, leaving it up to
-			the container to do that when appropriate.</para>
-		<para>In the second scenario, an application might need to define its own transaction scope
-			that spans more than one Cayenne operation. E.g. two sequential commits that need to be
-			rolled back together in case of failure. This can be done with an explicit thread-bound
-			transaction that surrounds a set of operations. Application is responsible for
-			committing or rolling it
-			back:<programlisting language="java">Transaction tx = runtime.getDataDomain().createTransaction();
+            is how an application can obtain entity name of a generic
+            object:<programlisting language="java">String entityName = generic.getObjectId().getEntityName();</programlisting></para>
+    </section>
+    <section xml:id="transactions">
+        <title>Transactions</title>
+        <para>Considering how much attention is given to managing transactions in most other ORMs,
+            transactions have been conspicuously absent from the ObjectContext discussion till now.
+            The reason is that transactions are seamless in Cayenne in all but a few special cases.
+            ObjectContext is an in-memory container of objects that is disconnected from the
+            database, except when it needs to run an operation. So it does not care about any
+            surrounding transaction scope. Sure enough all database operations are transactional, so
+            when an application does a commit, all SQL execution is wrapped in a database
+            transaction. But this is done behind the scenes and is rarely a concern to the
+            application code.</para>
+        <para>Two cases where transactions need to be taken into consideration are container-managed
+            and application-managed transactions. </para>
+        <para>If you are using an EJB container (or some other JTA environment), you'll likely need
+            to switch Cayenne runtime into "external transactions mode".  This is either done in the
+            Modeler (check DataDomain > 'Container-Managed Transactions' checkbox), or in the
+            code:<programlisting language="java">runtime.getDataDomain().setUsingExternalTransactions(true);</programlisting>In
+            this case Cayenne assumes that JDBC Connections obtained by runtime whenever that might
+            happen are all coming from a transactional DataSource managed by the container. In this
+            case Cayenne does not attempt to commit or rollback the connections, leaving it up to
+            the container to do that when appropriate.</para>
+        <para>In the second scenario, an application might need to define its own transaction scope
+            that spans more than one Cayenne operation. E.g. two sequential commits that need to be
+            rolled back together in case of failure. This can be done with an explicit thread-bound
+            transaction that surrounds a set of operations. Application is responsible for
+            committing or rolling it
+            back:<programlisting language="java">Transaction tx = runtime.getDataDomain().createTransaction();
 Transaction.bindThreadTransaction(tx);
 
 try {
@@ -281,5 +281,5 @@ finally {
         }
     }
 } </programlisting></para>
-	</section>
+    </section>
 </chapter>

Modified: cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/queries.xml
URL: http://svn.apache.org/viewvc/cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/queries.xml?rev=1425991&r1=1425990&r2=1425991&view=diff
==============================================================================
--- cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/queries.xml (original)
+++ cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/queries.xml Wed Dec 26 18:55:53 2012
@@ -1,61 +1,61 @@
 <?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="queries">
-	<title>Queries</title>
-	<para>Queries are Java objects used by the application to communicate with the database. Cayenne
-		knows how to translate queries into SQL statements appropriate for a particular database
-		engine. Most often queries are used to find objects matching certain criteria, but there are
-		other types of queries too. E.g. those allowing to run native SQL, call DB stored
-		procedures, etc. When committing objects, Cayenne itself creates special queries to
-		insert/update/delete rows in the dabase.</para>
-	<para>There is a number of built-in queries in Cayenne, described later in this chapter. Users can
-		also define their own query types to abstract certain DB interactions that for whatever
-		reason can not be adequately described by the built-in set. </para>
-	<para>Queries can be roughly categorized as "object" and "native". Object queries (most notably
-		SelectQuery and EJBQLQuery) are built with abstractions originating in the object model (the
-		"object" side in the "object-relational" divide). E.g. SelectQuery is assembled from a Java
-		class of the objects to fetch, a qualifier expression, orderings, etc. - all of this
-		expressed in terms of the object model.</para>
-	<para>Native queries describe a desired DB operation as SQL code (SQLTemplate query) or a reference
-		to a stored procedure (ProcedureQuery), etc. The results of native queries are usually
-		presented as Lists of Maps, with each map representing a row in the DB. They can potentially
-		be converted to objects, however often it takes a considerable effort to do so. Native
-		queries are also less (if at all) portable across databases than object queries. </para>
-	<section xml:id="selectquery">
-		<title>SelectQuery</title>
-		<para>SelectQuery is the most commonly used query in user applications. It returns a list of
-			persistent objects of a certain type specified in the
-			query:<programlisting language="java">SelectQuery query = new SelectQuery(Artist.class);
+    version="5.0" xml:id="queries">
+    <title>Queries</title>
+    <para>Queries are Java objects used by the application to communicate with the database. Cayenne
+        knows how to translate queries into SQL statements appropriate for a particular database
+        engine. Most often queries are used to find objects matching certain criteria, but there are
+        other types of queries too. E.g. those allowing to run native SQL, call DB stored
+        procedures, etc. When committing objects, Cayenne itself creates special queries to
+        insert/update/delete rows in the dabase.</para>
+    <para>There is a number of built-in queries in Cayenne, described later in this chapter. Users can
+        also define their own query types to abstract certain DB interactions that for whatever
+        reason can not be adequately described by the built-in set. </para>
+    <para>Queries can be roughly categorized as "object" and "native". Object queries (most notably
+        SelectQuery and EJBQLQuery) are built with abstractions originating in the object model (the
+        "object" side in the "object-relational" divide). E.g. SelectQuery is assembled from a Java
+        class of the objects to fetch, a qualifier expression, orderings, etc. - all of this
+        expressed in terms of the object model.</para>
+    <para>Native queries describe a desired DB operation as SQL code (SQLTemplate query) or a reference
+        to a stored procedure (ProcedureQuery), etc. The results of native queries are usually
+        presented as Lists of Maps, with each map representing a row in the DB. They can potentially
+        be converted to objects, however often it takes a considerable effort to do so. Native
+        queries are also less (if at all) portable across databases than object queries. </para>
+    <section xml:id="selectquery">
+        <title>SelectQuery</title>
+        <para>SelectQuery is the most commonly used query in user applications. It returns a list of
+            persistent objects of a certain type specified in the
+            query:<programlisting language="java">SelectQuery query = new SelectQuery(Artist.class);
 List&lt;Artist> objects = context.performQuery(query);</programlisting>This
-			returned all rows in the "ARTIST" table. If the logs were turned on, you might see the
-			following SQL
-			printed:<programlisting>INFO: SELECT t0.DATE_OF_BIRTH, t0.NAME, t0.ID FROM ARTIST t0
+            returned all rows in the "ARTIST" table. If the logs were turned on, you might see the
+            following SQL
+            printed:<programlisting>INFO: SELECT t0.DATE_OF_BIRTH, t0.NAME, t0.ID FROM ARTIST t0
 INFO: === returned 5 row. - took 5 ms.</programlisting></para>
-		<para>This SQL was generated by Cayenne from the SelectQuery above. SelectQuery can use a
-			qualifier to select only the data that you care about. Qualifier is simply an Expression
-			(Expressions where discussed in the previous chapter). If you only want artists whose
-			name begins with 'Pablo', you might use the following qualifier expression:
-			<programlisting language="java">SelectQuery query = new SelectQuery(Artist.class,
+        <para>This SQL was generated by Cayenne from the SelectQuery above. SelectQuery can use a
+            qualifier to select only the data that you care about. Qualifier is simply an Expression
+            (Expressions where discussed in the previous chapter). If you only want artists whose
+            name begins with 'Pablo', you might use the following qualifier expression:
+            <programlisting language="java">SelectQuery query = new SelectQuery(Artist.class,
         ExpressionFactory.likeExp(Artist.NAME_PROPERTY, "Pablo%"));
 List&lt;Artist> objects = context.performQuery(query);</programlisting>The
-			SQL will look different this
-			time:<programlisting>INFO: SELECT t0.DATE_OF_BIRTH, t0.NAME, t0.ID FROM ARTIST t0 WHERE t0.NAME LIKE ? 
+            SQL will look different this
+            time:<programlisting>INFO: SELECT t0.DATE_OF_BIRTH, t0.NAME, t0.ID FROM ARTIST t0 WHERE t0.NAME LIKE ?
 [bind: 1->NAME:'Pablo%']
 INFO: === returned 1 row. - took 6 ms.</programlisting></para>
-	</section>
-	<section xml:id="ejbqlquery">
-		<title>EJBQLQuery</title>
-	</section>
-	<section xml:id="sqltemplate">
-		<title>SQLTemplateQuery</title>
-	</section>
-	<section xml:id="procedurequery">
-		<title>ProcedureQuery</title>
-	</section>
-	<section xml:id="namedquery">
-		<title>NamedQuery</title>
-	</section>
-	<section xml:id="custom-queries">
-		<title>Custom Queries</title>
-	</section>
+    </section>
+    <section xml:id="ejbqlquery">
+        <title>EJBQLQuery</title>
+    </section>
+    <section xml:id="sqltemplate">
+        <title>SQLTemplateQuery</title>
+    </section>
+    <section xml:id="procedurequery">
+        <title>ProcedureQuery</title>
+    </section>
+    <section xml:id="namedquery">
+        <title>NamedQuery</title>
+    </section>
+    <section xml:id="custom-queries">
+        <title>Custom Queries</title>
+    </section>
 </chapter>

Modified: cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/rop-deployment.xml
URL: http://svn.apache.org/viewvc/cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/rop-deployment.xml?rev=1425991&r1=1425990&r2=1425991&view=diff
==============================================================================
--- cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/rop-deployment.xml (original)
+++ cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/rop-deployment.xml Wed Dec 26 18:55:53 2012
@@ -1,32 +1,32 @@
 <?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="rop-deployment">
-	<title>ROP Deployment</title>
-	<section xml:id="deploying-rop-server">
-		<title>Deploying ROP Server</title>
-		
-		<note><para>Recent versions of Tomcat and Jetty containers (e.g. Tomcat 6 and 7, Jetty 8) contain code
-				addressing a security concern related to "session fixation problem" by resetting the
-				existing session ID of any request that requires BASIC authentcaition. If ROP
-				service is protected with declarative security (see the the ROP tutorial and the
-				following chapters on security), this feature prevents the ROP client from attaching
-				to its session, resulting in MissingSessionExceptions. To solve that you will need
-				to either switch to an alternative security mechanism, or disable "session fixation
-				problem" protections of the container. E.g. the later can be achieved in Tomcat 7 by
-				adding the following <emphasis>context.xml</emphasis> file to the webapp's META-INF/
-				directory:
-				<programlisting>&lt;Context>
-	&lt;Valve className="org.apache.catalina.authenticator.BasicAuthenticator" 
-			changeSessionIdOnAuthentication="false" />
+    version="5.0" xml:id="rop-deployment">
+    <title>ROP Deployment</title>
+    <section xml:id="deploying-rop-server">
+        <title>Deploying ROP Server</title>
+
+        <note><para>Recent versions of Tomcat and Jetty containers (e.g. Tomcat 6 and 7, Jetty 8) contain code
+                addressing a security concern related to "session fixation problem" by resetting the
+                existing session ID of any request that requires BASIC authentcaition. If ROP
+                service is protected with declarative security (see the the ROP tutorial and the
+                following chapters on security), this feature prevents the ROP client from attaching
+                to its session, resulting in MissingSessionExceptions. To solve that you will need
+                to either switch to an alternative security mechanism, or disable "session fixation
+                problem" protections of the container. E.g. the later can be achieved in Tomcat 7 by
+                adding the following <emphasis>context.xml</emphasis> file to the webapp's META-INF/
+                directory:
+                <programlisting>&lt;Context>
+    &lt;Valve className="org.apache.catalina.authenticator.BasicAuthenticator"
+            changeSessionIdOnAuthentication="false" />
 &lt;/Context></programlisting>(The
-				&lt;Valve> tag can also be placed within the &lt;Context> in any other locations
-				used by Tomcat to load context configurations)</para></note>
-		
-	</section>
-	<section xml:id="deploying-rop-client">
-		<title>Deploying ROP Client</title>
-	</section>
-	<section xml:id="rop-security">
-		<title>Security</title>
-	</section>
+                &lt;Valve> tag can also be placed within the &lt;Context> in any other locations
+                used by Tomcat to load context configurations)</para></note>
+
+    </section>
+    <section xml:id="deploying-rop-client">
+        <title>Deploying ROP Client</title>
+    </section>
+    <section xml:id="rop-security">
+        <title>Security</title>
+    </section>
 </chapter>

Modified: cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/rop-setup.xml
URL: http://svn.apache.org/viewvc/cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/rop-setup.xml?rev=1425991&r1=1425990&r2=1425991&view=diff
==============================================================================
--- cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/rop-setup.xml (original)
+++ cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/rop-setup.xml Wed Dec 26 18:55:53 2012
@@ -1,11 +1,11 @@
 <?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="rop-setup">
-	<title>ROP Setup</title>
-	<section xml:id="rop-system-requirements">
-		<title>System Requirements</title>
-	</section>
-	<section xml:id="rop-jar-files-dependencies">
-		<title>Jar Files and Dependencies</title>
-	</section>
+    version="5.0" xml:id="rop-setup">
+    <title>ROP Setup</title>
+    <section xml:id="rop-system-requirements">
+        <title>System Requirements</title>
+    </section>
+    <section xml:id="rop-jar-files-dependencies">
+        <title>Jar Files and Dependencies</title>
+    </section>
 </chapter>

Modified: cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/setup.xml
URL: http://svn.apache.org/viewvc/cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/setup.xml?rev=1425991&r1=1425990&r2=1425991&view=diff
==============================================================================
--- cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/setup.xml (original)
+++ cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/setup.xml Wed Dec 26 18:55:53 2012
@@ -1,59 +1,59 @@
 <?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="setup">
-	<title>Setup</title>
-	<section xml:id="system-requirements">
-		<title>System Requirements</title>
-		<para>
-			<itemizedlist>
-				<listitem>
-					<para><emphasis role="italic">Java</emphasis>: Cayenne runtime framework and
-						CayenneModeler GUI tool are written in 100% Java, and run on any
-						Java-compatible platform. Required JDK version is 1.5 or higher. The last
-						version of Cayenne compatible with JDK 1.4 is 1.2.x/2.0.x and JDK 1.3 is 1.1.x</para>
-				</listitem>
-			</itemizedlist>
-			<itemizedlist>
-				<listitem>
-					<para><emphasis role="italic">JDBC Driver:</emphasis> An appropriate DB-specific
-						JDBC driver is needed to access the database. It can be included in the
-						application or used in web container DataSource configuration.</para>
-				</listitem>
-			</itemizedlist>
-			<itemizedlist>
-				<listitem>
-					<para><emphasis role="italic">Third-party Libraries:</emphasis> Cayenne runtime
-						framework has a minimal set of required and a few more optional dependencies
-						on third-party open source packages. See "Including Cayenne in a Project"
-						chapter for details.</para>
-				</listitem>
-			</itemizedlist>
-		</para>
-	</section>
-	<section xml:id="running-cayennemodeler">
-		<title>Running CayenneModeler</title>
-		<para>CayenneModeler GUI tool is intended to work with object relational mapping projects. While
-			you can edit your XML by hand, it is rarely needed, as the Modeler is a pretty advanced
-			tool included in Cayenne distribution. To obtain CayenneModeler, download Cayenne
-			distribution archive from <link xlink:href="http://cayenne.apache.org/download.html"
-				>http://cayenne.apache.org/download.html</link> matching the OS you are using. Of
-			course Java needs to be installed on the machine where you are going to run the
-			Modeler.</para>
-		<para>OS X distribution contains CayenneModeler.app at the root of the distribution disk
-			image.</para>
-		<para>Windows distribution contains CayenneModeler.exe file in the <code>bin</code>
-			directory.</para>
-		<para>Cross-platform distribution (targeting Linux, but as the name implies, compatible with any
-			OS) contains a runnable CayenneModeler.jar in the <code>bin</code> directory. It can be
-			executed either by double-clicking, or if the environment is not configured to execute
-			jars, by running from command-line:</para>
-		<programlisting>java -jar CayenneModeler.jar</programlisting>
-		<para>The Modeler can also be started from Maven. While it may look like an exotic way to start a
-			GUI application, it has its benefits - no need to download Cayenne distribution, the
-			version of the Modeler always matches the version of the framework, the plugin can find
-			mapping files in the project automatically. So is an attractive option to some
-			developers. Maven option requires a declaration in the
-			POM:<programlisting>&lt;build>
+    version="5.0" xml:id="setup">
+    <title>Setup</title>
+    <section xml:id="system-requirements">
+        <title>System Requirements</title>
+        <para>
+            <itemizedlist>
+                <listitem>
+                    <para><emphasis role="italic">Java</emphasis>: Cayenne runtime framework and
+                        CayenneModeler GUI tool are written in 100% Java, and run on any
+                        Java-compatible platform. Required JDK version is 1.5 or higher. The last
+                        version of Cayenne compatible with JDK 1.4 is 1.2.x/2.0.x and JDK 1.3 is 1.1.x</para>
+                </listitem>
+            </itemizedlist>
+            <itemizedlist>
+                <listitem>
+                    <para><emphasis role="italic">JDBC Driver:</emphasis> An appropriate DB-specific
+                        JDBC driver is needed to access the database. It can be included in the
+                        application or used in web container DataSource configuration.</para>
+                </listitem>
+            </itemizedlist>
+            <itemizedlist>
+                <listitem>
+                    <para><emphasis role="italic">Third-party Libraries:</emphasis> Cayenne runtime
+                        framework has a minimal set of required and a few more optional dependencies
+                        on third-party open source packages. See "Including Cayenne in a Project"
+                        chapter for details.</para>
+                </listitem>
+            </itemizedlist>
+        </para>
+    </section>
+    <section xml:id="running-cayennemodeler">
+        <title>Running CayenneModeler</title>
+        <para>CayenneModeler GUI tool is intended to work with object relational mapping projects. While
+            you can edit your XML by hand, it is rarely needed, as the Modeler is a pretty advanced
+            tool included in Cayenne distribution. To obtain CayenneModeler, download Cayenne
+            distribution archive from <link xlink:href="http://cayenne.apache.org/download.html"
+                >http://cayenne.apache.org/download.html</link> matching the OS you are using. Of
+            course Java needs to be installed on the machine where you are going to run the
+            Modeler.</para>
+        <para>OS X distribution contains CayenneModeler.app at the root of the distribution disk
+            image.</para>
+        <para>Windows distribution contains CayenneModeler.exe file in the <code>bin</code>
+            directory.</para>
+        <para>Cross-platform distribution (targeting Linux, but as the name implies, compatible with any
+            OS) contains a runnable CayenneModeler.jar in the <code>bin</code> directory. It can be
+            executed either by double-clicking, or if the environment is not configured to execute
+            jars, by running from command-line:</para>
+        <programlisting>java -jar CayenneModeler.jar</programlisting>
+        <para>The Modeler can also be started from Maven. While it may look like an exotic way to start a
+            GUI application, it has its benefits - no need to download Cayenne distribution, the
+            version of the Modeler always matches the version of the framework, the plugin can find
+            mapping files in the project automatically. So is an attractive option to some
+            developers. Maven option requires a declaration in the
+            POM:<programlisting>&lt;build>
     &lt;plugins>
         &lt;plugin>
             &lt;groupId>org.apache.cayenne.plugins&lt;/groupId>
@@ -62,6 +62,6 @@
         &lt;/plugin>
     &lt;/plugins>
 &lt;/build></programlisting></para>
-		<para>And then can be run as <programlisting>mvn cayenne-modeler:run</programlisting></para>
-	</section>
+        <para>And then can be run as <programlisting>mvn cayenne-modeler:run</programlisting></para>
+    </section>
 </chapter>

Modified: cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/starting-cayenne.xml
URL: http://svn.apache.org/viewvc/cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/starting-cayenne.xml?rev=1425991&r1=1425990&r2=1425991&view=diff
==============================================================================
--- cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/starting-cayenne.xml (original)
+++ cayenne/main/trunk/docs/docbook/cayenne-guide/src/docbkx/starting-cayenne.xml Wed Dec 26 18:55:53 2012
@@ -1,146 +1,146 @@
 <?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="starting-cayenne">
-	<title>Starting Cayenne</title>
-	<section xml:id="starting-serverruntime">
-		<title>Starting and Stopping ServerRuntime</title>
-		<para>In runtime Cayenne is accessed via
-				<code>org.apache.cayenne.configuration.server.ServerRuntime</code>. ServerRuntime is
-			created simply by calling a
-			constructor:<programlisting language="java">ServerRuntime runtime =
-	new ServerRuntime("com/example/cayenne-project.xml");</programlisting></para>
-		<para>The parameter you pass to the constructor is a location of the main project file. Location
-			is a '/'-separated path (same path separator is used on UNIX and Windows) that is
-			resolved relative to the application classpath. The project file can be placed in the
-			root package or in a subpackage (e.g. in the code above it is in "com/example"
-			subpackage).</para>
-		<para>ServerRuntime encapsulates a single Cayenne stack. Most applications will just have one
-			ServerRuntime using it to create as many ObjectContexts as needed, access the Dependency
-			Injection (DI) container and work with other Cayenne features. Internally ServerRuntime
-			is just a thin wrapper around the DI container. Detailed features of the container are
-			discussed in "Customizing Cayenne Runtime" chapter. Here we'll just show an example of
-			how an application might replace a default implementation of a built-in Cayenne service
-			(in this case - QueryCache) with a different
-			class:<programlisting language="java">public class MyExtensionsModule implements Module {
-	public void configure(Binder binder) {
-		binder.bind(QueryCache.class).to(EhCacheQueryCache.class);
-	}	
+    version="5.0" xml:id="starting-cayenne">
+    <title>Starting Cayenne</title>
+    <section xml:id="starting-serverruntime">
+        <title>Starting and Stopping ServerRuntime</title>
+        <para>In runtime Cayenne is accessed via
+                <code>org.apache.cayenne.configuration.server.ServerRuntime</code>. ServerRuntime is
+            created simply by calling a
+            constructor:<programlisting language="java">ServerRuntime runtime =
+    new ServerRuntime("com/example/cayenne-project.xml");</programlisting></para>
+        <para>The parameter you pass to the constructor is a location of the main project file. Location
+            is a '/'-separated path (same path separator is used on UNIX and Windows) that is
+            resolved relative to the application classpath. The project file can be placed in the
+            root package or in a subpackage (e.g. in the code above it is in "com/example"
+            subpackage).</para>
+        <para>ServerRuntime encapsulates a single Cayenne stack. Most applications will just have one
+            ServerRuntime using it to create as many ObjectContexts as needed, access the Dependency
+            Injection (DI) container and work with other Cayenne features. Internally ServerRuntime
+            is just a thin wrapper around the DI container. Detailed features of the container are
+            discussed in "Customizing Cayenne Runtime" chapter. Here we'll just show an example of
+            how an application might replace a default implementation of a built-in Cayenne service
+            (in this case - QueryCache) with a different
+            class:<programlisting language="java">public class MyExtensionsModule implements Module {
+    public void configure(Binder binder) {
+        binder.bind(QueryCache.class).to(EhCacheQueryCache.class);
+    }
 }</programlisting><programlisting language="java">Module extensions = new MyExtensionsModule();
 ServerRuntime runtime = 
-	new ServerRuntime("com/example/cayenne-project.xml", extensions);</programlisting></para>
-		<para>It is a good idea to shut down the runtime when it is no longer needed, usually before the
-			application itself is shutdown: <programlisting language="java">runtime.shutdown();</programlisting>When
-			a runtime object has the same scope as the application, this may not be always
-			necessary, however in some cases it is essential, and is generally considered a good
-			practice. E.g. in a web container hot redeploy of a webapp will cause resource leaks and
-			eventual OutOfMemoryError if the application fails to shutdown CayenneRuntime.</para>
-	</section>
-	<section>
-		<title>Merging Multiple Projects</title>
-		<para>ServerRuntime requires at least one mapping project to run. But it can also take multiple
-			projects and merge them together in a single configuration. This way different parts of
-			a database can be mapped independenlty from each other (even by different software
-			providers), and combined in runtime when assembling an application. Doing it is as easy
-			as passing multiple project locations to ServerRuntime constructor:</para><programlisting language="java">ServerRuntime runtime =
-	new ServerRuntime(new String[] {
-		"com/example/cayenne-project.xml",
-		"org/foo/cayenne-library1.xml",
-		"org/foo/cayenne-library2.xml"
-	}
+    new ServerRuntime("com/example/cayenne-project.xml", extensions);</programlisting></para>
+        <para>It is a good idea to shut down the runtime when it is no longer needed, usually before the
+            application itself is shutdown: <programlisting language="java">runtime.shutdown();</programlisting>When
+            a runtime object has the same scope as the application, this may not be always
+            necessary, however in some cases it is essential, and is generally considered a good
+            practice. E.g. in a web container hot redeploy of a webapp will cause resource leaks and
+            eventual OutOfMemoryError if the application fails to shutdown CayenneRuntime.</para>
+    </section>
+    <section>
+        <title>Merging Multiple Projects</title>
+        <para>ServerRuntime requires at least one mapping project to run. But it can also take multiple
+            projects and merge them together in a single configuration. This way different parts of
+            a database can be mapped independenlty from each other (even by different software
+            providers), and combined in runtime when assembling an application. Doing it is as easy
+            as passing multiple project locations to ServerRuntime constructor:</para><programlisting language="java">ServerRuntime runtime =
+    new ServerRuntime(new String[] {
+        "com/example/cayenne-project.xml",
+        "org/foo/cayenne-library1.xml",
+        "org/foo/cayenne-library2.xml"
+    }
 );</programlisting>
-		<para>When the projects are merged, the following rules are applied:<itemizedlist>
-				<listitem>
-					<para>The order of projects matters during merge. If there are two conflicting
-						metadata objects belonging to two projects, an object from the <emphasis
-							role="italic">last</emphasis> project takes precedence over the object
-						from the first one. This makes possible to override pieces of metadata. This
-						is also similar to how DI modules are merged in Cayenne.</para>
-				</listitem>
-				<listitem>
-					<para>Runtime DataDomain name is set to the name of the last project in the
-						list.</para>
-				</listitem>
-				<listitem>
-					<para>Runtime DataDomain properties are the same as the properties of the last
-						project in the list. I.e. <emphasis role="italic">properties are not
-							merged</emphasis> to avoid invalid combinations and unexpected runtime
-						behavior.</para>
-				</listitem>
-				<listitem>
-					<para>If there are two or more DataMaps with the same name, only one DataMap is
-						used in the merged project, the rest are discarded. Same precedence rules
-						apply - DataMap from the project with the highest index in the project list
-						overrides all other DataMaps with the same name.</para>
-				</listitem>
-				<listitem>
-					<para>If there are two or more DataNodes with the same name, only one DataNodes
-						is used in the merged project, the rest are discarded. DataNode coming from
-						project with the highest index in the project list is chosen per precedence
-						rule above.</para>
-				</listitem>
-				<listitem>
-					<para>There is a notion of "default" DataNode. After the merge if any DataMaps
-						are not explicitly linked to DataNodes, their queries will be executed via a
-						default DataNode. This makes it possible to build mapping "libraries" that
-						are only associated with a specific database in runtime. If there's only one
-						DataNode in the merged project, it will be automatically chosen as default.
-						A possible way to explicitly designate a specific node as default is to
-						override <code>DataDomainProvider.createAndInitDataDomain()</code>.</para>
-				</listitem>
-			</itemizedlist></para>
-	</section>
-	<section xml:id="webapps">
-		<title>Web Applications</title>
-		<para>Web applications can use a variety of mechanisms to configure and start the "services"
-			they need, Cayenne being one of such services. Configuration can be done within standard
-			Servlet specification objects like Servlets, Filters, or ServletContextListeners, or can
-			use Spring, JEE CDI, etc. This is a user's architectural choice and Cayenne is agnostic
-			to it and will happily work in any environment. As described above, all that is needed
-			is to create an instance of ServerRuntime somewhere and provide the application code
-			with means to access it. And shut it down when the application ends to avoid container
-			leaks.</para>
-		<para>Still Cayenne includes a piece of web app configuration code that can assist in
-			quickly setting up simple Cayenne-enabled web applications. We are talking about
-			CayenneFilter. It is declared in
-			web.xml:<programlisting>&lt;web-app>
-	...
-	&lt;filter>           
-		&lt;filter-name>cayenne-project&lt;/filter-name>
-		&lt;filter-class>org.apache.cayenne.configuration.web.CayenneFilter&lt;/filter-class>
+        <para>When the projects are merged, the following rules are applied:<itemizedlist>
+                <listitem>
+                    <para>The order of projects matters during merge. If there are two conflicting
+                        metadata objects belonging to two projects, an object from the <emphasis
+                            role="italic">last</emphasis> project takes precedence over the object
+                        from the first one. This makes possible to override pieces of metadata. This
+                        is also similar to how DI modules are merged in Cayenne.</para>
+                </listitem>
+                <listitem>
+                    <para>Runtime DataDomain name is set to the name of the last project in the
+                        list.</para>
+                </listitem>
+                <listitem>
+                    <para>Runtime DataDomain properties are the same as the properties of the last
+                        project in the list. I.e. <emphasis role="italic">properties are not
+                            merged</emphasis> to avoid invalid combinations and unexpected runtime
+                        behavior.</para>
+                </listitem>
+                <listitem>
+                    <para>If there are two or more DataMaps with the same name, only one DataMap is
+                        used in the merged project, the rest are discarded. Same precedence rules
+                        apply - DataMap from the project with the highest index in the project list
+                        overrides all other DataMaps with the same name.</para>
+                </listitem>
+                <listitem>
+                    <para>If there are two or more DataNodes with the same name, only one DataNodes
+                        is used in the merged project, the rest are discarded. DataNode coming from
+                        project with the highest index in the project list is chosen per precedence
+                        rule above.</para>
+                </listitem>
+                <listitem>
+                    <para>There is a notion of "default" DataNode. After the merge if any DataMaps
+                        are not explicitly linked to DataNodes, their queries will be executed via a
+                        default DataNode. This makes it possible to build mapping "libraries" that
+                        are only associated with a specific database in runtime. If there's only one
+                        DataNode in the merged project, it will be automatically chosen as default.
+                        A possible way to explicitly designate a specific node as default is to
+                        override <code>DataDomainProvider.createAndInitDataDomain()</code>.</para>
+                </listitem>
+            </itemizedlist></para>
+    </section>
+    <section xml:id="webapps">
+        <title>Web Applications</title>
+        <para>Web applications can use a variety of mechanisms to configure and start the "services"
+            they need, Cayenne being one of such services. Configuration can be done within standard
+            Servlet specification objects like Servlets, Filters, or ServletContextListeners, or can
+            use Spring, JEE CDI, etc. This is a user's architectural choice and Cayenne is agnostic
+            to it and will happily work in any environment. As described above, all that is needed
+            is to create an instance of ServerRuntime somewhere and provide the application code
+            with means to access it. And shut it down when the application ends to avoid container
+            leaks.</para>
+        <para>Still Cayenne includes a piece of web app configuration code that can assist in
+            quickly setting up simple Cayenne-enabled web applications. We are talking about
+            CayenneFilter. It is declared in
+            web.xml:<programlisting>&lt;web-app>
+    ...
+    &lt;filter>
+        &lt;filter-name>cayenne-project&lt;/filter-name>
+        &lt;filter-class>org.apache.cayenne.configuration.web.CayenneFilter&lt;/filter-class>
     &lt;/filter>
      &lt;filter-mapping>
         &lt;filter-name>cayenne-project&lt;/filter-name>
         &lt;url-pattern>/*&lt;/url-pattern>
      &lt;/filter-mapping>
-	...
+    ...
  &lt;/web-app>       </programlisting></para>
-		<para>When started by the web container, it creates a instance of ServerRuntime and stores
-			it in the ServletContext. Note that the name of Cayenne XML project file is derived from
-			the "filter-name". In the example above CayenneFilter will look for an XML file
-			"cayenne-project.xml". This can be overridden with "configuration-location" init
-			parameter.</para>
-		<para>When the application runs, all HTTP requests matching the filter url-pattern will have
-			access to a session-scoped ObjectContext like
-			this:<programlisting language="java">ObjectContext context = BaseContext.getThreadObjectContext();</programlisting>Of
-			course the ObjectContext scope, and other behavior of the Cayenne runtime can be
-			customized via dependency injection. For this another filter init parameter called
-			"extra-modules" is used. "extra-modules" is a comma or space-separated list of class
-			names, with each class implementing Module interface. These optional custom modules are
-			loaded after the the standard ones, which allows users to override all standard
-			definitions.</para>
-		<para>For those interested in the DI container contents of the runtime created by CayenneFilter,
-			it is the same ServerRuntime as would've been created by other means, but with an extra
-				<code>org.apache.cayenne.configuration.web.WebModule</code> module that provides
-				<code>org.apache.cayenne.configuration.web.RequestHandler</code> service. This is
-			the service to override in the custom modules if you need to provide a different
-			ObjectContext scope, etc.</para>
-		<para>
-			<note>
-				<para>You should not think of CayenneFilter as the only way to start and use Cayenne in a web
-					application. In fact CayenneFilter is entirely optional. Use it if you don't
-					have any special design for application service management. If you do, simply
-					integrate Cayenne into that design.</para>
-			</note>
-		</para>
-	</section>
+        <para>When started by the web container, it creates a instance of ServerRuntime and stores
+            it in the ServletContext. Note that the name of Cayenne XML project file is derived from
+            the "filter-name". In the example above CayenneFilter will look for an XML file
+            "cayenne-project.xml". This can be overridden with "configuration-location" init
+            parameter.</para>
+        <para>When the application runs, all HTTP requests matching the filter url-pattern will have
+            access to a session-scoped ObjectContext like
+            this:<programlisting language="java">ObjectContext context = BaseContext.getThreadObjectContext();</programlisting>Of
+            course the ObjectContext scope, and other behavior of the Cayenne runtime can be
+            customized via dependency injection. For this another filter init parameter called
+            "extra-modules" is used. "extra-modules" is a comma or space-separated list of class
+            names, with each class implementing Module interface. These optional custom modules are
+            loaded after the the standard ones, which allows users to override all standard
+            definitions.</para>
+        <para>For those interested in the DI container contents of the runtime created by CayenneFilter,
+            it is the same ServerRuntime as would've been created by other means, but with an extra
+                <code>org.apache.cayenne.configuration.web.WebModule</code> module that provides
+                <code>org.apache.cayenne.configuration.web.RequestHandler</code> service. This is
+            the service to override in the custom modules if you need to provide a different
+            ObjectContext scope, etc.</para>
+        <para>
+            <note>
+                <para>You should not think of CayenneFilter as the only way to start and use Cayenne in a web
+                    application. In fact CayenneFilter is entirely optional. Use it if you don't
+                    have any special design for application service management. If you do, simply
+                    integrate Cayenne into that design.</para>
+            </note>
+        </para>
+    </section>
 </chapter>

Modified: cayenne/main/trunk/docs/docbook/getting-started-rop/src/docbkx/authentification.xml
URL: http://svn.apache.org/viewvc/cayenne/main/trunk/docs/docbook/getting-started-rop/src/docbkx/authentification.xml?rev=1425991&r1=1425990&r2=1425991&view=diff
==============================================================================
--- cayenne/main/trunk/docs/docbook/getting-started-rop/src/docbkx/authentification.xml (original)
+++ cayenne/main/trunk/docs/docbook/getting-started-rop/src/docbkx/authentification.xml Wed Dec 26 18:55:53 2012
@@ -26,7 +26,7 @@
     &lt;auth-method&gt;BASIC&lt;/auth-method&gt;
     &lt;realm-name&gt;Cayenne Realm&lt;/realm-name&gt;
 &lt;/login-config&gt;
-	
+
 &lt;security-role&gt;
     &lt;role-name&gt;cayenne-service-user&lt;/role-name&gt;
 &lt;/security-role&gt;</programlisting>
@@ -54,20 +54,20 @@
         <para>Open pom.xml in the server project and configure a "userRealm" for the Jetty
             plugin:</para>
         <programlisting>&lt;plugin&gt;
-	&lt;groupId&gt;org.mortbay.jetty&lt;/groupId&gt;
-		&lt;artifactId&gt;maven-jetty-plugin&lt;/artifactId&gt;
-		&lt;version&gt;6.1.22&lt;/version&gt;
-		&lt;!-- adding configuration below: --&gt;
-		&lt;configuration&gt;
-			&lt;userRealms&gt;
-				&lt;userRealm implementation="org.mortbay.jetty.security.HashUserRealm"&gt;
-					&lt;!-- this name must match the realm-name in web.xml --&gt;
-					&lt;name&gt;Cayenne Realm&lt;/name&gt;
-					&lt;config&gt;realm.properties&lt;/config&gt;
-				&lt;/userRealm&gt;
-			&lt;/userRealms&gt;
-		&lt;/configuration&gt;
-	&lt;/plugin&gt;
+    &lt;groupId&gt;org.mortbay.jetty&lt;/groupId&gt;
+        &lt;artifactId&gt;maven-jetty-plugin&lt;/artifactId&gt;
+        &lt;version&gt;6.1.22&lt;/version&gt;
+        &lt;!-- adding configuration below: --&gt;
+        &lt;configuration&gt;
+            &lt;userRealms&gt;
+                &lt;userRealm implementation="org.mortbay.jetty.security.HashUserRealm"&gt;
+                    &lt;!-- this name must match the realm-name in web.xml --&gt;
+                    &lt;name&gt;Cayenne Realm&lt;/name&gt;
+                    &lt;config&gt;realm.properties&lt;/config&gt;
+                &lt;/userRealm&gt;
+            &lt;/userRealms&gt;
+        &lt;/configuration&gt;
+    &lt;/plugin&gt;
 &lt;/plugins&gt;</programlisting>
         <para>Now create a new file called {["realm.properties"}} <emphasis role="italic">at the
                 root of the server project</emphasis> and put user login/password in there:</para>
@@ -89,30 +89,30 @@ org.apache.cayenne.remote.hessian.Hessia
 INFO: Error establishing remote session. URL - http://localhost:8080/tutorial/cayenne-service; 
       CAUSE - cannot retry due to server authentication, in streaming mode
 java.net.HttpRetryException: cannot retry due to server authentication, in streaming mode
-	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1257)
-	at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
-	at com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:168)
-	at $Proxy0.establishSession(Unknown Source)
-	at org.apache.cayenne.remote.hessian.HessianConnection.connect(HessianConnection.java:210)
-	at org.apache.cayenne.remote.hessian.HessianConnection.getServerEventBridge(HessianConnection.java:114)
-	at org.apache.cayenne.remote.ClientChannel.setupRemoteChannelListener(ClientChannel.java:337)
-	at org.apache.cayenne.remote.ClientChannel.&lt;init>(ClientChannel.java:108)
-	at org.example.cayenne.Main.main(Main.java:25)
+    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1257)
+    at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
+    at com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:168)
+    at $Proxy0.establishSession(Unknown Source)
+    at org.apache.cayenne.remote.hessian.HessianConnection.connect(HessianConnection.java:210)
+    at org.apache.cayenne.remote.hessian.HessianConnection.getServerEventBridge(HessianConnection.java:114)
+    at org.apache.cayenne.remote.ClientChannel.setupRemoteChannelListener(ClientChannel.java:337)
+    at org.apache.cayenne.remote.ClientChannel.&lt;init>(ClientChannel.java:108)
+    at org.example.cayenne.Main.main(Main.java:25)
 Exception in thread "main" org.apache.cayenne.CayenneRuntimeException: [v.3.1M3 Sep 19 2011 07:12:41] 
 Error establishing remote session. URL - http://localhost:8080/tutorial/cayenne-service; 
 CAUSE - cannot retry due to server authentication, in streaming mode
-	at org.apache.cayenne.remote.hessian.HessianConnection.connect(HessianConnection.java:229)
-	at org.apache.cayenne.remote.hessian.HessianConnection.getServerEventBridge(HessianConnection.java:114)
-	at org.apache.cayenne.remote.ClientChannel.setupRemoteChannelListener(ClientChannel.java:337)
-	at org.apache.cayenne.remote.ClientChannel.&lt;init>(ClientChannel.java:108)
-	at org.example.cayenne.Main.main(Main.java:25)
+    at org.apache.cayenne.remote.hessian.HessianConnection.connect(HessianConnection.java:229)
+    at org.apache.cayenne.remote.hessian.HessianConnection.getServerEventBridge(HessianConnection.java:114)
+    at org.apache.cayenne.remote.ClientChannel.setupRemoteChannelListener(ClientChannel.java:337)
+    at org.apache.cayenne.remote.ClientChannel.&lt;init>(ClientChannel.java:108)
+    at org.example.cayenne.Main.main(Main.java:25)
 Caused by: java.net.HttpRetryException: cannot retry due to server authentication, in streaming mode
-	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1257)
-	at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
-	at com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:168)
-	at $Proxy0.establishSession(Unknown Source)
-	at org.apache.cayenne.remote.hessian.HessianConnection.connect(HessianConnection.java:210)
-	... 4 more</programlisting>
+    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1257)
+    at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
+    at com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:168)
+    at $Proxy0.establishSession(Unknown Source)
+    at org.apache.cayenne.remote.hessian.HessianConnection.connect(HessianConnection.java:210)
+    ... 4 more</programlisting>
         <para>Which is exactly what you'd expect, as the client is not authenticating itself. So
             change the line in Main.java where we obtained an ROP connection to this:</para>
         <programlisting language="java">ClientConnection connection = new HessianConnection(

Modified: cayenne/main/trunk/docs/docbook/getting-started-rop/src/docbkx/web-service.xml
URL: http://svn.apache.org/viewvc/cayenne/main/trunk/docs/docbook/getting-started-rop/src/docbkx/web-service.xml?rev=1425991&r1=1425990&r2=1425991&view=diff
==============================================================================
--- cayenne/main/trunk/docs/docbook/getting-started-rop/src/docbkx/web-service.xml (original)
+++ cayenne/main/trunk/docs/docbook/getting-started-rop/src/docbkx/web-service.xml Wed Dec 26 18:55:53 2012
@@ -7,36 +7,36 @@
         <para>Now lets get back to the "tutorial" project that contains a web application and set up
             dependencies. The only extra one that we don't have yet is resin-hessian.jar, just like
             the client, so let's add it (and the caucho repo declaration) to the pom.xml.</para>
-        <programlisting>&lt;project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 	
+        <programlisting>&lt;project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"&gt;
-	...
-	&lt;dependencies&gt;
-		...
-		&lt;dependency&gt;
-			&lt;groupId&gt;com.caucho&lt;/groupId&gt;
-			&lt;artifactId&gt;resin-hessian&lt;/artifactId&gt;
-			&lt;version&gt;3.1.6&lt;/version&gt;
-		&lt;/dependency&gt;
-	&lt;/dependencies&gt;
+    ...
+    &lt;dependencies&gt;
+        ...
+        &lt;dependency&gt;
+            &lt;groupId&gt;com.caucho&lt;/groupId&gt;
+            &lt;artifactId&gt;resin-hessian&lt;/artifactId&gt;
+            &lt;version&gt;3.1.6&lt;/version&gt;
+        &lt;/dependency&gt;
+    &lt;/dependencies&gt;
 
-	&lt;build&gt;
-	...
-	&lt;/build&gt;
-	
-	&lt;repositories&gt;
-		&lt;repository&gt;
-			&lt;id&gt;caucho&lt;/id&gt;
-			&lt;name&gt;Caucho Repository&lt;/name&gt;
-			&lt;url&gt;http://caucho.com/m2&lt;/url&gt;
-			&lt;layout&gt;default&lt;/layout&gt;
-			&lt;snapshots&gt;
-				&lt;enabled&gt;false&lt;/enabled&gt;
-			&lt;/snapshots&gt;
-			&lt;releases&gt;
-				&lt;enabled&gt;true&lt;/enabled&gt;
-			&lt;/releases&gt;
-		&lt;/repository&gt;
-	&lt;/repositories&gt;
+    &lt;build&gt;
+    ...
+    &lt;/build&gt;
+
+    &lt;repositories&gt;
+        &lt;repository&gt;
+            &lt;id&gt;caucho&lt;/id&gt;
+            &lt;name&gt;Caucho Repository&lt;/name&gt;
+            &lt;url&gt;http://caucho.com/m2&lt;/url&gt;
+            &lt;layout&gt;default&lt;/layout&gt;
+            &lt;snapshots&gt;
+                &lt;enabled&gt;false&lt;/enabled&gt;
+            &lt;/snapshots&gt;
+            &lt;releases&gt;
+                &lt;enabled&gt;true&lt;/enabled&gt;
+            &lt;/releases&gt;
+        &lt;/repository&gt;
+    &lt;/repositories&gt;
 &lt;/project&gt;</programlisting>
         <informaltable class="noteMacro" border="1">
             <col width="4%"/>
@@ -77,16 +77,16 @@
    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
    "http://java.sun.com/dtd/web-app_2_3.dtd">
 &lt;web-app>
-	&lt;display-name>Cayenne Tutorial&lt;/display-name>
-	&lt;servlet>
-		&lt;servlet-name>cayenne-project&lt;/servlet-name>
-		&lt;servlet-class>org.apache.cayenne.configuration.rop.server.ROPHessianServlet&lt;/servlet-class>
+    &lt;display-name>Cayenne Tutorial&lt;/display-name>
+    &lt;servlet>
+        &lt;servlet-name>cayenne-project&lt;/servlet-name>
+        &lt;servlet-class>org.apache.cayenne.configuration.rop.server.ROPHessianServlet&lt;/servlet-class>
         &lt;load-on-startup>0&lt;/load-on-startup>
-	&lt;/servlet>
-	&lt;servlet-mapping>
-		&lt;servlet-name>cayenne-project&lt;/servlet-name>
-		&lt;url-pattern>/cayenne-service&lt;/url-pattern>
-	&lt;/servlet-mapping>
+    &lt;/servlet>
+    &lt;servlet-mapping>
+        &lt;servlet-name>cayenne-project&lt;/servlet-name>
+        &lt;url-pattern>/cayenne-service&lt;/url-pattern>
+    &lt;/servlet-mapping>
 &lt;/web-app></programlisting>
         <informaltable class="noteMacro" border="1">
             <col width="4%"/>
@@ -130,9 +130,9 @@ INFO::Started SelectChannelConnector@0.0
 INFO: Loading XML configuration resource from file:cayenne-project.xml
 INFO: loading user name and password.
 INFO: Created connection pool: jdbc:derby:memory:testdb;create=true
-	Driver class: org.apache.derby.jdbc.EmbeddedDriver
-	Min. connections in the pool: 1
-	Max. connections in the pool: 1</programlisting>
+    Driver class: org.apache.derby.jdbc.EmbeddedDriver
+    Min. connections in the pool: 1
+    Max. connections in the pool: 1</programlisting>
         <para>Cayenne ROP service URL is <emphasis role="italic"
                 >http://localhost:8080/tutorial/cayenne-service</emphasis>. If you click on it, you
             will see "Hessian Requires POST" message, that means that the service is alive, but you



Mime
View raw message