Spring-boot: Support Spring Integration Java DSL

[joshlong]

the Spring Boot Spring Integration starter oddly brings in adapters for stream and file (which, you don't need necessarily and may never use!) but doesn't bring in the Spring Integration Java DSL. This is very confusing.

At a minimum, please also bring in the Java DSL and - in the next major version perhaps - remove the crazy unnecessary Spring Integration Adapters. There are dozens of adapters in Spring Integration and no body knows which particular one they'll need but the can bring all of them by following the pattern org.springframework.integration : spring-integration-$SUPPORTED_TECH : spring-integration.version but the Java DSL doesn't share the same version as the rest of Spring Integration, so it would benefit from being in there and having its own property.

Also, the Spring Integration dependencies fro the Spring Integration project itself are already available unqualified thanks to the Spring Integration BOM. The Java DSL isn't.

[philwebb]

Adding the Java DSL seems like a nice addition but I'm not keen to remove the stream and file adapters since it will make the upgrade to 1.4 more difficult.

We actually chose what we considered to be as sensible subset of technologies to include, namely:

• spring-integration-core
• spring-integration-file
• spring-integration-http
• spring-integration-ip
• spring-integration-stream

Other than the size of the JAR, does including them actually cause any problems?

[joshlong]

id be happy with just including the DSL but i always exclude those dependencies as soon as I import the spring integration starter.

• core makes sense
• file? what about ftp or sftp or ftps?
• http? use Spring MVC and just write to a channel, it's almost always easier
• ip ? :/ hopefully most people are using prewritten protocols (like spring-integration-mqtt or XMPP). instead of rolling their own protocols. If they need to do that I'd imagine they're in the minority.
• reading and writing from stdin/stdout are not the reasons i reach for an enterprise integration technology.

and anyway, it's the symmetry of it all. Libraries that aren't auto-configured just sitting on the CLASSPATH for no particular reason. Even Spring Social has various starters for various optional implementations.

these seem completely arbitrary and mean i have to add an exclude. Some people won't even know they can add an exclude as our messaging has always been that a starter is the opinionated way to get started with a given technology, the minimum for the best experience. obviously i don't care about .jar size. they're just.. confusing.

i'd be happy with just adding the DSL tho and hope we could add the DSL before 1.4. Removing these others might need to wait till 1.4..

[philwebb]

Why do you always exclude them? What problems do they cause?

[snicoll]

ping @joshlong

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[joshlong]

the issue is manifold:

• they're not required. thats the main objection. they're just sitting there, not doing anything, pointlessly. i will call this the 'application server' problem: if we don't need it, we don't need it.
• it wouldn't be such a big problem if the presence of libraries was otherwise harmless, if a bit confusing and.. pointless, but as we know, libraries present on the CLASSPATH _do_ have side-effects in Spring Boot. The Spring Integration HTTP adapter, for example, brings in Spring web(*) and that in turn triggers the HttpMessageConverterAutoConfiguration which is mostly harmless but, still, it's uneccessary.

Here are the positive conditions by just having spring-boot-starter-integration on the CLASSPATH:

   AopAutoConfiguration matched
      - @ConditionalOnClass classes found: org.springframework.context.annotation.EnableAspectJAutoProxy,org.aspectj.lang.annotation.Aspect,org.aspectj.lang.reflect.Advice (OnClassCondition)
      - matched (OnPropertyCondition)

   AopAutoConfiguration.JdkDynamicAutoProxyConfiguration matched
      - matched (OnPropertyCondition)

   GenericCacheConfiguration matched
      - Automatic cache type (CacheCondition)

   HttpMessageConvertersAutoConfiguration matched
      - @ConditionalOnClass classes found: org.springframework.http.converter.HttpMessageConverter (OnClassCondition)

   HttpMessageConvertersAutoConfiguration#messageConverters matched
      - @ConditionalOnMissingBean (types: org.springframework.boot.autoconfigure.web.HttpMessageConverters; SearchStrategy: all) found no beans (OnBeanCondition)

   HttpMessageConvertersAutoConfiguration.StringHttpMessageConverterConfiguration matched
      - @ConditionalOnClass classes found: org.springframework.http.converter.StringHttpMessageConverter (OnClassCondition)

   HttpMessageConvertersAutoConfiguration.StringHttpMessageConverterConfiguration#stringHttpMessageConverter matched
      - @ConditionalOnMissingBean (types: org.springframework.http.converter.StringHttpMessageConverter; SearchStrategy: all) found no beans (OnBeanCondition)

   IntegrationAutoConfiguration matched
      - @ConditionalOnClass classes found: org.springframework.integration.config.EnableIntegration (OnClassCondition)

   JmxAutoConfiguration matched
      - @ConditionalOnClass classes found: org.springframework.jmx.export.MBeanExporter (OnClassCondition)
      - matched (OnPropertyCondition)

   JmxAutoConfiguration#mbeanExporter matched
      - @ConditionalOnMissingBean (types: org.springframework.jmx.export.MBeanExporter; SearchStrategy: current) found no beans (OnBeanCondition)

   JmxAutoConfiguration#mbeanServer matched
      - @ConditionalOnMissingBean (types: javax.management.MBeanServer; SearchStrategy: all) found no beans (OnBeanCondition)

   JmxAutoConfiguration#objectNamingStrategy matched
      - @ConditionalOnMissingBean (types: org.springframework.jmx.export.naming.ObjectNamingStrategy; SearchStrategy: current) found no beans (OnBeanCondition)

   NoOpCacheConfiguration matched
      - Automatic cache type (CacheCondition)

   PersistenceExceptionTranslationAutoConfiguration matched
      - @ConditionalOnClass classes found: org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor (OnClassCondition)

   PersistenceExceptionTranslationAutoConfiguration#persistenceExceptionTranslationPostProcessor matched
      - @ConditionalOnMissingBean (types: org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor; SearchStrategy: all) found no beans (OnBeanCondition)
      - matched (OnPropertyCondition)

   PropertyPlaceholderAutoConfiguration#propertySourcesPlaceholderConfigurer matched
      - @ConditionalOnMissingBean (types: org.springframework.context.support.PropertySourcesPlaceholderConfigurer; SearchStrategy: current) found no beans (OnBeanCondition)

   RedisCacheConfiguration matched
      - Automatic cache type (CacheCondition)

   SimpleCacheConfiguration matched
      - Automatic cache type (CacheCondition)

caching, HTTP and persistence exception translation none of which are needed when I'm trying to write a Spring Integration Kafka or MQTT flow.

Spring Integration publishes a BOM which is already included, so I can already include common adapters and spring integration modules unqualified. It'd be no fuss at all to add spring-integration-*, one by one, as I need them. If the starter included the Java DSL and didn't needlessly include the four extra modules, then anybody could add as needed and they'd have the most concise way to write lean mean integration code out of the box. I also wonder what, if any, interaction the auto-config'd HTTP converters and so on will have when used with the forthcoming spring-reactive.

[vpavic]

I fully agree with @joshlong's stance on this.

We use Spring Integration extensively in nearly all of our projects and Boot's set of included modules never reflects our use case - multiple included modules are always left unused, and other are always manually included. Considering Spring Integration's complexity and sheer amount of modules I'd say it is very difficult to come up with something that can be considered as a _sensible subset of technologies to include_.

Going with just core and Java DSL really seems to be the most sensible option here.

[cemo]

+1 @vpavic and @joshlong

[joshlong]

also, this problem becomes more pronounced when you use Spring Cloud Stream (which builds on, and best interacts with, Spring Integration) to build Spring Cloud Data Flow modules. Modules are supposed to be reusable, singly focused.

[philwebb]

OK, we're sold. We'll fix this for 1.4.

[wilkinsona]

@artembilan What are your plans for Spring Integration Java DSL 1.2? Do you have a release planned at the moment?

[artembilan]

@wilkinsona , I'm afraid that there might be no 1.2 RELEASE yet for the Boot 1.4 RELEASE.
Maybe a bit later... Over a month after that...
We can release some 1.1.3 if the current version isn't compatible with SF+SI-4.3.

For more faster 1.2 I need more hands, minds and time from somewhere like subspace :smile:

[wilkinsona]

@artembilan Haha. Couldn't we all.

No problem with 1.1.x. I just wanted to know if we should expect an update to 1.2 in the Boot 1.4 time frame.

Thanks.