Printable View
My coworker is convinced that Spring Integration does not jive well with Spring Java Config. Is this true? I haven't yet used Spring Integration, but would like to. I much prefer the Java config style of app context configuration (the @Configuration kind, not the @Inject kind), and would prefer to use it over XML, which I hate.
Well, Spring Integration is not a general purpose DI framework and although it would probably be possible to come up with some form of ala-javaconfig style of configuration i'll be honest with you XML does fit much better here especially when every EIP element is represented via a very descriptive namespace.
Having said that we do realize that we need to have alternative configuration style and are currently working on Scala DSL for SI. You can get a quick preview here: https://github.com/SpringSource/spri...egration-scala
Another way to say this is that the XML elements we provide via the namespaces act as a DSL themselves. They provide a higher level model on top of the underlying API. For example, when you define a <transformer> or <router>, a few objects are created. At the surface there is a ConsumerEndpointFactoryBean that knows how to create either a PollingConsumer or EventDrivenConsumer instance based on the type of the input-channel being referenced (if it's a PollableChannel vs. SubscribableChannel, respectively). That "consumer" instance then references some implementation of MessageHandler (where the actual transformation or routing occurs). Typically, that handler then references a POJO. It may alternatively have a SpEL expression to evaluate or a script (e.g. Groovy) to execute.
So, all of that can be done via the @Configuration and @Bean style, but you would need to construct the API level objects as opposed to the DSL level. Because of the need for flexibility within our DSL, it's going to be a better fit in languages like Scala and Groovy. The link Oleg provided will show you the direction we're going.
Hope that makes sense.
-Mark
Seems like the SI namespace elements are just declarative representations of builders, which has an equivalent Java representation, e.g.
new GatewayBuilder("gatewayid", LeadGateway.class).build()
new ChannelBuilder("mychannel").queue(5).build()
new ServiceActivatorBuilder(inputChannel(), someService(), "someMethod").build();
Scala is nice, but perhaps something similar could be provided within the confines of the Java language. I've seem similar DSLs constructed without the features of Scala. The lack of closures makes some of it a bit verbose, but it could work.