Since Camel version 2.10 there is support for CDI (JSR-299) and DI (JSR-330). This offers new opportunities to develop and deploy Apache Camel projects in Java EE containers but also in standalone Java SE or CDI containers. Time to try it out and get familiar with it.
What exactly is Camel?
Camel is an integration framework. Some like to call it ESB-lite. But in the end, it is a very developer and component focused way of being successful at integration projects. You have more than 80 pre-build components to pick from and with that it basically contains a complete coverage of the Enterprise Integration Pattern which are well known and state of the art to use. With all that in mind, it is not easy to come up with a single answer. If you need one, it could be something like this: It is messaging technology glue with routing. It joins together messaging start and end points allowing the transference of messages from different sources to different destinations.
Why Do I Care?
I’m obviously excited about enterprise grade software. But always been a fan of more pragmatic solutions. There’s been some good blog posts, about when to use Apache Camel and with the growing need to integrate different systems over very heterogeneous platforms it is always handy to have a mature solutions at hand. Most of the samples out there start with bootstrapping the complete Camel magic, including the XML based Spring DSL and with it the mandatory dependencies. That blows everything up to a extend I don’t want to accept. Knowing that there has to be a lightweight way of doing it (Camel-Core is 2.5 MB at Version 12.13.2) I was looking into how to bootstrap it myself. And use some of it’s CDI magic.
The Place to Look for Ideas first
Is obviously the Java EE samples project on GitHub. Some restless community members collected an awesome amount of examples for you to get started with. The ultimate goal here is to be a reference for how to use the different specifications within the Java EE umbrella. But even some first extra bits have been included and showcase an example from different areas like NoSQL, Twitter, Quartz Scheduling and last but not least Camel integration. If you run it as it is in latest WildFly 8.1 it is not working. The cdi extension of Camel makes it a bit tricky to do it, but as mentioned in the corresponding issue, there is a way to get rid of the ambiguous CDI dependency by just creating a custom veto extension. The issue is filed with Camel and I heard, that they are looking into improving the situation. If you want to to try out the example, go to my GitHub repository and look for the CamelEE7 project.
How Did I Do It?
The Bootstrap.java is a @Singleton EJB which is loaded on application startup (remember, there are different ways to start up things in Java EE) and by @Inject ing an org.apache.camel.cdi.CdiCamelContext you get access to Camel. The tiny example uses another HelloCamel bean to show how to work with payload in the CDI integration.
Make sure to look at the CamelCdiVetoExtension.java and how it is configured in the META-INF folder. Now you’re ready to go. Happy Coding.
And The Best For Last
Camel 12.14 is on the horizon already, scheduled to be released in September. If you have issues or wishes you want to see in it, now is the time to speak up!
Excerpt of the awesome new features, that are upcoming:
Time to get excited!
| Reference: | Bootstrapping Apache Camel in Java EE7 with WildFly 8 from our JCG partner Markus Eisele at the Enterprise Software Development with Java blog. |
