Looking at JBI and Camel

I've been distracted by doing a couple of webinars on Camel so I haven't had a lot of time to spend on digging into my original blog post on Camel, CXF, and ServiceMix / JBI working well together. From looking at the JBI spec it seems that for WSDL 1.x, JBI does 'mandate' using the JBI XML wrapper. My sense is that since I'm having the CXF components work with / generate from a WSDL 1.1, it seems reasonable that would wrap the XML message. The other ServiceMix components are magically generating the NMR / WSDL binding for me so apparently its up for debate if the must use the JBI wrapper element - if they generate WSDL 2.0, the wrapper element is optional.

From looking at the JMS and HTTP components, its clear that there is a framework in place using Camel interceptors to add the JBI or SOAP envelopes when needed.

At this point, I'm going to let the dust settle with Camel 2.0, ServiceMix 4.x, etc. before I dig in more on how to get Camel's jbi endpoint to do the right thing with that jbi message wrapper….

Setting up Nexus as a local Maven Repository Manager

I do a lot with Apache Maven, and I kept hearing about how Nexus helps with better managing your local Maven repository, especially if you go offline a lot, which I do. I was pleasantly surprised as how easy it was to setup and that it did actually seems to speed up my Maven project builds. Sad to get excited about a product that actually does what it claims...

My needs are pretty modest in regards to Maven, and most of the Maven projects I deal with are small, so normally dealing with annoyances of offline and/or configuring m2eclipse to know about the 2 other Maven repos I use isn't that bad. However, when I started trying to build all of ServiceMix (24+ Maven projects) and started to see lots and lots of waiting on downloading various dependencies, I decided maybe I'd see if Nexus could help.

The install of the Nexus Open Source is very straightforward - untaring a tar ball - and starting the Nexus server was as easy as bin/nexus start. Sonatype provides a great (free) on-line book on Nexus - Repository Management with Nexus - that provides good instructions on installation and initial configuration. There isn't much configuration by default except for modifying your Apache Maven ~/.m2/settings.xml file to use the Nexus server versus looking on the Internet for dependencies.

The biggest challenge I had was since I was dealing with a large project which references ~12 other Maven Repositories (Nexus ships with Maven Central and Apache Repos configured) I had to add in those other repositories into Nexus so it could proxy them. Again the Nexus book provides a great section on how to know your missing a repo entry and how to add custom repos into Nexus. After I did a couple, it was very straightforward to figure out the other 10 or so custom repos that ServiceMix requires.

What I saw was that now with Nexus it felt that the ServiceMix built went much faster - maybe 10-20 % - I guessing mostly from just quick all local machine lookups on dependencies. It also felt that Nexus was a little smarter about how it downloaded dependencies from the Internet, not positive on that. Regardless, I noticed a build speed up and a dramatic reduction in network traffic during the build.

I also saw that using m2eclipse was much easier, which makes sense since both Nexus and m2eclipse are developed by the folks at Sonatype. m2eclipse will use you personal Maven ~/.m2/settings.xml file, which in my case is now configured to use Nexus, so I automagically get access to all those custom repositories I already configured in Nexus without having to painfully add into Eclipse. This is nice as I can now lookup archetypes in non-Central based repos, and do the "so what dependency do I need to add for this Class" search as well on non Maven Central hosted dependencies.

Overall a positive experience. Nice work Sonatype!

Eclipse Galileo, 64-bit Java, Java 5, and Snow Leopard...

I thought I'd provide some details on the adventures I had in getting Eclipse Galileo (3.5) working on my Mac running Snow Leopard.

As detailed in this great DZone article by Zviki Cohen, Snow Leopard only ships with a 64-bit version of Java 6. In fact, if you upgrade from Leopard to Snow Leopard, the installer will actually uninstall Java 5 and replace it with symbolic links to Java 6.

This proved to by a challenge for my Eclipse needs as 1) you need to make a decision about which flavor (32 bit or 64 bit; Carbon or Cocoa) of Eclipse to install on the Mac, and 2) Eclipse gets confused by the symbolic link to Java 5 and thinks you really do have a real Java 5 JDK installed.

After reading the Dzone article, I decided to go with the 64-bit Cocoa version as that seems in line with where Java and Mac OS are going. Also, as I was going through my installation Eclipse Galileo SR 1 (3.5 SR 1) shipped which provided 64-bit Cocoa versions for all Eclipse profiles (JEE, Java, etc.). The SR 1 release eliminated many of the hoops Zviki talks about in this article, making it a much easier path to choose. After using this version of Eclipse for about a week, I'd say I don't notice a big difference from the 32-bit version, but it certainly seems stable and having it do builds with really big projects (ServiceMix) it seems relatively fast. I do notice my Laptop fan turning on and both cores maxed out, which overall I assume is a good thing as that means that its taking full advantage of my computer during a large complex build...

The next big task was fixing the Java 5 issue. This was an especial challenge / need for me since 1) most FUSE projects still support Java 5 and 2) m2eclipse (Apache Maven support in Eclipse) gets confused importing Maven projects that use Java 5 with Eclipse thinking its got a JDK 5 installed but really its Java 6 (see above note about Snow Leopard linking JDK 5 dir to JDK 6). This post at OneSwarm details how to hack a real JDK 5 onto your Snow Leopard OS. The highlight being

In the terminal:
Get the java 5 that was included in 10.5 "leopard" and unpack
cd /tmp/
wget http://www.cs.washington.edu/homes/isdal/snow_leopard_workaround/java.1.5.0-leopard.tar.gz
tar -xvzf java.1.5.0-leopard.tar.gz
Move it to your System java folder (password needed)
sudo mv 1.5.0 /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0-leopard

Tell OS X that java 5 actually is java 5
cd /System/Library/Frameworks/JavaVM.framework/Versions/
sudo rm 1.5.0
sudo ln -s 1.5.0-leopard 1.5.0

I also updated the /System/Library/Frameworks/JavaVM.framework/Versions/1.5 link to point to the 1.5.0 link for completeness.

After doing this I updated Eclipse to use the real JDK 5, and m2eclipse with my ServiceMix project built much better. Now I can do both Java 5 and 6 development on 64-bit Cocoa version of Eclipse - all nice and shiny new :-)

Now onto some real coding... :-)

First Try at Blogging - Digging into ServiceMix and Camel Code

Well, here's the classic "Its my first blog post" statement, so let's see how this goes :-)

I've been working with ServiceMix and Camel since Feb 2009 when I joined the Progress FUSE technical field. Now I'm looking to take the next step and start digging much deeper into the code. So I thought this experience of digging into the code would also be a code this to start blogging about.

The first thing I was going to look into is how some of the ServiceMix components handle messages with or without a JBI Message wrapper. Specifically, the CXF BC and SE components, by default, expect an XML message to be wrapped. The challenge is that messages sent from Camel via the JBI endpoint do not / can not be wrapped automatically (i.e. I'd need to code in the wrapping myself). Putting in a simple XSLT transform to wrap my XML messages in the minimal JBI message elements isn't a big deal, but its something I'd expect Camel to do for me (I am a lazy developer at heart :-) ).

Right now I'm getting my development environment setup so I'm working off the ServiceMix and Camel Subversion repos. I've also taken this opportunity to setup the Nexus Open Source version to help better manage interactions with the various Maven repos, and Nexus does appear to help speed up a full ServiceMix build.

Next steps are to find the JBI wrapper code in the CXF components to understand how they work. A big question for me is, it looks like the JBI Message wrapper is optional in the JBI spec, so shouldn't the servicemix-cxf components just handle the presence, or not, of the JBI wrapper automatically versus, by default, requiring other JBI components to do it? I understand that I can disable the JBI wrapper by setting useJBIWrapper=false on the CXF components, its just annoying that I have to disable something for many / most other components to interact with it.