Fix AsciiDoctor Conversion Problems
This commit is contained in:
@@ -118,7 +118,7 @@ For further details please see <<ftp-outbound-gateway>> and <<sftp-outbound-gate
|
||||
|
||||
As of version 2.1, we have exposed more flexibility with regards to session management for remote file adapters (e.g., FTP, SFTP etc).
|
||||
|
||||
Specifically, the `cache-sessions` attribute, which is available via the XML namespace support, is now_deprecated_.
|
||||
Specifically, the `cache-sessions` attribute, which is available via the XML namespace support, is now _deprecated_.
|
||||
Alternatively, we added the `sessionCacheSize` and `sessionWaitTimeout` attributes on the `CachingSessionFactory`.
|
||||
|
||||
For further details please see <<ftp-session-caching>> and <<sftp-session-caching>>.
|
||||
|
||||
@@ -767,7 +767,7 @@ It is essentially a variation of the Bridge, but it is encapsulated within a cha
|
||||
Also, unlike the bridge, it basically forks another message flow.
|
||||
Is that flow _synchronous_ or _asynchronous_? The answer simply depends on the type of _Message Channel_ that 'channelB' is.
|
||||
And, now you know that we have: _Direct Channel_, _Pollable Channel_, and _Executor Channel_ as options.
|
||||
The last two do break the thread boundary making communication via such channels_asynchronous_ simply because the dispatching of the message from that channel to its subscribed handlers happens on a different thread than the one used to send the message to that channel.
|
||||
The last two do break the thread boundary making communication via such channels _asynchronous_ simply because the dispatching of the message from that channel to its subscribed handlers happens on a different thread than the one used to send the message to that channel.
|
||||
That is what is going to make your wire-tap flow _sync_ or _async_.
|
||||
It is consistent with other components within the framework (e.g., Message Publisher) and actually brings a level of consistency and simplicity by sparing you from worrying in advance (other than writing thread safe code) whether a particular piece of code should be implemented as _sync_ or _async_.
|
||||
The actual wiring of two pieces of code (component A and component B) via _Message Channel_ is what makes their collaboration _sync_ or _async_.
|
||||
|
||||
@@ -61,7 +61,7 @@ In the first case, the expression will evaluate to `null`; the second will resul
|
||||
Field or property 'delay' cannot be found on object of type 'org.springframework.messaging.MessageHeaders'
|
||||
----
|
||||
|
||||
So, if there is a possibility of the header being omitted, and you want to fall back to the default delay, it is generally more efficient (and recommended) to use the_Indexer_ syntax instead of _dot property accessor_ syntax, because detecting the null is faster than catching an exception.
|
||||
So, if there is a possibility of the header being omitted, and you want to fall back to the default delay, it is generally more efficient (and recommended) to use the _Indexer_ syntax instead of _dot property accessor_ syntax, because detecting the null is faster than catching an exception.
|
||||
=====
|
||||
|
||||
The delayer delegates to an instance of Spring's `TaskScheduler` abstraction.
|
||||
|
||||
@@ -19,7 +19,7 @@ When connecting to one of Spring Integration's subscribable Message Channels, th
|
||||
However, when connecting to a buffering, pollable Message Channel, some component has to schedule and manage the polling thread(s).
|
||||
Spring Integration provides two different endpoint implementations to accommodate these two types of consumers.
|
||||
Therefore, the consumers themselves can simply implement the callback interface.
|
||||
When polling is required, the endpoint acts as a_container_ for the consumer instance.
|
||||
When polling is required, the endpoint acts as a _container_ for the consumer instance.
|
||||
The benefit is similar to that of using a container for hosting Message Driven Beans, but since these consumers are simply Spring-managed Objects running within an ApplicationContext, it more closely resembles Spring's own MessageListener containers.
|
||||
|
||||
[[endpoint-handler]]
|
||||
@@ -437,7 +437,7 @@ Throughout the reference manual, you will also see specific configuration and im
|
||||
In the case of an Object, such a parameter will be mapped to a Message payload or part of the payload or header (when using the Spring Expression Language).
|
||||
However there are times when the type of input parameter of the endpoint method does not match the type of the payload or its part.
|
||||
In this scenario we need to perform type conversion.
|
||||
Spring Integration provides a convenient way for registering type converters (using the Spring 3.x ConversionService) within its own instance of a conversion service bean named_integrationConversionService_.
|
||||
Spring Integration provides a convenient way for registering type converters (using the Spring 3.x ConversionService) within its own instance of a conversion service bean named _integrationConversionService_.
|
||||
That bean is automatically created as soon as the first converter is defined using the Spring Integration infrastructure.
|
||||
To register a Converter all you need is to implement `org.springframework.core.convert.converter.Converter`, `org.springframework.core.convert.converter.GenericConverter` or `org.springframework.core.convert.converter.ConverterFactory`.
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
Message Filters are used to decide whether a Message should be passed along or dropped based on some criteria such as a Message Header value or Message content itself.
|
||||
Therefore, a Message Filter is similar to a router, except that for each Message received from the filter's input channel, that same Message may or may not be sent to the filter's output channel.
|
||||
Unlike the router, it makes no decision regarding_which_ Message Channel to send the Message to but only decides _whether_ to send.
|
||||
Unlike the router, it makes no decision regarding _which_ Message Channel to send the Message to but only decides _whether_ to send.
|
||||
|
||||
NOTE: As you will see momentarily, the Filter also supports a discard channel, so in certain cases it _can_ play the role of a very simple router (or "switch") based on a boolean condition.
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ For more information about Groovy please refer to the Groovy documentation which
|
||||
==== Groovy configuration
|
||||
|
||||
With Spring Integration 2.1, Groovy Support's configuration namespace is an extension of Spring Integration's Scripting Support and shares the core configuration and behavior described in detail in the <<scripting,Scripting Support>> section.
|
||||
Even though Groovy scripts are well supported by generic Scripting Support, Groovy Support provides the_Groovy_ configuration namespace which is backed by the Spring Framework's `org.springframework.scripting.groovy.GroovyScriptFactory` and related components, offering extended capabilities for using Groovy.
|
||||
Even though Groovy scripts are well supported by generic Scripting Support, Groovy Support provides the _Groovy_ configuration namespace which is backed by the Spring Framework's `org.springframework.scripting.groovy.GroovyScriptFactory` and related components, offering extended capabilities for using Groovy.
|
||||
Below are a couple of sample configurations:
|
||||
|
||||
_Filter_
|
||||
|
||||
@@ -675,7 +675,7 @@ The _reply-timeout_ maps to the _sendTimeout_ property of the _org.springframewo
|
||||
More precisely, the property is set on the extended `AbstractReplyProducingMessageHandler` class, which ultimately sets the property on the `MessagingTemplate`.
|
||||
|
||||
The value of the _sendTimeout_ property defaults to "-1" and will be applied to the connected `MessageChannel`.
|
||||
This means, that depending on the implementation, the Message Channel's_send_ method may block indefinitely.
|
||||
This means, that depending on the implementation, the Message Channel's _send_ method may block indefinitely.
|
||||
Furthermore, the _sendTimeout_ property is only used, when the actual MessageChannel implementation has a blocking send (such as 'full' bounded QueueChannel).
|
||||
|
||||
_HTTP Inbound Gateway_
|
||||
|
||||
@@ -688,7 +688,7 @@ _Pool Size_
|
||||
|
||||
The pool size attribute is no longer used; previously, it specified the size of the default thread pool when a task-executor was not specified.
|
||||
It was also used to set the connection backlog on server sockets.
|
||||
The first function is no longer needed (see below); the second function is replaced by the_backlog_ attribute.
|
||||
The first function is no longer needed (see below); the second function is replaced by the _backlog_ attribute.
|
||||
|
||||
Previously, when using a fixed thread pool task executor (which was the default), with NIO, it was possible to get a deadlock and processing would stop.
|
||||
The problem occurred when a buffer was full, a thread reading from the socket was trying to add more data to the buffer, and there were no threads available to make space in the buffer.
|
||||
|
||||
@@ -690,6 +690,6 @@ One provides _Inbound_ and _Outbound Channel Adapters_, and the other provides _
|
||||
They are configured to run with an embedded_http://activemq.apache.org/[ActiveMQ]_ process, but the samples' _https://github.com/SpringSource/spring-integration-samples/blob/master/basic/jms/src/main/resources/META-INF/spring/integration/common.xml[common.xml]__Spring Application Context_ file can easily be modified to support either a different JMS provider or a standalone _ActiveMQ_ process.
|
||||
|
||||
In other words, you can split the configuration, so that the Inbound and Outbound Adapters are running in separate JVMs.
|
||||
If you have_ActiveMQ_ installed, simply modify the _brokerURL_ property within the _common.xml_ file to use _tcp://localhost:61616_ (instead of _vm://localhost_).
|
||||
If you have _ActiveMQ_ installed, simply modify the _brokerURL_ property within the _common.xml_ file to use _tcp://localhost:61616_ (instead of _vm://localhost_).
|
||||
Both of the samples accept input via stdin and then echo back to stdout.
|
||||
Look at the configuration to see how these messages are routed over JMS.
|
||||
|
||||
@@ -77,10 +77,10 @@ That is why the _<context:mbean-export/>_ element is shown above as well.
|
||||
|
||||
When Messages are sent to the channel for this adapter, the Notification is created from the Message content.
|
||||
If the payload is a String it will be passed as the _message_ text for the Notification.
|
||||
Any other payload type will be passed as the_userData_ of the Notification.
|
||||
Any other payload type will be passed as the _userData_ of the Notification.
|
||||
|
||||
JMX Notifications also have a _type_, and it should be a dot-delimited String.
|
||||
There are two ways to provide the_type_.
|
||||
There are two ways to provide the _type_.
|
||||
Precedence will always be given to a Message header value associated with the `JmxHeaders.NOTIFICATION_TYPE` key.
|
||||
On the other hand, you can rely on a fallback _default-notification-type_ attribute provided in the configuration.
|
||||
|
||||
|
||||
@@ -57,7 +57,7 @@ When using a persistence provider, please ensure that the provider is compatible
|
||||
=== Java Implementation
|
||||
|
||||
Each of the provided components will use the `o.s.i.jpa.core.JpaExecutor` class which in turn will use an implementation of the `o.s.i.jpa.core.JpaOperations` interface.
|
||||
`JpaOperations` operates like a typical Data Access Object (DAO) and provides methods such as_find_, _persist_, _executeUpdate_ etc.
|
||||
`JpaOperations` operates like a typical Data Access Object (DAO) and provides methods such as _find_, _persist_, _executeUpdate_ etc.
|
||||
For most use cases the provided default implementation `o.s.i.jpa.core.DefaultJpaOperations` should be sufficient.
|
||||
Nevertheless, you have the option to optionally specify your own implementation in case you require custom behavior.
|
||||
|
||||
@@ -291,7 +291,7 @@ Below is a sample xml snippet that shows a sample usage of _inbound-channel-adap
|
||||
|
||||
----
|
||||
|
||||
<1> The channel over which the _inbound-channel-adapter_ will put the messages with the payload received after executing the provided JPA QL in the_query_ attribute.
|
||||
<1> The channel over which the _inbound-channel-adapter_ will put the messages with the payload received after executing the provided JPA QL in the _query_ attribute.
|
||||
|
||||
|
||||
<2> The `EntityManager` instance that will be used to perform the required JPA operations.
|
||||
@@ -505,7 +505,7 @@ By default the type is assumed to be a `java.lang.String`.
|
||||
|
||||
As seen in the above snippet, it is perfectly valid to use multiple _parameter_ sub elements within an outbound channel adapter tag and derive some parameters using expressions and some with static value.
|
||||
However, care should be taken not to specify the same parameter name multiple times, and, provide one _parameter_ sub element for each named parameter specified in the JPA query.
|
||||
For example, we are specifying two parameters_level_ and _name_ where _level_ attribute is a static value of type `java.lang.Integer`, where as the _name_ attribute is derived from the payload of the message
|
||||
For example, we are specifying two parameters _level_ and _name_ where _level_ attribute is a static value of type `java.lang.Integer`, where as the _name_ attribute is derived from the payload of the message
|
||||
|
||||
NOTE: Though specifying _select_ is valid for JPA QL, it makes no sense as outbound channel adapters will not be returning any result.
|
||||
If you want to select some values, consider using the outbound gateway instead.
|
||||
@@ -769,13 +769,13 @@ _parameter-source-factory_
|
||||
An instance of `o.s.i.jpa.support.parametersource.ParameterSourceFactory` that will be used to get an instance of `o.s.i.jpa.support.parametersource.ParameterSource`.
|
||||
The _ParameterSource_ is used to resolve the values of the parameters provided in the query.
|
||||
The_parameter-source-factory_ attribute is ignored, if operations are performed using a JPA entity.
|
||||
If a_parameter_ sub-element is used, the factory must be of type `ExpressionEvaluatingParameterSourceFactory`, located in package _o.s.i.jpa.support.parametersource_.
|
||||
If a _parameter_ sub-element is used, the factory must be of type `ExpressionEvaluatingParameterSourceFactory`, located in package _o.s.i.jpa.support.parametersource_.
|
||||
_Optional_.
|
||||
|
||||
_use-payload-as-parameter-source_
|
||||
|
||||
If set to _true_, the payload of the Message will be used as a source for providing parameters.
|
||||
If set to_false_, the entire Message will be available as a source for parameters.
|
||||
If set to _false_, the entire Message will be available as a source for parameters.
|
||||
If no JPA Parameters are passed in, this property will default to _true_.
|
||||
This means that using a default `BeanPropertyParameterSourceFactory`, the bean properties of the payload will be used as a source for parameter values for the to-be-executed JPA query.
|
||||
However, if JPA Parameters are passed in, then this property will by default evaluate to _false_.
|
||||
@@ -965,7 +965,7 @@ Since an _Updating Outbound Gateway_ is used, only _update_ and _delete_ JPQL qu
|
||||
|
||||
|
||||
When sending a message with a String payload and containing a header _rollNumber_ with a _long_ value, the last name of the student with the provided roll number is updated to the value provided in the message payload.
|
||||
When using an_UPDATING_ gateway, the return value is _always_ an integer value which denotes the number of records affected by execution of the JPA QL.
|
||||
When using an _UPDATING_ gateway, the return value is _always_ an integer value which denotes the number of records affected by execution of the JPA QL.
|
||||
|
||||
_Retrieving an Entity using JPQL_
|
||||
|
||||
|
||||
@@ -50,7 +50,7 @@ Spring Integration is guided by the following principles:
|
||||
|
||||
From the _vertical_ perspective, a layered architecture facilitates separation of concerns, and interface-based contracts between layers promote loose coupling.
|
||||
Spring-based applications are typically designed this way, and the Spring framework and portfolio provide a strong foundation for following this best practice for the full-stack of an enterprise application.
|
||||
Message-driven architectures add a_horizontal_ perspective, yet these same goals are still relevant.
|
||||
Message-driven architectures add a _horizontal_ perspective, yet these same goals are still relevant.
|
||||
Just as "layered architecture" is an extremely generic and abstract paradigm, messaging systems typically follow the similarly abstract "pipes-and-filters" model.
|
||||
The "filters" represent any component that is capable of producing and/or consuming messages, and the "pipes" transport the messages between filters so that the components themselves remain loosely-coupled.
|
||||
It is important to note that these two high-level paradigms are not mutually exclusive.
|
||||
|
||||
@@ -675,7 +675,7 @@ The following parameters are valid for all routers inside and outside of chains.
|
||||
|
||||
|
||||
This attribute specifies whether sequence number and size headers should be added to each Message.
|
||||
This_optional_ attribute defaults to _false_.
|
||||
This _optional_ attribute defaults to _false_.
|
||||
|
||||
|
||||
|
||||
@@ -698,7 +698,7 @@ NOTE: A Message will only be sent to the `default-output-channel` if `resolution
|
||||
If _true_ this attribute specifies that channel names must always be successfully resolved to channel instances that exist.
|
||||
If set to _true_, a `MessagingException` will be raised, in case the channel cannot be resolved.
|
||||
Setting this attribute to _false_, will cause any unresovable channels to be ignored.
|
||||
This_optional_ attribute will, if not explicitly set, default to _true_.
|
||||
This _optional_ attribute will, if not explicitly set, default to _true_.
|
||||
|
||||
NOTE: A Message will only be sent to the `default-output-channel`, if specified, when `resolution-required` is false and the channel is not resolved.
|
||||
|
||||
|
||||
@@ -40,7 +40,7 @@ $ git clone https://github.com/SpringSource/spring-integration-samples.git
|
||||
|
||||
That is all you need to do in order to clone the entire samples repository into a directory named _spring-integration-samples_ within the working directory where you issued that _git_ command.
|
||||
Since the samples repository is a live repository, you might want to perform periodic _pulls_ (updates) to get new samples, as well as updates to the existing samples.
|
||||
In order to do so issue the following git_PULL_ command:
|
||||
In order to do so issue the following git _pull_ command:
|
||||
|
||||
[source,xml]
|
||||
----
|
||||
|
||||
@@ -144,7 +144,7 @@ For more information regarding xml and xpath see <<xml>>.
|
||||
|
||||
Namespace support is provided for the easy addition of SpEL custom http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/expression/PropertyAccessor.html[`PropertyAccessor`] implementations.
|
||||
You can specify the `<spel-property-accessors/>` component to provide a list of custom `PropertyAccessor` s to the `EvaluationContext` used throughout the framework.
|
||||
Instead of configuring the factory bean above, simply add one or more of these components, and the framework will automatically add the accessors to the default_integrationEvaluationContext_ factory bean:
|
||||
Instead of configuring the factory bean above, simply add one or more of these components, and the framework will automatically add the accessors to the default _integrationEvaluationContext_ factory bean:
|
||||
|
||||
[source,xml]
|
||||
----
|
||||
|
||||
@@ -82,7 +82,7 @@ If you want to send the reply to another channel instead, then provide a 'reply-
|
||||
|
||||
TIP: When invoking a Web Service that returns an empty response after using a String payload for the request Message, _no reply Message will be sent by default_.
|
||||
Therefore you don't need to set a 'reply-channel' or have a REPLY_CHANNEL header in the request Message.
|
||||
If for any reason you actually _do_ want to receive the empty response as a Message, then provide the 'ignore-empty-responses' attribute with a value of _false_ (this only applies for Strings, because using a Source or Document object simply leads to a NULL response and will therefore_never_ generate a reply Message).
|
||||
If for any reason you actually _do_ want to receive the empty response as a Message, then provide the 'ignore-empty-responses' attribute with a value of _false_ (this only applies for Strings, because using a Source or Document object simply leads to a NULL response and will therefore _never_ generate a reply Message).
|
||||
|
||||
To set up an inbound Web Service Gateway, use the "inbound-gateway":
|
||||
[source,xml]
|
||||
|
||||
Reference in New Issue
Block a user