JobExecution access in Camel Spring Batch

Starting from Apache Camel 2.10, our users can benefit from the Spring Batch component. Recently one of such users approached me with the question - how can I access execution context of job started by Camel.

So far the easiest way to access JobExecution instance from the Camel was to register CamelJobExecutionListener to the Spring Batch.

<batch:job>
  <batch:step>
  ...
  </batch:step>
  <batch:listeners>
    <batch:listener ref="camelJobExecutionListener"/>
  </batch:listeners>
</batch:job>

<bean id="camelJobExecutionListener"
  class="org.apache.camel.component.spring.batch.support.CamelJobExecutionListener">
  <constructor-arg ref="camelTemplate"/>
  <constructor-arg value="seda:jobExecutionEventsQueue"/>
</bean>

Example above demonstrates how to collect JobExecution instances sent to Camel before the batch job is started and after it is completed. In this particular case JobExecutions will be collected in the SEDA queue named jobExecutionEventsQueue.

Starting from the Camel 2.11.1 SpringBatchProducer will also automatically forward JobExecution instance (one returned by the JobLauncher) as the output message. You can use the obtained JobExecution reference to perform some operations using the Spring Batch API directly.

from("direct:startBatch").
  to("spring-batch:myJob").
  to("mock:JobExecutions");
...
MockEndpoint mockEndpoint = ...;
JobExecution jobExecution = 
  mockEndpoint.getExchanges().get(0).getIn().getBody(JobExecution.class);
BatchStatus currentJobStatus = jobExecution.getStatus();

I hope this tiny enhancement will improve the experience of using Spring Batch with Apache Camel. If we can do anything to make the Camel Spring Batch API more developer-friendly, just drop us a line. Camel riders are always eager to improve components API.

Component scan support for Spring Scala

Just a few days ago an interesting feature has been committed into the Spring Scala master branch. From this point forward Scala configuration in Spring supports component scanning as the first-class citizen.

Component scanning is an extremely useful feature of Spring Framework which provides the support to dynamically compose the application context, depending on the content of the application classpath. Component scanner basically looks up the classpath in order to find the classes marked with dedicated annotations (such as @Component or @Service). The latter classes are then registered in the application context as the bean definitions. Class eligible for classpath scanning could look as follows.

package org.example;

import org.springframework.stereotype.Component;

@Component
public class MyComponent {}

To enable component scanning in Spring XML configuration, we usually include the <context:component-scan/> element in the wiring file.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:context="http://www.springframework.org/schema/context"
     xsi:schemaLocation="http://www.springframework.org/schema/beans
         http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
         http://www.springframework.org/schema/context
         http://www.springframework.org/schema/context/spring-context-3.0.xsd">

   <context:component-scan base-package="org.example"/>

</beans>

People who favor Java Spring configuration style over XML files, usually fall back to the @ComponentScan annotation.

@Configuration
@ComponentScan({"org.example"})
public class MyApplicationConfig {}

Starting from the next milestone of Spring Scala (i.e. 1.0.0.M3) you will be able to use similar component scan syntax in the FunctionalConfiguration classes. In order to take the advantage of new component scanning API in Spring Scala, you need to enhance your configuration with ContextSupport trait.

 
class MyScalaApplicationConfig 
  extends FunctionalConfiguration with ContextSupport {

  componentScan("org.example", "com.example")

}

If you need more strict control over the scanning configuration, you can pass additional options into the componentScan method call.

 
class MyScalaApplicationConfig 
  extends FunctionalConfiguration with ContextSupport {

  componentScan(basePackages = Seq("org.example"),
    scopedProxy = Some(ScopedProxyMode.TARGET_CLASS),
    excludeFilters = Seq(new RegexPatternTypeFilter(Pattern.compile(".*Test")))
  )

}

Until the reference documentation for Spring Scala is released, please refer to the Scaladoc of ContextSupport trait for more details of component scan API.

Building functional application context with Spring Scala

The is the second post of mine presenting the latest changes to the bleeding-edge Spring Scala 1.0.0.M2 release of the Spring Scala project from the Spring Source portfolio. As I mentioned in my previous post, my goal is to provide a set of practical examples for Spring Scala users until project reference documentation will be published.

This time I would like to describe the possible ways of creating functional application contexts available in the latest milestone release.

First of all, let me demonstrate the example of simple FunctionalConfigApplicationContext. Quick reminder here - functional application config is a brand new way to define Scala-friendly Spring application context configurations by taking the advantage of Scala functions.

import org.springframework.scala.context.function.FunctionalConfigApplicationContext

class MyConfiguration extends FunctionalConfiguration {

  bean("serviceName") {
    new BusinessService(dao())
  }

  val dao = bean("daoName") {
    new JdbcDao()
  }

}

The simplest way to create application context from the configuration class presented above is to use the companion object of the FunctionalConfigApplicationContext class.

val context = FunctionalConfigApplicationContext[MyConfiguration]
val service = context[BusinessService]

If you want to build application context from multiple configuration classes, the companion FunctionalConfigApplicationContext object might be helpful again.

val context = FunctionalConfigApplicationContext(
  classOf[MyConfiguration],classOf[SomeOtherConfiguration])

val service = context[BusinessService]

At last, but not least, if you need a tighter control over the way the FunctionalConfigApplicationContext is built, you can create it using default constructor and then register the FunctionalConfiguration classes manually.

val context = new FunctionalConfigApplicationContext()
context.registerClass[MyConfiguration]
context.registerClasses(
  classOf[AnotherConfiguration], classOf[YetAnotherConfiguration])
context.refresh()

val service = context[BusinessService]

If you have in mind even better way to create functional configurations in Spring Scala, please just drop me a line. Or even better - issue pull request to the Spring Scala GitHub repository.

Rich ApplicationContext in Spring Scala

The latest milestone release (1.0.0.M2) of Spring Scala brings you many of the brand new exciting features. Unfortunately as Spring Scala is still in the early development phase, there is no reference documented dedicated to this library. The documentation will be published before the first stable release of Spring Scala. However as both I and Spring Scala forum have been pinged with the questions about the reference documentation for new Spring Scala features, I decided to write some blog posts describing new goodies delivered to the Spring Scala community. This is the very first of these, demonstrating the awesomeness of the rich BeanFactory and ApplicationContext.

Let's start with the org.springframework.scala.context.RichApplicationContext. The latter trait provides Scala-friendly versions of the methods from the plain old Spring ApplicationContext. In order to convert ApplicationContext into RichApplicationContext you can use implicit conversion defined in the ApplicationContextConversions.toRichApplicationContext object.

import ApplicationContextConversions._
...
val context : ApplicationContext = ...

val nissan = context.bean[Nissan]
val xtrail = context.bean[Nissan](name = "xtrail")

// Return Map[String,Car].
val allCars = context.beansOfType[Car] 

// Return Seq[String].
val namesOfCars = context.beanNamesForType[Car]

If you like even more syntactic sugar you can use RichListableBeanFactory.appy() notation to retrieve the bean from the context.

import ApplicationContextConversions._
...
val context : ApplicationContext = ...

// Syntactic sugar magic!
val nissan = context[Nissan] 

// Same magic by bean name.
val xtrail : Nissan = context("xtrail")  

Keep in mind that org.springframework.scala.context.function.FunctionalConfigApplicationContext extends RichApplicationContext out of the box, so you don't need to use ApplicationContextConversions implicit conversion while working with this type of context.

// We can comment out context's implicit conversions
// import ApplicationContextConversions._
...
val context = FunctionalConfigApplicationContext[CarConfig]
val nissan = context[Nissan]

How do you like new Spring Scala context API? What else would you like Scala-friendly ApplicationContext to have?

Spring Scala 1.0.0.M2 has been released

Arjen Poutsma, open source rock star from SpringSource/VMware, announced today that the second milestone of Spring Scala 1.0.0 has been finally released. I feel emotionally bounded to this release, as I contributed pretty much to it :) .

Spring Scala is the brand new project from the Spring portfolio. Its goal is to provide the first-class bridge between the Spring wiring and the Scala code.

New release includes some nice features making Scala people the happy people including:

• New JdbcTemplate wrapper. We've dropped the SimpleJdbcTemplate as it has been deprecated in Java.
• Introduced new "rich" wrappers for the BeanFactory, ListableBeanFactory and ApplicationContext. Also added implicit conversions to these wrappers (following the "Pimp my library" pattern).
• Introduced new AOP Advice wrappers, with implicit conversions (AdviceConversions)
• Upgraded to Scala 2.10.2 and Spring 3.2.2. Note that Spring 3.2.2 is required when using the FunctionalConfiguration trait.
• Added Scala-friendly TransactionSynchronizationManager wrapper supporting pattern-matching style of registering synchronization callbacks. 
• Changed inner workings of FunctionConfiguration so that it now eagerly initializes beans that require this (BeanFactoryPostProcessors etc).
• And many more bug fixes and other changes.

Stay tuned for the next Spring Scala milestone!

Spring Scala forum is here for you

Apparently I've become the Open Source junkie. Recently I started to contribute to another great open source project, this time the one not related directly to the Apache Camel family. I've been a little bit involved into the Spring Scala project from the Spring Source (aka VMware) foundry.

I really like the idea behind this fine piece of software. I plan to use Spring Scala as the base for the Camel and ServiceMix modules written in Scala. For now Camel comes with a nice Scala DSL, however Scala users still don't feel like the first-class citizens in the ServiceMix world. The main reason behind this situation is that there is no dedicated bridge between ServiceMix's Spring XML bootstrap file and Scala code.

Arjen Poutsma (dev lead of Spring Scala) was so kind to create Spring Scala forum so project committers and users could communicate more easily. I personally monitor this forum, so if you got any doubts or suggestions regarding the project, feel free to drop a message there. Keep in mind also that anybody can create request the pull to the Spring Scala on GitHub, so feel free to contribute your ideas.

The future of Camel goodies

Apache Camel is distributed together with the pretty impressive set of components authored by our wonderful contributors. At this point we provide support for around 150 components and data formats. This is really impressive number which makes Camel the leader among the integration frameworks.

The bigger palette of components we offer, the more often we ask ourselves what will be the best way to handle our Camel herd. Should we keep components under Apache Software Foundation umbrella or should we create independent repository for them? What about the release cycles? Who should be responsible for the quality of the components?

If you are interested in the components-related brainstorm we had on Camel development mailing list you should take a peek at this interesting discussion thread. We would appreciate your opinion in this conversation, as we really want to hear the voice of the end users and community in this regards.