Is there any way to configure JMS outbound channel adapter
<int-jms:outbound-channel-adapter id="jmsOut" destination="outQueue" channel="exampleChannel"/>
by the similar "easy" way, but using only java-based (annotations) configuration?
If no, so what is the simplest way to achieve this point?
Eugene, I've already pointed you out to the Spring Integration Java DSL. It is exactly the best way to simplify Spring Integration from Java-based config.
Since it isn't the first your similar question, please, pay attention to that project, which has a simple fusion with Core SI:
#Bean
public IntegrationFlow jmsOutboundFlow() {
return IntegrationFlows.from("exampleChannel")
.handleWithAdapter(h ->
h.jms(this.jmsConnectionFactory).destination("outQueue"))
.get();
}
Otherwise it may look like this for the raw Java & Annotation configuration:
#Bean
#serviceActivator(inputChannel = "exampleChannel")
public MessageHandler jsmOutboundAdapter() {
JmsTemplate template = new DynamicJmsTemplate();
template.setConnectionFactory(this.jmsConnectionFactory);
JmsSendingMessageHandler handler = new JmsSendingMessageHandler(template);
handler.setDestinationName("outQueue");
return handler;
}
Related
What would be the Spring Integration DSL way of creating the equivalent of
<int:gateway service-interface="MyService" default-request-channel="myService.inputChannel"/>
// where my existing interface looks like
interface MyService { process(Foo foo); }
I've not been able to find a factory in org.springframework.integration.dsl and none of argument lists for IntegrationFlows.from(...) are helping self discovery.
It sort of feels like I'm missing something like a Java protocol adaptor from https://github.com/spring-projects/spring-integration-java-dsl/wiki/Spring-Integration-Java-DSL-Reference#using-protocol-adapters.
// I imagine this is what I can't find
IntegrationFlows.from(Java.gateway(MyService.class)
.channel("myService.inputChannel")
.get();
The only thing I've come across is on an old blog post, but it seems to require annotating the interface with #MessagingGateway and #Gateway, which I'd like to avoid. See https://spring.io/blog/2014/11/25/spring-integration-java-dsl-line-by-line-tutorial
We have done that recently in Spring Integration 5.0. With that you really can do this:
#Bean
public IntegrationFlow controlBusFlow() {
return IntegrationFlows.from(ControlBusGateway.class)
.controlBus()
.get();
}
public interface ControlBusGateway {
void send(String command);
}
See more info in the latest blog post.
Right now you don't have choice unless declare #MessagingGateway on the interface and start the flow from the request channel for that gateway definition.
I see there is still no JPA high-level support in Spring Integration Java DSL
Example Spring integration DSL for JPA Inbound Channel adapter
But how it is possible to configure JPA outbound channel adapter on low level?
E.g. to create Java DSL config like this in XML
<int-jpa:outbound-channel-adapter id="moduleMessagePersister" channel="inputPersisterChannel" persist-mode="MERGE" entity-manager-factory="entityManagerFactory">
<int-jpa:transactional transaction-manager="transactionManager"/>
</int-jpa:outbound-channel-adapter>
I remember as promised a contribution :-).
Re. <int-jpa:outbound-channel-adapter>:
Any such an XML component is a Consumer Endpoint for the particular MessageHandler.
See the latest changes in the Core project to help users to determine what to use for the Java & Annotation configuration. And therefore for Java DSL as well: https://jira.spring.io/browse/INT-3964
So, for this particular element we have:
<xsd:documentation>
Configures a Consumer Endpoint for the
'org.springframework.integration.jpa.outbound.JpaOutboundGatewayFactoryBean' (one-way)
updating a database using the Java Persistence API (JPA).
</xsd:documentation>
Therefore we have to configure something like
#Bean
public FactoryBean<MessageHandler> jpaMessageHandler() {
JpaOutboundGatewayFactoryBean factoryBean = new JpaOutboundGatewayFactoryBean();
...
factoryBean.setProducesReply(false);
return factoryBean;
}
And use it from the DSL:
#Bean
public IntegrationFlow jpaFlow(MessageHandler jpaMessageHandler) {
...
.handle(jpaMessageHandler)
.get();
}
Let me know what should be documented else!
And yes: we definitely should utilize JPA adapters in the next 1.2 Java DSL version...
I am using spring integration for ftp integration. Following is my config
<int:channel id="ftpChannel"/>
<int-ftp:outbound-channel-adapter id="ftpOutbound"
channel="ftpChannel"
remote-directory="/"
session-factory="ftpClientFactory">
<int-ftp:request-handler-advice-chain>
<int:retry-advice />
</int-ftp:request-handler-advice-chain>
</int-ftp:outbound-channel-adapter>
How do I convert this to java based spring configuration?
From one side, please, pay attention that we have already Spring Integration Java DSL project and you can find there the FTP test-cases to figure out how to configure the FTP adapter from Java and DSL perspective.
From other side you should take a look to the Spring Integration Reference Manual, Annotation Configuration chapter to figure out what is #ServiceActivator, #Transformer and others. Your particular case may look like:
#Bean
#ServiceActivator(inputChannel = "ftpChannel", adviceChain = "retryAdvice")
public MessageHandler ftpHandler() {
FileTransferringMessageHandler handler = new FileTransferringMessageHandler(this.ftpClientFactory);
handler.setRemoteDirectoryExpression(new LiteralExpression("/"))
return handler;
}
and so on.
The retryAdvice in my sample is bean name for the RequestHandlerRetryAdvice.
I have the following spring-integration XML config
<ip:tcp-outbound-gateway id="outboundClient"
request-channel="requestChannel"
reply-channel="string2ObjectChannel"
connection-factory="clientConnectionFactory"
request-timeout="10000"
reply-timeout="10000"/>
How can I write the Java config equivalent of the above?
I thought the equivalent would be
#Bean
public TcpOutboundGateway outboundClient() {
TcpOutboundGateway tcpOutboundGateway = new TcpOutboundGateway();
tcpOutboundGateway.setConnectionFactory(clientConnectionFactory());
tcpOutboundGateway.setRequiresReply(true);
tcpOutboundGateway.setReplyChannel(string2ObjectChannel());
tcpOutboundGateway.setRequestTimeout(10000);
tcpOutboundGateway.setSendTimeout(10000);
return tcpOutboundGateway;
}
But I couldn't find a way to set the request channel.
Any help would be appreciated.
Thank you
Your config looks good, but you should know in addition that any Spring Integration Consumer component consists of two main objects: MessageHandler (TcpOutboundGateway in your case) and EventDrivenConsumer for subscriable input-channel or PollingConsumer if input-channel is Pollable.
So, since you already have the first, handling, part you need another consuming. For this purpose Spring Integration suggests to mark your #Bean with endpoint annotations:
#Bean
#ServiceActivator(inputChannel = "requestChannel")
public TcpOutboundGateway outboundClient() {
See more in the Spring Integration Reference Manual.
However to allow such a annotation process (or any other Spring Integration infrastructure) you have to mark your #Configuration with #EnableIntegration.
Also consider to use Spring Integration Java DSL to have more gain from JavaConfig.
For the time being I see no reason to add Redis but all Spring Session examples include it. I want to design with the idea in mind that I might add it later. The thing I want right now is Header Authentication.
How can I enable the Header Authentication without enabling Redis?
(a spring boot single file application as example would be nice)
The MapSessionRepository was created for just that purpose.
This works with version 1.2 and untested, 1.1
#EnableSpringHttpSession
class HttpSessionConfig {
#Bean
MapSessionRepository sessionRepository() {
return new MapSessionRepository();
}
#Bean
HttpSessionStrategy httpSessionStrategy() {
return new HeaderHttpSessionStrategy();
}
}
I think all you need is a filter of type - SessionRepositoryFilter<Session>, which in a Spring Boot application means a #Bean of that type. When you create it you just inject a HeaderHttpSessionStrategy.