It is very possible that I didn't get it or I didn't spend enough time working with it, but my experience with Camel is not great. I worked with Camel in two different teams with a different set of skills and experience but all Camel projects had several characteristics:

• no tests or tests in bad shape
• low type safety due to large number of casts
• huge and complex routes

After a lot of pain, we decided to drop Camel and to use plain Spring Boot and a few things changed:

• it became easier to write tests
• easier to design and write the code
• team happiness increased

Even after this, I don't think Camel is a bad framework and it can be successful in certain contexts. It is important to understand its good and bad parts and decide for yourself. I will highlight its bad parts as its good parts are easy to find e.g.

type safety

Exchange is central to the route and it provides no type safety. It is too easy to expect a rabbit but to get an orange. Exchange is like a raw Map but producer and consumer are most of usually in different files which makes this hard to spot.

testing

It was really difficult to write tests with Camel. Mocking did not work as expected, code to be tested was very coupled and negative testing was almost impossible. The resulting test was usually very complicated and very difficult to read. The number of disabled tests grew constantly as it was difficult to understand what went wrong.

surprising behavior

Nobody is probably happy when the behavior of a certain piece of code surprises. Something like a printReport method does also some updates in a database. Or when exceptions are swallowed and everything looks rosy. It was quite a surprise to find that this is the default Camel exception handling.

abstraction inversion

It gets really funny when people start implementing everything in routes. Do we need to add two numbers? Let's create a new route. We start coding in Camel DSL and things are getting complicated. Let's add more routes to solve this. In the end, something which can be done in a few lines of Java code becomes a huge untested route.

learning curve

We got so many times in situations where we knew something can be solved with plain Spring but we were in a route context and we had to find a Camel solution. Hence we spent hours and sometimes days doing something which could have been done in minutes. And so many times we realized later that the solution we found was not doing what we expected to do.

design

Camel seemed to stay in your way and not let you design code in the way wanted. We found it especially difficult to implement wrapping logic. Think about try-finally Java concept. We had to transform a local wrapping logic into a linear logic having its endpoints far away in the code.

custom integration

We had a case of one request - many responses pattern on a JMS interface. Camel supports only one request - one response pattern so the team had to work around this. A very unmaintainable solution was found for something which was done later in a different project very simple with plain Spring solution.

combining frameworks

We must always be careful when we add libraries to our projects. Adding 2 similar frameworks like Camel and Spring to a project is close to insanity. You'll find all crazy combinations of these 2 frameworks and interesting problems to solve when conflicts between libraries happen.

In closing words, be very careful when you decide what framework to use in your project. Question everything, start small and grow the solution slowly.

Pablo Vergés presented at the Software-Craftsmanship-Zurich event an interesting approach on learning Git.

The idea is to create a git repository inside another git repository and track changes in the inner repository using the outer repository.

Slides can be found here and a recording of another event with the same content can be found here.

Let's try to clean up embedded Elasticsearch indexes before every integration test:

class ElasticsearchCleanerExtension : BeforeEachCallback {

    override fun beforeEach(context: ExtensionContext) {
        val contextManager = testContextManager(context)
        val applicationContext = contextManager.testContext.applicationContext as GenericApplicationContext
        val cleaner = applicationContext.getBean(ElasticsearchCleaner::class.java)
        cleaner.cleanup()
    }

    private fun testContextManager(context: ExtensionContext):TestContextManager {
        val namespace = Namespace.create(SpringExtension::class.java)
        val store = context.getStore(namespace)
        return store.getOrComputeIfAbsent(context.requiredTestClass, ::TestContextManager, TestContextManager::class.java)
    }
}

which depends on the actual clean up component:

@Component
class ElasticsearchCleaner(val studentRepository: StudentRepository) {
    fun cleanup() {
        studentRepository.deleteAll()
            .block(Duration.ofSeconds(2))
    }
}

Each test must be annotated:

@SpringBootTest
@ExtendWith(ElasticsearchCleanerExtension::class)
class StudentPersistenceTest {
....
}

Now, the student index will be cleaned up before each test in the StudentPersistenceTest class.

Luckily, there is a way to customize the generated code by the Maven plugin. We'll need 2 projects for this: one with customizations and the other with actual code generation.

Customization project

Let's try to add static constructors for single field types:

public class AvroGeneratorExtensions {

    public String staticConstructor(SpecificCompiler specificCompiler, Schema schema) {
        if (schema.getFields().size() != 1) {
            return "";
        }
        String parameters = createParameters(specificCompiler, schema);
        String setters = createSetters(schema);
        return "public static " + specificCompiler.javaType(schema) + " of(" + parameters + ") {return newBuilder()" + setters + ".build();}";
    }

    private String createSetters(Schema schema) {
        String setters = schema.getFields().stream()
                .map(f -> "." + generateSetMethod(schema, f) + "(" + f.name() + ")")
                .collect(joining("\n"));
        return setters;
    }

    private String createParameters(SpecificCompiler specificCompiler, Schema schema) {
        String parameters = schema.getFields().stream()
                .map(f -> specificCompiler.javaType(f.schema()) + " " + f.name())
                .collect(joining(", "));
        return parameters;
    }

This class must be compiled and published as a jar file.

Messages project

In the main project, we need to configure the build like:

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.avro</groupId>
                <artifactId>avro-maven-plugin</artifactId>
                <version>${avro.version}</version>
                <dependencies>
                    <dependency>
                        <!-- add above project here -->
                    </dependency>
                </dependencies>
                <executions>
                    <execution>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>schema</goal>
                            <goal>protocol</goal>
                            <goal>idl-protocol</goal>
                        </goals>
                        <configuration>
                            <sourceDirectory>${project.basedir}/src/main/avro/</sourceDirectory>
                            <templateDirectory>${project.basedir}/src/main/resources/templates/</templateDirectory>
                            <stringType>String</stringType>
                            <fieldVisibility>private</fieldVisibility>
                            <velocityToolsClassesNames>AvroGeneratorExtensions</velocityToolsClassesNames>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

Velocity templates must be extracted from avro jar file into src/main/resources/templates/. These are:

• enum.vm
• fixed.vm
• protocol.vm
• record.vm

Add $avrogeneratorextensions.staticConstructor($this, $schema) to record.vm to generate the static constructors.

A working example can be found here:

• Customization
• Messages

Yeah, this looks like a huge hack but I am not aware of a better way to customize generated code. Templates must be updated each time a new version of Avro library is used and the development process is basically trial and error.

Spring Data maps enum by default using the enum name and it gets a bit complicated when we want to map these values to a human-readable form.

Let's take as example simplified Gender enumeration:

enum class Gender(val esValue: String) {
    MALE("m"),
    FEMALE("f"),
    OTHER("o");
}

We need to write 2 converters, one for serialization and one for deserialization:

@ReadingConverter
class StringToGenderConverter : Converter<String, Gender> {
    private val mapping: Map<String, Gender> = Gender.values().associateBy { it.esValue }

    override fun convert(source: String): Gender {
        return mapping.getOrDefault(source, OTHER)
    }
}

@WritingConverter
class GenderToStringConverter : Converter<Gender, String> {

    override fun convert(source: Gender): String {
        return source.esValue
    }
}

And then we need to add them to configuration:

@Configuration
class ElasticsearchConfig(private val conversionService: GenericConversionService) : AbstractReactiveElasticsearchConfiguration() {

    @Bean
    override fun entityMapper(): EntityMapper {
        val entityMapper = ElasticsearchEntityMapper(elasticsearchMappingContext(), conversionService)
        val converters = listOf(
            GenderToStringConverter(),
            StringToGenderConverter()
        )
        entityMapper.setConversions(ElasticsearchCustomConversions(converters))
        return entityMapper
    }
}

GenderToStringConverter can be made generic by having Gender implement an interface:

enum class Gender(private val esValue: String) : ElasticsearchValue {
    MALE("m"),
    FEMALE("f"),
    OTHER("o");

    override fun esValue(): String = esValue
}

interface ElasticsearchValue {
    fun esValue() : String
}

and converter:

@WritingConverter
class ElasticsearchValueToStringConverter : Converter<ElasticsearchValue, String> {

    override fun convert(source: ElasticsearchValue): String {
        return source.esValue()
    }
}