From 19a9764cd2b497c40ecf980842120b4521c097df Mon Sep 17 00:00:00 2001 From: Oleg Zhurakousky Date: Thu, 2 Jul 2009 20:40:15 +0000 Subject: [PATCH] INT-676 added documentation around: multipart-file support, long-polling, delete-source-files in FileWritingMessageHandler --- spring-integration-reference/src/endpoint.xml | 17 +++++++++++++++ spring-integration-reference/src/file.xml | 21 +++++++++++++++++++ spring-integration-reference/src/http.xml | 11 ++++++++-- 3 files changed, 47 insertions(+), 2 deletions(-) diff --git a/spring-integration-reference/src/endpoint.xml b/spring-integration-reference/src/endpoint.xml index 036047bbaa..baf5ac52f1 100644 --- a/spring-integration-reference/src/endpoint.xml +++ b/spring-integration-reference/src/endpoint.xml @@ -220,5 +220,22 @@ consumer.setTransactionManager(txManager); provide a reference to any implementation of Spring's TaskExecutor interface by specifying the bean name. The thread pool element is simply provided for convenience. + + You can also use Polling consumers to emulate event-driven semantics. With a long receive-timeout and a short trigger + interval you can effectively approximate event-driven behavior even for a polled message source. + + + A good use case that shows how this approach could be aplied is event-driven files via inbound-channel-adapter where drop of the + file into a directory woudl essentially become an event for that file to be picked up and sent throught the process. + + + + +]]> + Using this approach does not carry much overhead since internally it is nothing more then a timed-wait thread which does not use much of CPU resurces + + + \ No newline at end of file diff --git a/spring-integration-reference/src/file.xml b/spring-integration-reference/src/file.xml index fb4f05f110..54775440ce 100644 --- a/spring-integration-reference/src/file.xml +++ b/spring-integration-reference/src/file.xml @@ -126,6 +126,27 @@ using the namespace. ]]> + + Namespace based configuration also supports delete-source-files attribute which if set to true + will trigger deletion of the original source files after writing to a destination. + The default value for that flag is false + ]]> + + + The delete-source-files attribute will only have an effect if the inbound Message has a File payload or + FileHeaders.ORIGINAL_FILE header value containing either a File instance or a String representing the original file path. + + + + + In cases where you want to continue processing messages based on the written File you can use outbound-gateway which plays a very similar role + as the outbound-channel-adapter. However instead of writing a file It will send it over to the reply channel + ]]> + If you have more elaborate requirements to the payload to file conversion you could extend the FileWritingMessageHandler, but a diff --git a/spring-integration-reference/src/http.xml b/spring-integration-reference/src/http.xml index e092aa71ea..c69140d579 100644 --- a/spring-integration-reference/src/http.xml +++ b/spring-integration-reference/src/http.xml @@ -24,17 +24,21 @@ ]]> The HttpInboundEndpoint accepts an instance of InboundRequestMapper which allows customisation of the mapping from HttpServletRequest to Message. If none is - provided the an instance of DefaultInboundRequestMapper will be used. This encapsulates a simple strategy, which for + provided an instance of DefaultInboundRequestMapper will be used. This encapsulates a simple strategy, which for example will create a String message for a POST request where the content type starts with "text", see the Javadoc for full details. + Starting with this release MultiPart File support was implemented. If the request has been wrapped as a MultipartHttpServletRequest, + then the 'content type' can be checked. If it is known, and begins with "text", then the MultipartFile can be copied to a String in the parameter + map. If the 'content type does not begin with "text", then the MultipartFile can be copied to a byte array within the parameter map instead. + In sending a response to the client there are a number of ways to customise the behaviour of the gateway. By default the gateway will simply acknowledge that the request was received by sending a 200 status code back. It is possible to customise this response by providing an implementation of the Spring MVC View which will be invoked with the created Message. In the case that the gateway should expect a reply to the Message then setting the expectReply flag will cause the gateway to wait for a response Message before creating an Http response. Below is an example of a gateway - configured to use a custom view and to wait for a response. It also shows how to customise the Http methods accepted by the gateway, which + configured to use a custom view and to wait for a response. It also shows how to customise the Http methods accepted by the gateway, which are POST and GET by default. @@ -53,6 +57,9 @@ for that map entry by default is 'requestMessage', but this can be overridden by setting the 'requestKey' property on the endpoint's configuration. + + Starting wit this release +