Innovating with an Arduino: Traffic Light Noise Meter

The End Product

At Jive we have an open loft style development environment with great equipment and a great view of Mount Timpanogos.  We employ a lot of passionate developers and engage in a lot of pair programming.  While we do our best to use dedicated breakout rooms for discussions, the noise level in the office sometimes gets to be a bit much.  When our Scrum master cum culture coach announced an Arduino based hackathon challenge for the dev team, I knew what must be built.  A subtle device to provide a feedback loop for the noise level in the office.  Nothing says subtle like a 6-foot tall bright orange traffic light glowing red in your direction.

Integration Testing OSGi Bundles in Apache Karaf/ServiceMix with Pax Exam 3

This short post demonstrates a bare-bones configuration of Pax Exam 3 for testing an OSGi bundle deployed in ServiceMix 4.  Over the last couple years, Pax Exam and Apache Karaf introduced some fantastic features enabling the provisioning of a clean Apache Karaf distribution,  such as Apache Karaf itself, Apache ServiceMix, or JBoss Fuse, for integration testing.  In the past, I have manually configured 100+ facets of Pax Exam 1 to mimic an out-of-the-box Apache ServiceMix as well as written JMX based control code to provision an OSGi application into a stand-alone instance of Apache ServiceMix.  While both of these approaches enabled successful unit and integration testing, the features introduced since Pax Exam 1 make such approaches unnecessary.  These new features enable the provisioning of a Karaf distribution  with minimal configuration of Pax Exam.

While Apache Karaf and Pax exam both provide some example code around the features needed to provision a Karaf based distribution for testing, the code has recently shuffled between the two projects and it takes a bit of digging to get it all working.  The points illustrated below provide some tips in conjunction with the working sample project available in GitHub.  Building on the code here, and optionally incorporating the Pax Exam Maven Plug-in, one can create an elaborate set of integration test profiles for an OSGi based application or bundle.

Tracking Integration Test Coverage with Maven and SonarQube

While the combination of Maven, the Maven Surefire Plug-in, Jenkins, and SonarQube provide fantastic visualization and reporting of unit test coverage out of the box, these tools do not provide a configuration free out of the box solution for collecting and displaying the same metrics for integration test coverage.  Awareness of both integration and unit test coverage provides the development team and product owners with a more accurate picture of test completeness.  This more complete picture can be used to justify lack of testing in certain areas, identify risky portions of the code that are not tested in a production-like environment, and show trends in the quality/completeness of integration tests that were not previously measurable.  This article illustrates how a few simple changes to your Maven configuration can provide this valuable insight.

Intro to Camel By Example

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.

Integration Testing Web Applications

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.

Enhancements to Testing and JSSE Debugging in Camel 2.10

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.

How I learned to stop worrying and love OS X Lion for Java development

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.

Deploying Spring MVC Based Web Applications to OSGi Using Apache ServiceMix

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.

Simplified TLS Configuration in Apache Camel

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:

1. Provide a uniform framework for complete customization of JSSE/TLS configuration options from key stores, to algorithms, to protocols, to sockets.
2. Provide an easy way to configure these options through code, Spring, and Blueprint.
3. Provide extensibility to allow for the addition of future configuration options.
4. 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.

Secrets of The Felix Bundle Plug-in Macros Revealed

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.