From the definition of StreamBridge there is no implementation for defining a RabbitMQ exchange.
Is there a way to programmatically set the destination (i.e., RabbitMQ exchanage) and not just the binding with StreamBridge?
StreamBridge (SB) is not a general purpose utility class to interact with underlying messaging system (e.g., RabbitMq). It is however a general purpose utility class to interact with the binder which connect messaging system to your application. So yes there is a method in SB to specify which binder should be used to send a message, but that is where it stops.
You can use RabbotTemplate from Spring-AMQP project to have have that level of granularity, but that is out of scope of spring-cloud-stream.
Related
When developing inbound channel adapters, I couldn’t find any place that mentions the differences between AbstractMessageSource and MessageProducerSupport in Spring Integration. I’m asking this question in the context of reactive streams, so I’m actually looking at AbstractReactiveMessageSource, but I guess it doesn’t matter for my question. I also wonder whether MessageProducerSupport supports project reactor and doesn’t have an equivalent to AbstractReactiveMessageSource.
There is some documentation about these types of components: https://docs.spring.io/spring-integration/docs/current/reference/html/overview.html#finding-class-names-for-java-and-dsl-configuration
The inbound message flow side has its own components, which are divided into polling and listening behaviors.
So, the MessageProducerSupport is for those protocols which provide a listening callback for us. So, we can hook up into that, build message and produce it into a channel provided by the MessageProducer. So, it is self-eventing component which really has everything to listen to the source system and produce messages from the callback. This type of channel adapters called event-driven and samples of them are JMS, AMQP, HTTP, IMAP, Kinesis etc.
From here it is wrong to try to compare the MessageProducerSupport with an AbstractMessageSource because the are not relevant. The one you should look into is a SourcePollingChannelAdapter. Exactly this one is that kind of flow beginning endpoint which is similar to MessageProducerSupport. With only the problem that it is based on a periodic scheduled task to request for messages in the provided MessageSource. This type of component is for those protocols which don't provide listening callback, e.g. local file system, (S)FTP, JDBC, MongoDb, POP3, S3 etc.
You probable would expect something similar to MessageSource for the MessageProducer level, but there is not that kind of layer because everything single event-driven protocol has its own specifics, therefore we cannot extract some common abstraction like in case of polling protocols.
If your source system provides for you a reactive Publisher, you don't need to look into a SourcePollingChannelAdapter and MessageSource. You just need a MessageProducerSupport and call its subscribeToPublisher(Publisher<? extends Message<?>> publisher) from the start() implementation.
There is no need in the reactive implementation for the polling since Publisher is not pollable by itself it is event-driven. Although it has its own back-pressure specifics which is out of MessageProducerSupport scope.
There is also some explanation in this section of the doc: https://docs.spring.io/spring-integration/docs/current/reference/html/reactive-streams.html#source-polling-channel-adapter. And see a couple next paragraphs.
I want a Java class (jms receiver) which always run in background and check for any message arrive in jms queue.How it can be possible? Please help.
What you want is a JMS MessageListener. Create your JMS client resources (e.g. connection/context, session, etc.) like normal and then invoke setMessageListener on your consumer passing in your implementation of the MessageListener interface. This is pretty basic JMS stuff so you can find more detailed tutorials online.
I want to know the major difference between VM and JMS component of Mule ESB. Can someone help me to know it.
As per Mule documentation, VM transport is for intra-JVM communication between Mule flows. So, that means when you use a VM in your flow, you can communicate between different flows in the application.
A flow containing VM inbound cannot be called externally from external application as thus the flow is equivalent to a private flow used within the application. By default uses in-memory queues.
Please go through the documentation :- https://docs.mulesoft.com/mule-user-guide/v/3.8/vm-transport-reference
On the other hand as per Mule documentation, JMS is an external host, allows communication between different components of a distributed application and JMS transport lets you easily send and receive messages to queues and topics for any message service which implements the JMS specification.
A flow, which has JMS inbound can be called from externally unlike VM. Documentation is here :- https://docs.mulesoft.com/mule-user-guide/v/3.8/jms-transport-reference
Within the application, if you send the control from one flow to another flow we use VM.VM can be used as both inbound and outbound.
Outside the application, for example, A application want to send something to B application(external application) there we use JMS.
I am new to spring integration and was going through the definition of service activator. The definition says that it is used to call a method and wrap the result in the response message. The definition also tells that it is a outbound gateway for invoking the bean method. I am not clear on the second statement. As I understand outbound gateway is to send the request from the application to external application and get the response back into the application. So, if a bean is invoked, it is invoked within the application and hence it should be inbound gateway right. Please let me know where I am wrong.
There are two types of integration - with external systems using various protocols, and with legacy java code using method invocation.
Within that, there are one-way integrations (provided by channel adapters) and two-way integration (request/response, provided by gateways). In each case, the integration can be inbound to the message flow, or outbound from it.
The <int: .../> namespace provides inbound and outbound channel adapters for invoking legacy code from the messaging flow, in the latter case (outbound) the method return type must be null. You could also invoke the same method with a service activator, but the channel adapter is preferred because it's clear it's a one-way integration.
On the inbound side, the messaging gateway (<int:gateway/>) is provided to allow legacy java code interact with the messaging flow ("call" it) without any specific dependencies.
There is no <int:outbound-gateway/> for invoking a method because the service activator provides that functionality.
If you can point us to the documentation that caused the confusion, we can try to improve it; please open a documentation JIRA issue.
I have two java classes that implements Runnable within the same application, let's say A and B classes.
These two classes share a BlockingQueue to pass some data. Class A sends data to class B through BlockingQueue. Then class B takes the data and process it. What I am trying to do is that when some conditions happen in class B as a result of process this data, it sends a messages to class A, and class A prints these messages.
So I was having a look at Spring messaging using Apache ActiveMQ, but it seems a broker must be started in order communication works using "activemq start" command. Is there any possibility to do this without having this broker started?
What is the best option to do this? I would like to do this using Spring framework so can be done using some kind of approach in Spring? Or the only possiblity using spring is through apache activemq?
Take a looks at Spring Integration; components communicate using Messages.
You can use an entirely in-memory configuration or provide persistence via some broker such as ActiveMQ.
The components themselves are not concerned with that; they simply send/receive messages.
Create the Queue in spring and inject it into both Runnables