I’ve been using and distributing a Apache Camel based example project as part of informal training and JUG talks for several years. I wrote the example to demonstrate best practices for the use of Camel as well as the wonderful testing support baked into the Camel libraries in the context of a complete use case. The example extends the lessons provided in the examples found in the Apache Camel distribution by tying a number of concepts together just like developers do in real world solutions. I recently updated the example to demonstrate the flexibility of Camel to move from a simple deployment in a Tomcat instance to a scalable multi-node deployment using asynchronous messaging.
These updates aim to demonstrate the low-invasiveness of Apache Camel to your existing code base when deployed alongside traditional Web applications in a Servlet container or JEE application server as well as the ability of Camel to scale with your deployment as needed. The updates demonstrate how Camel can scale your integration and business logic on a collection of manually managed and deployed Tomcat instances or on a managed cluster of Fuse ESB (JBoss Fuse) instances leveraging Fuse Fabric and Fuse Management Console to provide more enterprise ready management, monitoring, and provisioning capabilities.
The example code and tutorial documentation are available on GitHub at https://github.com/DavidValeri/intro-to-camel-by-example.
Note that with the Red Hat acquisition of FuseSource, Fuse ESB has been rebranded as JBoss Fuse. At this time, Fuse ESB 7.1 represents the latest GA release of the product line. The example code and tutorial referenced in this post will leverage Fuse ESB 7.1 until the GA release of the rebranded JBoss Fuse becomes available.
Over the years I have needed to integration test a number of web applications from simple user facing applications to large Web service APIs. No matter what the application does, one always needs to deploy the application into a container to perform integration testing of the user interface or Web service APIs. A good development team with an eye on efficiency gets bonus points if this process is handled automatically by the build process. I’ve been using a combination of Maven, Cargo, and a continuous integration server to cheaply solve this problem for years while incurring minimal overhead during the build process. In this post, I lay out a simple configuration for integrating Cargo into the Maven build process for automated testing and for rapid build, test, fix cycles when tooling like JRebel isn’t available.
While testing and security are often the last to get invited to the party, they are integral parts of well written software. Two new features in Camel 2.10 help to ease debugging of TLS related security issues and to provide full support for writing unit tests of Camel routes in Spring Test. While these two new features aren’t likely to make TLS configuration and unit testing the king and queen of prom, they will make you a more productive Camel rider.
I’ve been humming along using OS X 10.6 for the better part of a year now. For the most part, the tool suite I identified in my earlier post has served me well. Having just released a major project for a client, I decided now would be a good time to upgrade to OS X Lion. Considering that I am months behind the curve, I figured it would be simple and that any issues would already have been addressed by the blogosphere.
Everything went well except for getting a JDK with with source code and JavaDocs. This post describes how to get a JDK installation with source and JavaDoc after the upgrade or a clean install. Everything went well except for a couple issues. This post describes the issues I encountered with my environment. Continue reading
The OSGi specification defines appropriate bundle manifest headers and mechanisms for the deployment of servlet-based WAR packaged applications into an OSGi container. As with most APIs, programming a modern application using the Servlet specification requires copious amounts of boilerplate code that any number of Web application frameworks can reduce. The Spring MVC framework is among these Web application frameworks. As with many of the capabilities of an OSGi container, the hooks for integrating the WAR with the capabilities of the container, such as OSGi services; modularity; configuration; and class loading, requires programming copious amounts of boilerplate code to OSGi APIs. Unlike the world of Web applications, there are far fewer frameworks for simplifying deployment in an OSGi container. The Spring DM framework is among this small group. This article discusses how to leverage the Spring MVC framework together with the capabilities of Spring DM in order to take full advantage of the value added features of both frameworks. This article uses Apache ServiceMix as the target platform.
As you can probably tell from some of my previous blog posts on the subject of security, I’ve spent some time mired deep in the muck that is TLS configuration in the JVM. Over time, I have found that many libraries and frameworks provide poor support for customizing the finer points of TLS. The greatest offenders simply support global configuration through the JSSE system properties. Others allow you to specify a pre-configured SSLContext or SSLEngine but don’t allow you to easily configure the sockets that actually get used by the library or framework. Still others provide a slew of configuration options, unique to the framework, that are used to instantiate an SSLContext for you. While these solutions to configuring TLS are workable, they impose limitations on your application and require developers to learn different configuration mechanisms for every framework that they need to configure with TLS.
One of Camel’s greatest strengths is to abstract the complexity of framework boilerplate code away from one’s application. Unfortunately, when it comes to TLS configuration, Camel just wasn’t doing enough to prevent developers needing to configure TLS for a component from having to implement framework specific interfaces, learn framework specific configuration options, and generally curse TLS and JSSE. This observation coupled with a healthy does of frustration served as the impetuous for creating the JSSE Configuration Utility in Apache Camel.
The key goals of the configuration utility are:
- Provide a uniform framework for complete customization of JSSE/TLS configuration options from key stores, to algorithms, to protocols, to sockets.
- Provide an easy way to configure these options through code, Spring, and Blueprint.
- Provide extensibility to allow for the addition of future configuration options.
- Provide support for the configuration utility across a number of key networking related Camel components.
The JSSE Configuration Utility is available in Camel 2.8 and above. You can read about the capabilities of the JSSE Configuration Utility and see a list of components with support for the utility on the Apache Camel Wiki. Support for the new Camel Asynchronous HTTP Client component is planed for Camel 2.9. If you are looking for an enterprise-ready, validated, and supported distribution of Apache Camel, try Fuse Mediation Router which is based on Apache Camel.
I was recently dealing with some client concerns regarding package import scopes in their Maven-built artifact using the Felix Bundle Plug-in. The client was curious about strategies for dealing with package import version ranges as well as how to manage the creation of these ranges within their Maven builds. This article discusses some strategies for managing package import versions using the Felix Bundle Plug-in and the versioning related macros.
I recently acquired a nice 17 inch MacBook Pro to replace my not too old but way too bogged down Windows machine. I’ve primarily been developing in Java on the Windows platform for eight years. In that time, I’ve come across a lot of tips, tricks, and tools to increase productivity and generally make life easier. This post discusses some of the equivalent tips, tricks, and applications in OS X with a focus on free solutions.
If you have ever supported a client in the US Government, civil or otherwise, you have probably heard of the FIPS 140-2 compliance requirements for cryptographic operations. If you haven’t, stick around a little longer and it will eventually ruin your day. This article discusses how to use free open-source software to provide FIPS 140-2 compliant message-level security in Apache CXF’s SOAP over HTTP Web services.
This article builds on the setup described in my previous article Using NSS for FIPS 140-2 compliant transport security in CXF by adding a WS-Security compliant digital signature over portions of the message as well as using WS-Security to encrypt portions of the message. Refer to my previous post for details on FIPS and configuring NSS in Java.
These same features are also available in FUSE Services Framework, a freely distributed enterprise ready distribution of CXF available with various subscription options.
If you have ever supported a client in the US Government, civil or otherwise, you have probably heard of the FIPS 140-2 compliance requirements for cryptographic operations. If you haven’t, stick around a little longer and it will eventually ruin your day. This article discusses how to use free open-source software to provide FIPS 140-2 compliant transport layer security (TLS) in Apache CXF’s HTTP Web services. This article is also useful for describing the general steps needed to configure NSS as a security provider in a JVM.
Update: At the publishing of this article, PKCS#11 support within CXF’s HTTP/Jetty transports was only available in snapshot releases of 2.4 and 2.3.1. Now that CXF 2.3.1 has been released, the examples in this post have been updated to use CXF 2.3.1. This capability also appears in FUSE Services Framework.