Team bootstrap

As some of you may know, recently I changed my employer. I decided to start working for the pretty large american corporation - Pitney Bowes. We specialize in hardware and software solutions for automation and monitoring of postal processes and surroundings (printing, packaging, delivery and so forth).

I'm responsible for setting up and leading engineering team for Java development center emerging here in Poland (Bielsko-Biała). This is the very first Polish team outsourcing the US Pitney Bowes Global Technology Center. This is pretty exciting opportunity as I've been granted much freedom in shaping the form of the team being created here on the Polish site.

As I'd like to summarize my existing team leading experiences and confront them with the best practices of others, I decided to create this blog tag - team bootstrap. I plan to publish here my thoughts on building the efficient Java team with the strong engineering culture.

BTW If you...

• are available to work in the office in Bielsko-Biała (Poland)
• know Java
• would like to work on the challenging messaging-related project
• would like to work in the team with engineering culture certified by my humble person

...then you should drop me a line :) .

Getting unchecked result of Future with Guava

If you like Java Executor Framework as much as I do (and hate checked exceptions as much as I do), then you probably start to swear each time you need to handle all these annoying checked exceptions of Future#get.

Future<MyMessage> response =
  camelProducerTemplate.asyncRequestBody(
    "http://veryslow.com/esb/service",
    "request", MyMessage.class);
...
// Do something else waiting for the HTTP response.
...
try {
  handleResponse(response.get());
} catch (InterruptedException e) {
  throw new RuntimeException(e);
} catch (ExecutionException e) {
  throw new RuntimeException(e);
}

Handling checked exceptions of Future is especially annoying, as Executor Framework is widely used when implementing popular Request-Reply pattern in messaging systems.

Fortunately Guava's Futures utility provides glue code for handling Future#get exceptions. This extremely useful method is called getUnchecked.

import static com.google.common.util.concurrent.Futures.getUnchecked;
...
Future<MyMessage> response =
  camelProducerTemplate.asyncRequestBody(
    "http://veryslow.com/esb/service",
    "request", MyMessage.class);
...
// Do something else waiting for the HTTP response.
...
handleResponse(getUnchecked(response));

Thank you Google.

New JGroups component for Camel is out

Starting from the version 2.10.0 of Camel you can use new JGroups component.

JGroups is a toolkit for reliable multicast communication. The latter communication is usually (but not only) based on the IP multicast. I personally find JGroups-based communication extremely useful for clustering almost anything.

With new Camel component you can broadcast multicast messages to the JGroups cluster. For example when you save message to the persistent store, you may like to notify some other parties that they need to invalide cached data.

from("direct:persistDataEvent").
multicast().parallelProcessing().
  to("sql:insert into MyTable (column1, column2) values (#,#)", 
     "jgroups:MyTableCacheInvalidation");

On the other hand, when you need to listen for the multicast notification, you can use JGroups component on the consumer side of the route. For example to listen for the cache invalidation events you could use the route below.

from("jgroups:MyTableCacheInvalidation").
to("bean:myTableCache?method=invalidate")

Due to the licensing issues (JGroups is licensed under LGPL) this component is developed under the umbrella of the Camel Extra project.

And here are Maven coordinates for new artifact:

<dependency>
  <groupId>org.apache-extra.camel</groupId>
  <artifactId>camel-jgroups</artifactId>
  <version>x.x.x</version>
  <!-- use the same version as your Camel core version -->
</dependency>

Enjoy your ride with new Camel in our herd :) .

I'm full-rights Apache Camel commiter from now on

From this Monday I'm officially full-rights committer for the the Apache Camel (aka Camel Rider).

Why full-rights? Some time ago, when I started to contribute to the Apache Camel I've been granted committer privileges for the Camel modules not distributed under the Apache license (aka Camel Extra). Now I basically can commit everywhere.

Camel PMCs nominated also two other committers - Scott England-Sullivan and Raul Kripalani. Both of them are Camel/ServiceMix experts hired by Red Hat (previously by the Fuse Source). It so cool to be nominated to the committer in the companion of such open source rock stars :) .

Becoming a committer will definitely increase my contribution frequency rate :) . I got pretty long backlog with things I would like add to the Camel. Things that usually occurred to me during development of the projects with the Camel under the hood.

There is also one thing that is a pure Camel-research not related directly to my professional activity. Some time ago I've managed to start small Camel router on my Android device. I plan to create separated camel-android module in Camel Extra, where people interested in running Camel on mobile devices could contribute their code.

Anyway developing such top-notch project as Camel is extremely exciting and addicting :) . You should try it.

Minimal reasonable Fuse Fabric installation

If you're ServiceMix user, you need to be aware of the existence of the fancy piece of software from the FuseSource foundry called Fuse Fabric. Fabric takes deployment of the ServiceMix to the higher level of maturity. The ZooKeeper level of the maturity to be exact.

When you should seriously start to think about introducing the Fabric to your solution?

In my opinion you start to gain from the Fuse Fabric starting from the two ServiceMix instances hosted at two machines.

The minimal reasonable Fabric installation could consist of:

• Fabric Server and one child container on the first machine (A).
• Fabric container on the second machine (B). The container on the B machine is connected via SSH to the Fabric Server on the machine A.

You create parent Fabric profile with base configuration. The latter profile will be used to derive two child profiles for the containers A and B. The child profiles will contain machine-specific configuration (like endpoints addresses or singleton quartz tasks).

By introducing Fabric, you get the following advantages over the vanilla ServiceMix installation:

• the comfort of deploying the ServiceMix solution into the single machine (Fabric Server).
• clean separation of the shared and machine specific configurations (achieved via profiles).

ServiceMix: Autodeployment of the bundle snapshots

You can tell Karaf to scan your local Maven repositories for the latest version of the given bundle.

smx@root> osgi:install mvn:com.example/my-bundle/0.1.0-SNAPSHOT
Bundle ID: 227
smx@root> dev:watch 227
Watched URLs/IDs: 
227

Now whenever you install new version of the bundle to your local snapshot repository, Karaf will fetch the proper jar and deploy it to the ServiceMix.

smx@root> [Watch] Updating watched bundle: my-bundle (0.1.0-SNAPSHOT)

Good thing for fast system tests in the development environment.

PS Thanks to Łukasz Dywicki (aka Karaf-PMC-master) for a good comment.

LoggingErrorHandler support in Camel Scala DSL

Scala DSL for Camel is a little behind its older brother.

I submitted a patch to Camel Scala module, so starting from the Camel 2.10, Scala DSL supports loggingErrorHandler as well as the Java DSL does.

"jms:in"
errorHandler(loggingErrorHandler.level(LoggingLevel.INFO).logName("com.example.MyLogger")) 
to "jms:out"

And yeah, I also find Scala Camel syntax even more sexy than Java version. :)