Code Monkey home page Code Monkey logo

spring-projects / spring-integration Goto Github PK

View Code? Open in Web Editor NEW
1.5K 135.0 1.1K 69.45 MB

Spring Integration provides an extension of the Spring programming model to support the well-known Enterprise Integration Patterns (EIP)

Home Page: http://projects.spring.io/spring-integration/

License: Apache License 2.0

Java 98.48% Groovy 0.45% HTML 0.27% Ruby 0.01% Python 0.01% XSLT 0.01% CSS 0.07% Kotlin 0.70% PLpgSQL 0.01%
spring java eip microservices

spring-integration's Introduction

Spring Integration

Build Status Revved up by Develocity

Extends the Spring programming model to support the well-known Enterprise Integration Patterns. Spring Integration enables lightweight messaging within Spring-based applications and supports integration with external systems via declarative adapters. Those adapters provide a higher-level of abstraction over Spring’s support for remoting, messaging, and scheduling. Spring Integration’s primary goal is to provide a simple model for building enterprise integration solutions while maintaining the separation of concerns that is essential for producing maintainable, testable code.

Using the Spring Framework encourages developers to code using interfaces and use dependency injection (DI) to provide a Plain Old Java Object (POJO) with the dependencies it needs to perform its tasks. Spring Integration takes this concept one step further, where POJOs are wired together using a messaging paradigm and individual components may not be aware of other components in the application. Such an application is built by assembling fine-grained reusable components to form a higher level of functionality. With careful design, these flows can be modularized and also reused at an even higher level.

In addition to wiring together fine-grained components, Spring Integration provides a wide selection of channel adapters and gateways to communicate with external systems. Channel Adapters are used for one-way integration (send or receive); gateways are used for request/reply scenarios (inbound or outbound).

Installation and Getting Started

First, you need dependencies in your POM/Gradle:

<dependency>
    <groupId>org.springframework.integration</groupId>
    <artifactId>spring-integration-core</artifactId>
</dependency>

which is also pulled transitively if you deal with target protocol channel adapters. For example for Apache Kafka support you need just this:

<dependency>
    <groupId>org.springframework.integration</groupId>
    <artifactId>spring-integration-kafka</artifactId>
</dependency>

For annotations or Java DSL configuration you need to enable Spring Integration in the application context:

@EnableIntegration
@Configuration
public class ExampleConfiguration {
    
}

Code of Conduct

Please see our Code of conduct.

Reporting Security Vulnerabilities

Please see our Security policy.

Documentation

The Spring Integration maintains reference documentation (published and source), GitHub wiki pages, and an API reference. There are also guides and tutorials across Spring projects.

Checking out and Building

To check out the project and build from the source, do the following:

git clone git://github.com/spring-projects/spring-integration.git
cd spring-integration
./gradlew clean test

or

./gradlew clean testAll

The latter runs additional tests (those annotated with @LongRunningIntegrationTest); it is a more thorough test but takes quite a lot longer to run.

The test results are captured in build/reports/tests/test (or .../testAll) under each module (in HTML format).

Add --continue to the command to perform a complete build, even if there are failing tests in some modules; otherwise the build will stop after the current module(s) being built are completed.

NOTE: While Spring Integration runs with Java SE 17 or higher, a Java 17 compiler is required to build the project.

To build and install jars into your local Maven cache:

./gradlew build publishToMavenLocal

To build api Javadoc (results will be in build/api):

./gradlew api

To build the reference documentation (results will be in build/site):

./gradlew antora

To build complete distribution including -dist, -docs, and -schema zip files (results will be in build/distributions):

./gradlew dist

Using Eclipse or Spring Tool Suite (with BuildShip Plugin)

If you have the BuildShip plugin installed,

File -> Import -> Gradle -> Existing Gradle Project

Using Eclipse or Spring Tool Suite (when the BuildShip Plugin is not installed)

To generate Eclipse metadata (.classpath and .project files, etc.), do the following:

./gradlew eclipse

Once complete, you may then import the projects into Eclipse as usual:

File -> Import -> General -> Existing projects into workspace

Browse to the 'spring-integration' root directory. All projects should import free of errors.

Using IntelliJ IDEA

To import the project into IntelliJ IDEA:

File -> Open... -> and select build.gradle from spring-integration project root directory

Guidelines

See also Contributor Guidelines.

Resources

For more information, please visit the Spring Integration website at: https://spring.io/projects/spring-integration

spring-integration's People

Contributors

adamasorho avatar amolnayak311 avatar artembilan avatar cbeams avatar dependabot[bot] avatar dsyer avatar dturanski avatar ericbottard avatar garyrussell avatar ghillert avatar gregbragg avatar iwein avatar jpartner avatar liujiong1982 avatar manueljordan avatar markfisher avatar markpollack avatar mbogoevici avatar meteorkor avatar nebhale avatar olegz avatar oxcafedead avatar sobychacko avatar spring-builds avatar spring-integration-extensions-zz avatar spring-operator avatar trgpa avatar tzolov avatar vpavic avatar wilkinsona avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

spring-integration's Issues

Implement MessagePublishingInterceptor [INT-28]

Mark Fisher opened INT-28 and commented

This issue was deferred from the 1.0.x roadmap, because the use of EL will provide a much better experience for mapping arguments, return values, and exceptions to the Message to be published. I am re-opening and assigning to 2.0-M1 now that we depend on Spring 3.0 and have the EL support.

This was the original description back in the early milestones (things will be a bit different now because of EL - see the version in the sandbox for a rough idea):
"The MessagePublishingInterceptor will serve as an AOP-driven messaging gateway - providing a setter for the output channel. It should also allow for configuration of the type of interception (before or after) as well as an optional Message-preparing/payload-extracting strategy. For 'before' interception (e.g. auditing), the MethodInvocation itself would be passed as Message payload, unless a payload extractor is provided. For 'after' interception, the default behavior (when no payload extractor is provided) will depend on the message outcome: if the method returns successfully, the return value will be passed as the Message payload, but if the method throws an exception, the exception will be the payload (of an ErrorMessage). The sending of ErrorMessages should probably be configurable - minimally with a simple enable/disable boolean flag. The default interception type should most likely be 'after'."


Sub-tasks:

  • #4799 Add @Publisher annotation

  • #4815 Add support for non-annotation based binding of an EL expression to Message payload and headers

  • #4820 Add documentation for AOP-based Message publishing interceptor

  • #4823 Create interceptor and AOP advisor for @Publisher annotation

Create pollable JMS source adapter [INT-16]

Mark Fisher opened INT-16 and commented

This JMS source will be a PollableSource implementation that simply uses the JmsTemplate's receiveAndConvert() method. Either a JmsTemplate may be provided explicitly - else a ConnectionFactory+Destination combination in which case the JmsTemplate will be created. This source is intended for low-volume messaging situations - otherwise a truly event-driven JMS source should be used (see #4036).


No further details from INT-16

Define Messaging Mapper interface [INT-14]

Mark Fisher opened INT-14 and commented

The MessageMapper performs a similar role to Spring's MessageConverter for JMS. The main difference is that MessageMapper translates between any object and an instance of the generic Message. The mappers will typically be used by SourceAdapter and TargetAdapter. While each of those only needs conversion in a single direction (object-to-message or message-to-object respectively), MessageMapper implementations should typically provide bi-directional (and symmetric) translation. Therefore the interface could define both methods. The other option would be to provide individual interfaces and then implementation classes may implement both.


No further details from INT-14

Implement Service Activator [INT-18]

Mark Fisher opened INT-18 and commented

The Service Activator is a MessageHandler implementation that invokes a method on a Spring-manged object with the Message payload object as parameter. In most cases, the method to invoke should accept only a single parameter; otherwise, a parameter-builder strategy could be provided.


No further details from INT-18

Implement ApplicationEvent source adapter [INT-29]

Mark Fisher opened INT-29 and commented

The ApplicationEvent source adapter will itself implement Spring's ApplicationListener interface. Any incoming ApplicationEvent will then be passed along as the payload of a message to the specified output channel. It should also allow for a Message-creating/payload-extracting strategy so that a developer may have more fine-grained control of the contents of the message payload (or alternatively, this may be accomplished with a Message Translator).


No further details from INT-29

Provide message source and target interfaces [INT-13]

Mark Fisher opened INT-13 and commented

The MessageSource interface defines the receive methods to be used by any component that supports message reception. The MessageTarget defines the send methods to be implemented by any component that supports message sending. The MessageChannel should be refactored to extend these 2 interfaces.


No further details from INT-13

Allow configurable error handler for MessageEndpoints [INT-19]

Mark Fisher opened INT-19 and commented

The default error handler implementation should be a simple payload-type router that maps exception types to channels. When running within a messaging-aware context, a global error handler can be provided to endpoints by default while still allowing the option of overriding with a local handler on a per-endpoint basis.


No further details from INT-19

Define base MessageEndpoint [INT-15]

Mark Fisher opened INT-15 and commented

The base MessageEndpoint implementation should expose setters for common dependencies: source, target, and handler. The base endpoint class should also implement Spring's Lifecycle interface.


No further details from INT-15

Define FileNameGenerator strategy and default implementation [INT-27]

Mark Fisher opened INT-27 and commented

When writing files, the file target adapter needs to determine the appropriate file name at runtime. A FileNameGenerator interface should define this functionality (e.g. String generateFileName(Message message)). The default implementation could possibly check for a 'filename' property in the message header, else fallback to use the message ID.


No further details from INT-27

Implement event driven consumer [INT-4]

Mark Fisher opened INT-4 and commented

This consumer will receive messages from a channel with a configurable number of concurrent listeners. Each listener should be submitted to an executor (using the task execution abstraction). When a Message is received from the Channel, it should be passed to the provided MessageHandler. The consumer should also handle Message expiration. This class will extend a consumer base class (#4022).


No further details from INT-4

Create file source adapter [INT-25]

Mark Fisher opened INT-25 and commented

The file source adapter will require a polling policy and a source directory to poll for new files. When a file arrives, it will be converted to a Message and sent to the specified output channel. The built-in Messaging Mapper should support a Message payload of either String or byte array.


No further details from INT-25

Implement aggregator [INT-9]

Mark Fisher opened INT-9 and commented

An aggregating message handler will associate incoming messages with a group based on correlation ID. For each incoming message, it will check if a group already exists for that message. If so, the message will be added to that group's aggregator (managed in a map within the aggregating handler - keyed by the correlation id). If not, it will create an "aggregator" and then add the message. Each time a message is added to the aggregator, it will check its "end condition". When the end condition is satisfied, the message group will be aggregated into a single outgoing message.


No further details from INT-9

Implement MessageBus with minimal requirements [INT-34]

Mark Fisher opened INT-34 and commented

The MessageBus will be ApplicationContextAware. It should contain a ChannelRegistry and EndpointRegistry and automatically detect those components within its application context. The MessageBus should also implement lifecycle and enable cascading start/stop to its registered components. The bus should also contain a boolean option 'autoCreateChannels' so that any registered endpoint with a source or target name could trigger creation of a channel (simple point-to-point with default configuration) with that name. Otherwise, the bus will fail on startup. The bus should also provide an 'autoStartup' (default is true) so that initialization also triggers the startup.


No further details from INT-34

Create an event-driven JMS source adapter [INT-41]

Mark Fisher opened INT-41 and commented

The JMS source adapter will encapsulate an instance of DefaultMessageListenerContainer (by default) and a MessageListener that passes the JMS Message payload within a generic Message to the specified output MessageChannel. It should also be possible to provide other versions of the message listener container via setter. Even though a polling dispatcher task will not be required for this source, the task execution should be coordinated by the MessageBus.


No further details from INT-41

Implement resequencer [INT-24]

Mark Fisher opened INT-24 and commented

The resequencer is a stateful handler similar to an aggregator (#4021) where the 'end condition' is achieved when the number of received messages for a given sequence matches the total expected in the sequence (the MessageHeader contains properties: 'sequenceNumber' and 'sequenceTotal'). The key difference is that a resequencer does not aggregate the sequence of messages into a single message. Rather, it simply reorders them before sending to its output channel. The sending should normally occur incrementally - i.e. as soon as the next expected 'lowest' remaining sequence number is encountered. However, the resequencer should also allow for deferred sending until either all messages in the sequence arrive or a configurable timeout period elapses. In the latter case, an error message may be sent - or in some cases, it may be desirable to send only the successfully received messages - in order (e.g. message-1, message-4, message-7) - as soon as the timeout has elapsed.


No further details from INT-24

Implement ApplicationEvent target adapter [INT-30]

Mark Fisher opened INT-30 and commented

The ApplicationEvent target adapter will consume messages from a specified input channel and then publish ApplicationEvents via the designated 'applicationEventPublisher'. The adapter should delegate to an ApplicationEventCreator strategy for converting from the incoming Message to the ApplicationEvent to be published. Perhaps a default MessageEvent should also be defined (extending the abstract ApplicationEvent class) so that the message can simply be wrapped as an event in case no event creator strategy is provided.


No further details from INT-30

Define root exception for messaging and basic implementations [INT-3]

Mark Fisher opened INT-3 and commented

Define a base (runtime) MessagingException as well as implementations for use in case of message-handling and message-delivery failures. Each should provide (at least) 2 constructors: one for a message String + root cause Exception and another for a message String only (when there is no root cause Exception).


No further details from INT-3

Implement splitter [INT-23]

Mark Fisher opened INT-23 and commented

The splitter handler should implement MessageHandler and delegate to a MessageSplitter strategy - such as: List<Message> split(Message message)
The splitter may optionally set the sequenceNumber/sequenceTotal properties to the messages' headers.


No further details from INT-23

Provide namespace support for JmsSourceAdapter [INT-45]

Mark Fisher opened INT-45 and commented

The 'jms-source' element should accept the following attributes: jms-template, connection-factory, destination, destination-name, channel, and poll-period. Channel should be required according to the XSD.

If poll-period is not provided, then a JmsMessageDrivenSourceAdapter is used (instead of JmsPollingSourceAdapter). In that case, the parser should enforce that a 'connection-factory' is available and either a 'destination' or 'destination-name' is provided as well. For the polling adapter, the 'jms-template' reference is sufficient (but providing 'connection-factory' + 'destination' is also an option).


No further details from INT-45

Create JMS target adapter [INT-17]

Mark Fisher opened INT-17 and commented

The adapter will delegate to Spring's JmsTemplate to send the generic Message's payload within a JMS Message to the specified JMS Destination. This will use SimpleMesageConverter by default but should expose a setter for the 'messageConverter' property.


No further details from INT-17

Provide annotation support for message-publishing interceptor [INT-39]

Mark Fisher opened INT-39 and commented

The Publisher annotation will provide a 'channel' attribute and annotated methods would be capable of publishing to the specified channel. The AnnotationAwareMessagePublishingInterceptor will recognize the annotation and resolve the provided channel name to a MessageChannel instance if possible (a ChannelResolver strategy must be provided to it). A PublisherAnnotationPostProcessor should create proxies in its after-init callback using a PublisherAnnotationAdvisor with an AnnotationMatchingPointcut for a configurable method annotation (default is @Publisher). The 'channelNameAttribute' should also be configurable (default is "channel").


No further details from INT-39

Define MessageEndpoint component annotation and method annotations for handler, source, and target [INT-35]

Mark Fisher opened INT-35 and commented

The @MessageEndpoint annotation should contain the @Component meta-annotation to allow for autodetection. The following endpoint attributes should be available: source, target, handler, consumerType. The first three accept Strings (e.g. for channel name or handler bean name) and the consumerType accepts the ConsumerType enum (see #4054).

A @Handler method annotation would trigger creation of a MessageHandler adapter. Such methods can accept either a Message or any Object that will match by payload type by default. A @Router method will return either a String (endpoint then uses the channel resolver) or a MessageChannel instance. The @Source method annotation can return either a Message or an Object to be used as Message payload (by the message factory). A @Target method annotation will be wrapped in a MessageTarget adapter for sending the message payload.


No further details from INT-35

Implement consumer base class [INT-11]

Mark Fisher opened INT-11 and commented

This class will provide the common configuration (channel, handler, executor) for both polling and event-driven consumers. Other common behavior includes lifecycle management, handler invocation, and invalid message handling (including expired messages).


No further details from INT-11

Create file target adapter [INT-26]

Mark Fisher opened INT-26 and commented

The file target adapter will write the contents of an incoming Message payload to a file within a specified directory. This will require a FileNameGenerator strategy (#4044). It should handle either String or byte array payloads.


No further details from INT-26

Implement MulticastDispatcher (and prerequisite refactoring) [INT-47]

Mark Fisher opened INT-47 and commented

Whereas the UnicastDispatcher sends messages to a single endpoint (potentially among multiple subscribers), this dispatcher should send to all subscribed endpoints that accept the message within the specified constraints (timeout, max-retries, etc). This will also involve some core refactoring to accommodate the subscription activation based on common consumer policies. In other words, if 3 endpoints are subscribed to the same channel with a multicast dispatcher, then the consumer policies must match (since they will be sharing the dispatcher and therefore a single message-retriever). Essentially this means that a consumer policy for multicast is 1-per-channel whereas with unicast the policies can be per-endpoint. Also, the current PointToPointChannel implementation might need to be renamed since point-to-point vs. publish/subscribe is actually determined by the dispatcher in use - not the channel itself. It is actually a channel + its (default) consumer policy that determines a point-to-point channel or publish/subscribe channel. An endpoint can override the policy - only in the case that the channel is configured with a unicast dispatcher (a point-to-point-channel). This enables the EIP notion of "competing consumers".


No further details from INT-47

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.