Wednesday, October 29, 2014

Using Apache Camel with Spring Boot

Some time ago I created a Spring Boot auto-configuration module for the Apache Camel. Initially it was a part of the Fabric8 Spring Boot support, but I decided that the module deserves its own life under the Apache Camel umbrella, so I've just moved it there. Spring Boot module will be available starting from Camel 2.15.0.


What is Camel auto-configuration for Spring Boot?


Spring Boot Camel component provides auto-configuration for the Apache Camel. Our opinionated auto-configuration of the Camel context auto-detects Camel routes available in the Spring context and registers the key Camel utilities (like producer template, consumer template and the type converter) as beans.


How to enable Camel auto-configuration in my Spring Boot application?


Just drop camel-spring-boot jar into your classpath:

<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-spring-boot</artifactId>
    <version>${camel.version}</version> <!-- use the same version as your Camel core version -->
</dependency>

camel-spring-boot jar comes with the spring.factories file, so as soon as you add that dependency into your classpath, Spring Boot will automatically auto-configure the Camel for you. Yay! That was fast ;) .



Auto-configured Camel context


The most important piece of functionality provided by the Camel auto-configuration is the CamelContext instance. Camel auto-configuration creates SpringCamelContext for your and take care of the proper initialization and shutdown of that context. Created Camel context is also registered in the Spring application context (under camelContext bean name), so you can access it just as the any other Spring bean.
@Configuration
public class MyAppConfig {
 
  @Autowired
  CamelContext camelContext;
 
  @Bean
  MyService myService() {
    return new DefaultMyService(camelContext);
  }
 
}
Keep in mind however that usually you don't really have to inject CamelContext directly into your application, as you can use the feature called...



Auto-detecting Camel routes


Camel auto-configuration collects all the RoutesBuilder instances from the Spring context and automatically injects them into the provided CamelContext. It means that creating new Camel route with the Spring Boot starter is as simple as adding the @Component annotated class into your classpath...
@Component
public class MyRouter extends RouteBuilder {
 
  @Override
  public void configure() throws Exception {
    from("jms:invoices").to("file:/invoices");
  }
 
}
...or creating a new route RoutesBuilder bean in your @Configuration class:
@Configuration
public class MyRouterConfiguration {
 
  @Bean
  RoutesBuilder myRouter() {
    return new RouteBuilder() {
 
      @Override
      public void configure() throws Exception {
        from("jms:invoices").to("file:/invoices");
      }
 
    };
  }
 
}

Ideally, you should not wire routes into the CamelContext by yourself. It is simpler just to add them to the classpath and let the Spring Boot to wire them for you.

Camel properties


Spring Boot auto-configuration automatically connect Spring Boot external configuration (like properties placeholders, OS environment variables or system properties) with the Camel properties support. It basically means that any property defined in application.properties file...
  
route.from = jms:invoices
...or set via the system property...
java -Droute.to=jms:processed.invoices -jar mySpringApp.jar
...can be used as the placeholder in the Camel route:
@Component
public class MyRouter extends RouteBuilder {
 
  @Override
  public void configure() throws Exception {
    from("{{route.from}}").to("{{route.to}}");
  }
 
}

Basically any property available for the Spring property resolver can be resolved by the Camel properties component as well.

Customizing Camel context configuration


If you would like to perform some operations on CamelContext bean created by Camel auto-configuration, register CamelContextConfiguration instance in your Spring context:
@Configuration
public class MyAppConfig {
 
  ...
 
  @Bean
  CamelContextConfiguration contextConfiguration() {
    return new CamelContextConfiguration() {
      @Override
      void beforeStart(CamelContext context) {
        // your custom configuration goes here
      }
    };
  }
 
}
Method CamelContextConfiguration#beforeStart(CamelContext) will be call just before the Spring starts the auto-configured CamelContext.

Auto-configured consumer and producer templates


Camel auto-configuration provides a pre-configured ConsumerTemplate and ProducerTemplate instances. You can simply inject them into your Spring-managed beans:
@Component
public class InvoiceProcessor {
 
  @Autowired
  private ProducerTemplate producerTemplate;
 
  @Autowired
  private ConsumerTemplate consumerTemplate;

  public void processNextInvoice() {
    Invoice invoice = consumerTemplate.receiveBody("jms:invoices", Invoice.class);
    ...
    producerTemplate.sendBody("netty-http:http://invoicing.com/received/" + invoice.id());
  }
 
}
In the example above I read a message from the JMS queue, convert it into the domain class called Invoice and finally use HTTP call to send confirmation to some external system that I processed the invoice. No Camel routes here, only consumer/producer templates.

By default consumer and producer templates come with the endpoint cache sizes equal to 1000. You can change that values via the following Spring properties:
camel.springboot.consumerTemplateCacheSize = 100
camel.springboot.producerTemplateCacheSize = 200


Auto-configured TypeConverter


Camel auto-configuration registers TypeConverter instance named typeConverter in the Spring context.
@Component
public class InvoiceProcessor {
 
  @Autowired
  private TypeConverter typeConverter;
 
  public long parseInvoiceValue(Invoice invoice) {
    String invoiceValue = invoice.grossValue();
    return typeConverter.convertTo(Long.class, invoiceValue);
  }
 
}
As you can see the type converter is pretty handy when performing conversions between two data types, so it is very useful to have it available in your Spring components.

What's next?


There are still many features I'd like to see in Camel Spring Boot. Just to mention some of them:
  • Test helpers API. We don't really need a full-blown testing API, like for the old Camel or Camel Spring. Spring Boot testing API enhanced by the Camel auto-configuration is flexible enough to handle all the most important testing scenarios (like loading routes, overriding the configuration and so forth) without any additional Camel-specific testing utilities. However having a base class with some extra helper methods to avoid testing-code boilerplate will be always appreciated.
  • Registering custom converters. I'd like to make it really easy to register new Camel type converters. As simple as adding new converter bean to the Spring context.
  • Bridge between Spring and Camel converters. Spring comes with its own types converter API. I will be nice to bridge Spring converters to Camel (and reversely) so end-users could benefit from the maximum number of converters available for them.
  • Making sure that Camel components work nicely with Spring Boot. That would require creating some pull requests to Spring Boot upstream and changes in the code of some components to be sure that those can properly pick up the beans pre-configured by Spring Boot. For example I would like to be sure that camel-jpa component plays nicely with the default Hibernate configuration provided by the Spring Boot JPA auto-configuration.


Give it a shot!


Just try to use the new Spring Boot support for Camel and let me know what do you think of it. Do you feel it lacks some functionality? Something is not working as it should? Our documentation sucks? Feel free to ping me.

Friday, October 17, 2014

Six major changes in the Fabric8 V2


As some of you may know from my tweets, the Fabric8 team started to work on the v2 branch of the project. You may also already know that this version of Fabric8 will bring some major architectural changes. All of those are for better in my humble opinion, even if you may find them a bit aggressive ;) .

Change #1: Docker and Kubernetes will be required to run Fabric8

Yes. Containers are the big thing. They will change the way we deploy and manage our software. The new version of Fabric8 fully embraces the containerization trend. It means that Fabric8 is designed to work on top of Kubernetes and Docker. Fabric8 will work in any environment providing the Kubernetes platform such as RHEL Atomic, OpenShift, Google Compute Engine, Azure and so forth.

For platforms not supporting Docker, there will be a Kubernetes emulator layer. But come on, don't resist the changes in the industry - just invest into the Docker and Kubernetes. If Microsoft did it, you can do it as well :) .

Change #2: No ZooKeeper runtime registry

There will be no ZooKeeper ensemble in the Fabric8 anymore. Fabric8 1.x used ZooKeeper to share the runtime information between applications and to discover services. Kubernetes comes with the etcd internally which serves much of the same purpose and has support for the services binding, so Fabric8 v2 doesn't need ZooKeeper registry anymore for general purpose provisioning of containers and services.

However certain services will still require master slave election and partitioning functionality (such as running clusters of ActiveMQ); where either etcd or Apache ZooKeeper is required. If a Kubernetes environment allows it, then Fabric8 could reuse the underlying etcd cluster; otherwise an etcd or ZooKeeper clusters is required for things like ActiveMQ clustering.

Change #3: No profiles to configure application deployment

There will be no profiles in Fabric8 anymore. Starting from v2 Fabric8 uses app JSON files (i.e. Kubernetes extension proposed by OpenShift 3) to configure deployment of the managed application. More detailed configuration (like properties or YAML files) can be added to the file system of the deployed application's Docker image.

Change #4: Git repository isn't mandatory

Applications' configuration isn't stored in Git repository as it used to be in Fabric8 v1. As Fabric8 v2 doesn't use profiles (but app templates instead), the Git repository is not needed anymore. You can just store application's configuration (app file) in the Maven project and use the Fabric8 Maven plugin to start the application in the Kubernetes without keeping the configuration in any central repository (like Git).

However keeping app files in Git for easier configuration management can be useful. That's why Hawt.io provides this functionality for you. You can push your configuration to the Hawt.io Git repository via fabric8:deploy Maven goal. Fabric8 uses App Zip packaging format to distribute the configuration between the various environments.

Change #5: There is not Fabric8 "server" anymore

Starting from Fabric8 v2 Kubernetes is responsible for providing the runtime registry for the managed applications. It means that you don't have to start any dedicated Fabric8 deamon. Tools like Fabric8 Maven plugin or Hawt.io can connect directly to the Kubernetes and deploy into it or manage the applications.

Change #6: No Fabric8 server == no (Karaf) Fabric8 shell

If you are the shell kind of person (like me!), you probably enjoy Karaf-based Fabric8 shell very much. As there is no "Fabric8 server" anymore, Karaf won't provide the default shell any longer. For the Fabric8 v2 development activities, the recommended tool is JBoss Forge with the Fabric8 add-on. For provisioning purposes (like creating containers/services or changing the replica sizes) the default shell is OpenShift/Kube. Kube will be included in Red Hat Enterprise Linux and OpenShift V3 and is the standard shell for provisioning any kind of the container.

Technically, you can install Karaf server into the Kubernetes and enjoy the part of the old Fabric8 shell commands, but keep in mind that main development efforts will be focused on Kube and Forge commands.

Give it a shot

Wanna try new Fabric8 V2? Here is the detailed guide how to install it locally and deploy a sample application into it. Got problems with installation? Ping us on Fabric8 forum - we'd love to help you.

Wednesday, July 16, 2014

Using Spring framework with Fabric8

So you wanna deploy Spring application into OSGi?

In the older versions of the Karaf, ServiceMix and Fuse we recommended to use Spring Dynamic Modules to deploy applications based on the Spring framework. As Spring DM project is not actively maintained anymore, we currently don't recommend to use it. Moreover due to the fact that there is no other alternative for Spring deployments in the OSGi environment, we don't recommend provisioning Spring-based applications into the OSGi anymore.

Spring Boot container

The recommended approach for working with the Spring applications in the Fabric8 environment is to use the Spring Boot container - the flat classpath microservice provisioned and managed by the Fabric8.

You can provision Spring Boot container either as a managed JVM process or as a Docker container.

Spring Boot container comes with many useful utilities that makes it much easier to use Apache Camel and ActiveMQ. Spring Boot containers can be also aware of the Gateway, ZooKeeper registry and the other Fabric8 components.

Other flat classpath containers

The other option to work with the Spring-based applications in the Fabric8 environment is to deploy those as a part of the WAR into Tomcat or as a module into the WildFly or Apache TomEE. You can also provision managed JVM process and start Spring application context yourself. Keep in mind that those deployment options don't make you to use Spring Boot - you can always create and manage the Spring application context yourself.

Wednesday, July 9, 2014

Wearing my red fedora - GeeCon and 33rd Degree

I usually don't write posts summarizing conferences, because I assume that nobody cares what I think about given event. ;) This time however I decided to write a summary of the most important topics from these two biggest Java gigs in Poland from the perspective of the Red Hatter. I know at least few folks interested in this kind of review ;) .

First of all both 33rd Degree and GeeCon are very similar. Really. Both events take place in the same venue (which is really cool BTW - I love conferences in the cinemas). I even got problem recognizing during which conference I've been talking to whom. However it doesn't really matter as I enjoyed GeeCon as much as 33rd Degree :) .

The most interesting stuff from the perspective of the guy working on daily basis with the Fuse middleware:

Microservices

Buzz-busters will eat me alive for this, but I must say it. Microservices are becoming really popular. You may argue that microservcies are new ESB, say platitudes like "there ain't no such thing as a free lunch" or just hate microservices with passion. You can't deny however that microservices are starting to become the big thing in the industry right now. I'm particularly interested in this topic as my recent open source love, Fabric8, is a kind of devOps swiss knife where we support microservices as a first-class citizen.

BTW If you got a chance to listen to Thoughtworks' Sam Newman talking about microservices, do it. Believe me, his talk is worth your time :) .

Spring Boot

If you are Spring hater, please stop reading now. Spring holds really big piece of the market share for application frameworks in the Java world. IMHO you need to be a friend to the Spring to get wider adoption of your Java software. Just as we are in Fabric8. Some things to remember in the context of the Spring:
  • Spring XML is dead
  • long live @Configuration
  • long live Groovy
  • IMHO Spring will be basically equal to Spring Boot pretty soon. Don't bother with your lousy custom configuration wiring code - migrate to Spring Boot and make your life easier.
Keep also in mind that not only Thoughtworks and Red Red promotes microservices approach to the architecture. Pivotal is shouting "microservices are cool" at you as well.

Java 8

Sometimes I also can't believe this, but yeah, Java 8 is here and it rocks. Please make our world a better place and adopt it. BTW Apparently Java 7 can be perceived as a minimal version of Java right now. That's good, because we require Java 7 in the latest Fabric8 as well :) .

Docker

We love Docker at Red Hat. Fabric8 loves Docker as well. I think that the majority of the industry still doesn't realize how big thing Docker is. Docker should be at your list of the technologies you need to learn in 2014. Docker plays nicely with the microservices approach. And as in the case of the micoservices, many big players started to adopt it (Red Hat, Google, Pivotal, Thoughtworks to name a few).

Vert.x

This is my personal TODO. Vert.x looks really promising and I'm ashamed I don't know it yet. This is project definitely worth to mention in this post as it is supported and promoted by Red Hat. Vert.x is pretty good candidate to take a piece of market share from Spring. And not only Spring, because Vert.x is a polyglot framework and therefore not limited to JVM.

Monday, June 23, 2014

Bootstrap RESTful Docker on Ubuntu

The most "devOps way" of communicating with the Docker server is to expose it via the REST API. And then using the HTTP client of your choice to send commands to that Docker server.  

Here is what you need to do in order to set up the Docker server exposed via REST endpoint on Ubuntu 14.04.

Install Docker

Here is the Official Ubuntu installation documentation in the nutshell - to install Docker on Ubuntu just type the following command into your shell:

curl -s https://get.docker.io/ubuntu/ | sudo sh

Expose Docker via HTTP

By default Docker is exposed only via the Unix sockets. You can change it with the additional -H (host) option.

sudo sh -c 'echo "DOCKER_OPTS=\"-H unix:///var/run/docker.sock -H tcp://127.0.0.1:2375\"" > /etc/default/docker'
sudo service docker restart
In order to verify that Docker has been properly exposed via HTTP, execute the following command:

curl http://127.0.0.1:2375/version
{"ApiVersion":"1.12","Arch":"amd64","GitCommit":"990021a","GoVersion":"go1.2.1","KernelVersion":"3.13.0-29-generic","Os":"linux","Version":"1.0.1"}

Running Docker without root

If you wanna execute docker command without sudo, add yourself to the docker system group:

usermod -a -G docker yourUserName

Fabric8 readiness

The settings presented above are the default Docker setup expected by the Fabric8 Docker integration. If you followed this instruction, you can safely play with the Fabric8 Docker containers.

Monday, June 16, 2014

What is Fuse now?

Some people don't fully realize it, but Fuse ESB has been evolving pretty much over the past few years. Many folks see Fuse as the commercially supported version of the ServiceMix i.e. OSGi container used to deploy Camel, CXF and ActiveMQ.

Well, that changed :).

ESB? Not really anymore...

Recently Fuse evolved into the open source project called Fabric8 - the iPaaS integration platform. What is iPaaS integration platform? It's the piece of the software that allows you to deploy (and manage) your business services and middleware. I personally like to say that Fabric8 is something that glue your sofware pieces together.

Fabric8 itself is the open source project. JBoss Fuse is Fabric8 with commercial support (delivered to you by the awesome Red Hat engineering support ;).

Deploy whatever you want, wherever you want

Fabric8 is a poly-container. It means that you are no longer forced to deploy your services as the OSGi bundles running inside the Apache Karaf container. Fabric8 provides unified container API that makes it possible to deploy your services (WARs, OSGi bundles, jar containing executable class with public static void main method, WildFly modules and so forth) into the container of your choice (Tomcat, Karaf, plain JVM processes, WildFly, etc).

With the Fabric8 you can deploy your services not only to the various type of servers on the single physical machine, but also to the remote machine managed via SSH, or even better, to the cloud containers (like Openshift or Docker). From the Fabric8 perspective it really doesn't matter where do you deploy your services - you can still manage and monitor them in the same unified way.



DevOps heaven

We love devOps. Fabric8 is being developed with the devOps folks treated as the first-class citizens. Fabric8 comes with Hawtio - really impressive management console. Just try it - believe me it's worth to try Fabric8 just for the Hawtio alone :) .

For more command line oriented guys (like me), there is a Fabric8 shell available. You can use your favorite SSH client to connect into the Fabric8 shell and take the advantage of the interactive shell with the auto-completion among its numerous features.

What does it mean for me?

Do you enjoy our messaging related goodies? You like lightweight messaging with the ActiveMQ? Messages routing and gazillion of components available in Apache Camel? Services management with the Apache Karaf shell? Fabric8 has it all. Plus provisioning, management and monitoring features that can bring back the joy to your operations activities :) . Give Fabric8 a try and see how it can leverage the software development process to the new level of fun - in case of any issues you can find Fabric8 folks on our mailing list and IRC channel. We are always happy to help with the potential issues!

Thursday, November 21, 2013

Camel Extra release life cycle finally in place

This is an epic moment for all the Camel Extra users. For the very first time in the history of the project we are finally in sync with the release cycle of Apache Camel.

The above basically means that from now on you can always use the version of Camel Extra component which is tested against your version of Apache Camel. For example if you want to use Hibernate component in your project using Camel 2.12.1, you can use the same version of the latter component as your ASF Camel dependencies.
<properties>
  <camel-version>2.12.1</camel-version>
</properties>
...
<dependency>
  <groupId>org.apache.camel</groupId>
  <artifactId>camel-core</artifactId>
  <version>${camel-version}</version>
</dependency>
<dependency>
  <groupId>org.apache-extras.camel-extra</groupId>
  <artifactId>camel-hibernate</artifactId>
  <version>${camel-version}</version>
</dependency>
From this point forward Camel Extra is distributed in the same versions as Apache Camel, starting from 2.10.0. For this moment that would be:
  • camel-extra-2.10.0
  • camel-extra-2.10.1
  • camel-extra-2.10.2
  • camel-extra-2.10.3
  • camel-extra-2.10.4
  • camel-extra-2.10.5
  • camel-extra-2.10.6
  • camel-extra-2.10.7
  • camel-extra-2.11.0
  • camel-extra-2.11.1
  • camel-extra-2.11.2
  • camel-extra-2.12.0
  • camel-extra-2.12.1
Catching up the Apache Camel life cycle takes the burden of answering the users' question "Why there is no Hibernate component in version ${put your Apache Camel version here} available in Maven Central?" from me :) . Many thanks for all the Camel Extra riders contributing to the release process. Special thanks go to our new committer Christoph Emmersberger. Kudos for all your great work during the laborious release process!