Tribute to Contributors

During my life span of developer I have contributed patches, suggestions etc. that it is the spirit of the open source community. The path to the source is available to me as a client. Once in a while you discover a few gems from the source thanking the contributors. That of course brings a smile to the contributor that his work is appreciated.

Today I discovered a little gem from the past. The excellent EHCache has had recent activity so I was circling their website again, pointed in their direction by all the news sites, feeds and blogs.

Well the EHCache team has taken the time to list a page of the team members and the contributors. Really nice. Thumbs up. Some years ago I was also told by my former colleagues from e-ma in China that they had found a snippet in iBatis where Clinton Begin thanks me.

Now that the committers have ohloh as a kind aggregation of your contributions I have been thinking that there should be a similar service for all the contributors as well. Many of these contributors are the real heroes. They are out there working at the clients, in knee deep wrestling with the problems and knows where the pain is.

Now that I am an Apache Committer on the Apache Camel project I take all our contributors seriously and know what it feels like when the team behind responds.

So if you haven't contributed, well you work is appreciated and its nice to have its name out in the opening. So dust of your patches from the open source frameworks you are using, create a JIRA account and submit your contributions. We need all the feedback and hard work from the end-users, the contributors, you, the real hero.

Camel - Tutorial - Part 4

I am writing a longer tutorial for Apache Camel where we start from the beginning and take baby steps. I have just completed part 4, that is the first part to introduce the routing concept in Camel so we are really serious about the baby steps.

The new part 4.
And if you haven't seen the tutorial before check out the introduction.

Camel now has HL7 support

I recently committed a new component camel-hl7 to Apache Camel to support HL7 in terms of:
- the HL7 MLLP (Minimal Link Layer Protocol) for HL7 services over the network
- a HL7 parser for the ER7 format (EDI based) with the HAPI library.

At my current client HL7 is a quite common data format for data interchange in the health care industry. And as the Capital Region of Denmark we of course also use HL7 for integrations. However not many of the Integration Platforms out there has some kind of HL7 support.

As the HAPI framework is quite well used we don't have any doubts not using it, and as the HL7 MLLP is just a "plugin" to Apache Mina we should be well covered with the network stuff.

The camel-hl7 component will be included as of Camel 1.5 that currently is in progress.

I have since received a few mails from people in same situation where they had to roll out the own solution. They are looking with interest that we have this feature out-of-the-box with Apache Camel.

Personal milestone - 500 commits

As I posted a blog today I saw that my ohloh banner had the major number 500:



Just wanted to post a quick blog with the breakdown:
- WebWork (58 commits)
- XWork (66 commits)
- Apache Camel (376 commits)

- 4 kudos received
- 2 kudos given

Will be fun to see if or when I reach 1000.

CWSIA0084E - What planet is WebSphere from!

At my current client we are evaluating different light weight ESB frameworks, that is to be hosted on the IBM WebSphere 6.1 platform.

We have chosen the web deployment model for our integrations so basically we are building a bunch of .war applications that we deploy. Within these .war application we have the light weight ESB embedded.

Today it's Mule's turn and I am building a proof of concept mirroring an existing integration we have on our old heavy weight platform. This integration uses two internal JMS queues to store intermediate messages in a route path.

I have setup a project using Mule 2.0.2 with its different transports and among them mule-transport-jms for the JMS part.

All is dandy when I run the application out-of-container with my unit tests where we use Jetty and ActiveMQ. No problem there.

I repackage my application without ActiveMQ and setup Mule to use WebSphere JMS connection factory instead.

Kaboom. I get a CWSIA0084E exception. Great there is an unique token to use for Google search (IBM got that part right), however I immediately got disappointed as even Google had a hard time to find any links - 6 hits.

At the end I found this IBM article from a IBM person:
Quoting from the article:

"So when you get this error, the problem isn't a bug in your code, it's your entire approach. In a nutshell, if you want to run a MessageListener in J2EE, don't implement a MessageListener, implement a (can you guess?) messsage-driven bean (the JMS kind, which implements MessageListener). And if you don't like using EJBs? Get used to it. MDBs work in J2EE; MessageListeners don't."

So I am just asking what planet are IBM WebSphere from? Please not always be so strict to the spec any other container I have worked with allowed you to work with JMS from any deployment model of choice.

Well that is -1 for Mule and -2 for WebSphere. Unfortunately WebSphere will prevail.

Generate toString() bundled in IDEA 8

Great news. Jetbrains is now bundling my plugin into the IDEA distribution.

I received this mail from Jetbrains:

Hello Claus,

A couple of days ago we saw a post on your blog complaining about the breakage in our OpenAPI. While in general this is indeed a big problem, in this particular case we can offer you a great solution: bundling your plugin in the IntelliJ IDEA distribution. In this case we'll update your plugin code ourselves while doing the API refactorings.

If you agree, we'll move the plugin to our Subversion repository. It will of course remain open-source, and you'll of course have commit access to the part of repository containing your plugin.

Are you interested in this?

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

This is great news for the plugin. Jetbrains will ensure that it stays compatible with their future lines and the plugin was mostly feature complete anyway.

So after 6+ years of development of this plugin its nice to know that it have found a new home.

I want to thank Jetbrains for listening. Amazing they read my blog ;).
And of course all the people that have contributed to the plugin in any form, without you the plugin would have been so popular:

Contributors
- Bas Leijdekkers for initial port of plugin to IDEA 7
- Mike Abney, Spencer Goh and Tom Gaigner for contributing templates that have been inspirations for improving the default templates
- Martin Schmid for submitting java code for field chooser dialog used in earlier versions
- Roman Porotnikov for improving templates
- Glen Schrader for showing how to add this plugin in the generate menu (alt + ins)
- Igor Levit for implementing the conflict resolution policy code and improving the settings UI
- Vince Mallet for upgrading the plugin to various Aurora versions
- Dave Griffith for inspiration how to use Inspection by sneaking his great InspectionGadget plugin source code
- Rick Maddy for explaining how the migration to the new plugin repository works (the since-build stuff)
- Mark Scott for the hint how to set Veloicty to log in IDEAs log files.
- Sascha Weinreuter (author of Smart Introduce plugin) for UI code to the quick template selection list
- Mark Scott for the hint how to fix the indent of toString() in the generate menu honoring icons