INT-3782: Fix PDF Formatting

JIRA; https://jira.spring.io/browse/INT-3782

- downsize some images to fit in PDF margins
- reduce some long FQ Class names
- fix some tables
- add some missing links

src/reference/asciidoc/endpoint-summary.adoc

@@ -66,10 +66,10 @@ To recap, *Inbound Channel Adapters* are used for one-way integration bringing d
 | *Events*
 
 
-| <<applicationevent-inbound>>
+| <<appevent-inbound>>
 
 
-| <<applicationevent-outbound>>
+| <<appevent-outbound>>
 
 
 | N

src/reference/asciidoc/event.adoc

@@ -4,8 +4,8 @@
 Spring Integration provides support for inbound and outbound `ApplicationEvents` as defined by the underlying Spring Framework.
 For more information about Spring's support for events and listeners, refer to the http://static.springsource.org/spring/docs/2.5.x/reference/beans.html#context-functionality-events[Spring Reference Manual].
 
-[[applicationevent-inbound]]
-=== Receiving Spring ApplicationEvents
+[[appevent-inbound]]
+=== Receiving Spring Application Events
 
 To receive events and send them to a channel, simply define an instance of Spring Integration's `ApplicationEventListeningMessageProducer`.
 This class is an implementation of Spring's `ApplicationListener` interface.
@@ -30,8 +30,8 @@ In the above example, all Application Context events that match one of the types
 If a downstream component throws an exception, a MessagingException containing the failed message and exception will be sent to the channel named 'eventErrorChannel'.
 If no "error-channel" is specified and the downstream channels are synchronous, the Exception  will be propagated to the caller.
 
-[[applicationevent-outbound]]
-=== Sending Spring ApplicationEvents
+[[appevent-outbound]]
+=== Sending Spring Application Events
 
 To send Spring `ApplicationEvents`, create an instance of the `ApplicationEventPublishingMessageHandler` and register it within an endpoint.
 This implementation of the `MessageHandler` interface also implements Spring's `ApplicationEventPublisherAware` interface and thus acts as a bridge between Spring Integration Messages and `ApplicationEvents`.

src/reference/asciidoc/ip.adoc

@@ -358,7 +358,7 @@ Beginning with version 3.0, changes to `TcpConnection` s are reported by `TcpCon
 [NOTE]
 =====
 The following is deprecated as of _version 4.2_; use the generic Event Inbound Channel Adapter instead.
-See <<applicationevent-inbound>>.
+See <<appevent-inbound>>.
 
 For convenience, a `<int-ip:tcp-connection-event-inbound-channel-adapter/>` is provided.
 This adapter will receive all `TcpConnectionEvent` s (by default), and send them to its `channel`.
@@ -378,7 +378,7 @@ You can also use this to limit which `TcpConnectionEvent` s you are interested i
 
 In addition, since _version 4.0_ the standard deserializers discussed in <<connection-factories>> now emit `TcpDeserializationExceptionEvent` s when problems are encountered decoding the data stream.
 These events contain the exception, the buffer that was in the process of being built, and an offset into the buffer (if available) at the point the exception occurred.
-Applications can use a normal `ApplicationListener`, or see <<applicationevent-inbound>>, to capture these events, allowing analysis of the problem.
+Applications can use a normal `ApplicationListener`, or see <<appevent-inbound>>, to capture these events, allowing analysis of the problem.
 
 Starting with _versions 4.0.7, 4.1.3_, `TcpConnectionServerExceptionEvent` s are published whenever an unexpected exception occurs on a server socket (such as a `BindException` when the server socket is in use).
 These events have a reference to the connection factory and the cause.
@@ -1058,6 +1058,7 @@ Default 100.
 Only applies if `using-nio` is `true`.
 |===
 
+[[ip-udp-ib-atts]]
 .UDP Inbound Channel Adapter Attributes
 [cols="1,^1,4", options="header"]
 |===
@@ -1338,7 +1339,7 @@ Only applies if the reply-channel might block, such as a bounded QueueChannel th
 [[ip-msg-headers]]
 === IP Message Headers
 The following `MessageHeader` s are used by this module:
-[cols="1,1,4", options="header"]
+[cols="2,2,4", options="header"]
 |===
 | Header Name
 | IpHeaders Constant
@@ -1368,7 +1369,7 @@ The framework includes acknowledgment information in the data packet.
 | CONNECTION_ID
 | A unique identifier for a TCP connection; set by the framework for inbound messages; when sending to a server-side inbound channel adapter, or replying to an inbound gateway, this header is required so the endpoint can determine which connection to send the message to.
 | ip_actualConnectionId
-| ACTUAL_CONNECTION_ID
+| ACTUAL_ CONNECTION_ID
 | For information only - when using a cached or failover client connection factory, contains the actual underlying connection id.
 |===
 

src/reference/asciidoc/jmx.adoc

@@ -361,14 +361,16 @@ Previously, beans of these types were exported as two distinct MBeans:
 1) the metrics MBean (with an objectName such as: `intDomain:type=MessageHandler,name=myRouter,bean=endpoint`).
 This MBean had metrics attributes and metrics/Lifecycle operations.
 
-2) a second MBean (with an objectName such as: `ctxDomain:name=org.springframework.integration.config.RouterFactoryBean#0
-						,type=MethodInvokingRouter`) was exported with the channel mappings attribute and operations.
+2) a second MBean (with an objectName such as:
+`ctxDomain:name=org.springframework.integration.config.RouterFactoryBean#0`
+`,type=MethodInvokingRouter`)
+was exported with the channel mappings attribute and operations.
 
 Now, the attributes and operations are consolidated into a single MBean.
 The objectName will depend on the exporter.
 If exported by the integration MBean exporter, the objectName will be, for example: `intDomain:type=MessageHandler,name=myRouter,bean=endpoint`.
-If exported by another exporter, the objectName will be, for example: `ctxDomain:name=org.springframework.integration.config.RouterFactoryBean#0
-						,type=MethodInvokingRouter`.
+If exported by another exporter, the objectName will be, for example: `ctxDomain:name=org.springframework.integration.config.RouterFactoryBean#0`
+`,type=MethodInvokingRouter`.
 There is no difference between these MBeans (aside from the objectName), except that the statistics will *not* be enabled (the attributes will be 0) by exporters other than the integration exporter; statistics can be enabled at runtime using the JMX operations.
 When exported by the integration MBean exporter, the initial state can be managed as described above.
 

src/reference/asciidoc/mail.adoc

@@ -182,6 +182,7 @@ For example:
 
 In the above example instead of relying on the default `SearchTermStrategy` the `TestSearchTermStrategy` will be used instead
 
+[[imap-peek]]
 [IMPORTANT]
 .Important: IMAP PEEK
 =====

src/reference/asciidoc/message-store.adoc

@@ -68,6 +68,7 @@ The Framework provides these implementations, which can be used as a persistent
 * <<mongodb-priority-channel-message-store>>
 * <<jdbc-message-store-channels>>
 
+[[sms-caution]]
 [WARNING]
 .Caution with SimpleMessageStore
 =====

src/reference/asciidoc/message.adoc

@@ -62,7 +62,7 @@ The following Message headers are pre-defined:
 
 .Pre-defined Message Headers
 
-[cols="2l,2l,6", options="header"]
+[cols="2l,2l,5", options="header"]
 |===
 
 

src/reference/asciidoc/mongodb.adoc

@@ -251,7 +251,7 @@ If you don't have a 'real' transaction, you can use a `org.springframework.integ
 
 IMPORTANT: This does NOT make MongoDB itself transactional, it simply allows the synchronization of actions to be taken before/after success (commit) or after failure (rollback).
 
-Once your poller is transactional all you need to do is set an instance of the `org.springframework.integration.transaction.TransactionSynchronizationFactory` on the `transactional` element.
+Once your poller is transactional all you need to do is set an instance of the `o.s.i.transaction.TransactionSynchronizationFactory` on the `transactional` element.
 `TransactionSynchronizationFactory` will create an instance of the `TransactioinSynchronization`.
 For your convenience, we've exposed a default SpEL-based `TransactionSynchronizationFactory` which allows you to configure SpEL expressions, with their execution being coordinated (synchronized) with a transaction.
 Expressions for before-commit, after-commit, and after-rollback are supported, together with a channel for each where the evaluation result (if any) will be sent.

src/reference/asciidoc/preface.adoc

@@ -63,3 +63,10 @@ NOTE: Please note that the namespace prefix can be freely chosen.
 You may even choose not to use any namespace prefixes at all.
 Therefore, apply the convention that suits your application needs best.
 Be aware, though, that SpringSource Tool Suite™ (STS) uses the same namespace conventions for Spring Integration as used in this reference guide.
+
+
+== Conventions in this Book
+
+In some cases, to aid formatting, when specifying long fully-qualified class names, we shorten
+the package `org.springframework` to `o.s` and `org.springframework.integration` to `o.s.i`, such as with
+`o.s.i.transaction.TransactionSynchronizationFactory`.

src/reference/asciidoc/redis.adoc

@@ -465,7 +465,7 @@ If you don't have a 'real' transaction, you can use a `o.s.i.transaction.PseudoT
 
 IMPORTANT: This does NOT make the Redis activities themselves transactional, it simply allows the synchronization of actions to be taken before/after success (commit) or after failure (rollback).
 
-Once your poller is transactional all you need to do is set an instance of the `org.springframework.integration.transaction.TransactionSynchronizationFactory` on the `transactional` element.
+Once your poller is transactional all you need to do is set an instance of the `o.s.i.transaction.TransactionSynchronizationFactory` on the `transactional` element.
 `TransactionSynchronizationFactory` will create an instance of the `TransactionSynchronization`.
 For your convenience we've exposed a default SpEL-based `TransactionSynchronizationFactory` which allows you to configure SpEL expressions, with their execution being coordinated (synchronized) with a transaction.
 Expressions for before-commit, after-commit, and after-rollback are supported, together with a channel for each where the evaluation result (if any) will be sent.
@@ -585,10 +585,10 @@ If neither of them is provided the `payload` is used as the command argument(s).
 Argument expressions may evaluate to 'null', to support a variable number of arguments.
 
 
-<10> A `boolean` flag to specify if the evaluated Redis command string will be made available as the `#cmd` variable in the expression evaluation context in the `org.springframework.integration.redis.outbound.ExpressionArgumentsStrategy` when `argument-expressions` is configured, otherwise this attribute is ignored.
+<10> A `boolean` flag to specify if the evaluated Redis command string will be made available as the `#cmd` variable in the expression evaluation context in the `o.s.i.redis.outbound.ExpressionArgumentsStrategy` when `argument-expressions` is configured, otherwise this attribute is ignored.
 
 
-<11> Reference to an instance of `org.springframework.integration.redis.outbound.ArgumentsStrategy`.
+<11> Reference to an instance of `o.s.i.redis.outbound.ArgumentsStrategy`.
 Mutually exclusive with `argument-expressions` attribute.
 If neither of them is provided the `payload` is used as the command argument(s).
 

src/reference/asciidoc/router.adoc

@@ -25,7 +25,7 @@ In order to provide a quick overview, all available attributes are listed in the
 
 .Routers Outside of a Chain
 
-[cols="3,1,1,1,1,1,1", options="header"]
+[cols="2,1,1,1,1,1,1", options="header"]
 |===
 
 
@@ -338,7 +338,7 @@ a| image::images/tickmark.png[]
 |===
 
 .Routers Inside of a Chain
-[cols="3,1,1,1,1,1,1", options="header"]
+[cols="2,1,1,1,1,1,1", options="header"]
 |===
 
 

src/reference/asciidoc/spel.adoc

@@ -158,7 +158,7 @@ Instead of configuring the factory bean above, simply add one or more of these c
 With this sample, two custom `PropertyAccessor` s will be injected to the `EvaluationContext` in the order that they are declared.
 
 NOTE: Custom `PropertyAccessor` s declared in a parent context are also made available in any child context(s).
-They are placed at the end of result list (but before the default `org.springframework.context.expression.MapAccessor` and `org.springframework.expression.spel.support.ReflectivePropertyAccessor`).
+They are placed at the end of result list (but before the default `org.springframework.context.expression.MapAccessor` and `o.s.expression.spel.support.ReflectivePropertyAccessor`).
 If a `PropertyAccessor` with the same bean id is declared in a child context(s), it will override the parent accessor.
 Beans declared within a `<spel-property-accessors/>` must have an 'id' attribute.
 The final order of usage is: the accessors in the current context, in the order in which they are declared, followed by any from parent contexts, in order, followed by the `MapAccessor` and finally the `ReflectivePropertyAccessor`.

src/reference/asciidoc/syslog.adoc

@@ -80,7 +80,7 @@ A `UDP` adapter that sends messages to channel `fromSyslog`.
 It also shows the `SmartLifecycle` attributes `auto-startup` and `phase`.
 It has a reference to a custom `org.springframework.integration.syslog.MessageConverter` with id `converter` and an `error-channel`.
 Also notice the `udp-attributes` child element.
-You can set various UDP attributes here, as defined in <<ip-ib-adapter-attributes>>.
+You can set various UDP attributes here, as defined in <<ip-udp-ib-atts>>.
 
 NOTE: When using the `udp-attributes` element, the `port` attribute must be provided there rather than on the `inbound-channel-adapter` element itself.
 

src/reference/asciidoc/transformer.adoc

@@ -326,6 +326,7 @@ NOTE: When using the headers to determine the type, you should *not* provide a `
 In addition to JSON Transformers, Spring Integration provides a built-in _#jsonPath_ SpEL function for use in expressions.
 For more information see <<spel>>.
 
+[[transformer-xpath-spel-function]]
 *#xpath SpEL Function*
 
 Since version _3.0_, Spring Integration also provides a built-in _#xpath_ SpEL function for use in expressions.