Using Camel with ServiceMix Kernel

Gert has a great post on ServiceMix Kernel and Camel showing how easy it is to take ServiceMix Kernel, install Camel into it and then deploy a route using a simple Spring XML file. Nice job Gert!

Apache ServiceMix Kernel 1.0.0 released!

via Guillaume's post

Apache ServiceMix Kernel 1.0.0 has just been released.

Apache ServiceMix Kernel is a small OSGi based runtime which provides
a lightweight container onto which various bundles can be deployed.
Amongst the list of supported features, Apache ServiceMix Kernel supports:

• hot deployment of OSGi bundles, exploded bundles or custom artifacts (spring xml configuration files support is provided)
  
• services configuration stored as property files are monitored and provided as standard OSGi configurations
  
• a centralized logging back end supported by Log4J, ServiceMix Kernel supports a number of different APIs (JDK 1.4, JCL, SLF4J, Avalon, Tomcat, OSGi)
• provisioning of libraries or applications can be done using simple commands via simple xml descriptors
  
• native OS integration as a service so that the lifecycle will be bound to your Operating System.
  
• an extensible shell console to manage services, applications and libraries
• operations on the console can be done remotely via a secured and encrypted channel
  
• a security framework based on JAAS
• new instances can be created using a single command line

This release, with the detailed release notes, is available at:
http://servicemix.apache.org/kernel/servicemix-kernel-100.html.

I'm particularly pleased to get the 1.0.0 release out; it makes it really easy to have hot-redeployable Camel routing rules - just edit your Spring XML when using the expanded bundle mode and ServiceMix will auto-redeploy your routing rules dynamically!

Whats new in ServiceMix 4 and Camel

Rod Biresch has posted a nice blog post about what's new in ServiceMix 4.x which is definitely worth a read! 

Also Claus Ibsen has added to the collection of tutorials on Camel, this time on using Axis with Camel. Nice work guys!

better stack traces in Java with log4j - including the jar file and version number!

When problems occur in open source software users tend to get stack traces. They often fire them off to some open source mailing list or forum asking for help; often without providing much in the way of detail. One of the first questions asked by support teams is often 'OK, what version are you using'.

Given that its possible to figure out the actual version being used of each class - either using the package information from the MANIFEST or by finding the jar the class came from, it seems logical to include the version information into a stack trace at the end of the line.

One day the JVM might actually do this for us :)

In the meantime, I've created a patch for log4j to add this feature; it appends an optional String to stack traces printed via log4j which includes the jar file name if it can be deduced plus the Java Package version the line of code comes from.

Here's an example...

org.apache.log4j.config.PropertySetterException: Hello
at org.apache.log4j.spi.ThrowableInformationTest.testStackTracePackageName(ThrowableInformationTest.java:306)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [1.5.0]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [1.5.0]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [1.5.0]
at java.lang.reflect.Method.invoke(Method.java:585) [1.5.0]
at junit.framework.TestCase.runTest(TestCase.java:154) [junit-3.8.1.jar]
at junit.framework.TestCase.runBare(TestCase.java:127) [junit-3.8.1.jar]
at junit.framework.TestResult$1.protect(TestResult.java:106) [junit-3.8.1.jar]
at junit.framework.TestResult.runProtected(TestResult.java:124) [junit-3.8.1.jar]
at junit.framework.TestResult.run(TestResult.java:109) [junit-3.8.1.jar]
at junit.framework.TestCase.run(TestCase.java:118) [junit-3.8.1.jar]
at junit.textui.TestRunner.doRun(TestRunner.java:116) [junit-3.8.1.jar]
at com.intellij.rt.execution.junit.IdeaTestRunner.doRun(IdeaTestRunner.java:94) [idea_rt.jar]
at junit.textui.TestRunner.doRun(TestRunner.java:109) [junit-3.8.1.jar]
at com.intellij.rt.execution.junit.IdeaTestRunner.startRunnerWithArgs(IdeaTestRunner.java:22) [idea_rt.jar]
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:118) [idea_rt.jar]
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40) [idea_rt.jar]

So you can see what version of junit is being used (despite there being no manifest information) along with the JDK implementation version.
e.g.

at java.lang.reflect.Method.invoke(Method.java:585) [1.5.0]

means we found the package number but couldn't find the jar file but we found the implementation version of java.lang.reflect to be 1.5.0. Whereas

at junit.framework.TestCase.run(TestCase.java:118) [junit-3.8.1.jar]

means we found the jar file but the jar file has no manifest version information.

Am hoping one day this gets into some log4j release! You can find the patch here if you're interested.

am loving Beyond REST and the PIMP protocol

I really enjoyed reading Joshua Schachter's post beyond rest today - and particularly the comments. The basic idea is how to get a kinda publish/subscribe system to work on the web for processing real time updates to things like social sites at internet scale without introducing some really complex new protocol; but reusing the lovely RESTful web endpoints.

I posted a comment in the thread but figured it was quite big so figured I'd post it here too :)

I'm really liking the PIMP protocol and like Sam's strawman of using caching headers to implement it...

My suggestion is to think of this instead as another form of caching. All we really want is a header that tells the server that we are interested when a particular resource has been updated and how to tell us. The server can then either understand that header and acknowledge in the response that it will notify me. Here is my strawman:Request:
...
X-Cache-Callback:http://www.javarants.com/notify/joshua.schachter.org/atom.xml;SECRET
Response:
...
X-Cache-Callback: OK

Then if that resource is updated the service is expected to either HEAD the callback as a notification or POST the new contents of the resource, servers choice. You could later add semantics for merely updating the resource vs replacing it wholesale. I would also think about adding the ability for the server to specify a timeout after which you are free to poll again if you haven't heard anything on the assumption that sometimes the service may lose the state associated with your subscription.

Am thinking rather than returning OK the server returns the amount of time before the client has to re-issue the subscription to keep it alive. So the server can decide the maximum subscription time. Good PIMP servers (PIMPS :) might wanna make this quite long to reduce the polling overhead.

I also love the simplicity of the HEAD or POST to differentiate a notification of change to a notification-with-the-data.

I've long wanted a 'SUBSCRIBE' verb in HTTP for doing this kinda thing; but I think your cache-header approach is cleaner - as folks can either keep polling and/or subscribe for the update notification.

The nice thing too is that it allows easy migration to PIMP without introducing any overhead or new traffic; that clients continue to poll as normal - but they advertise themselves as being PIMP aware. Then eventually when one day the server becomes PIMP aware the clients receive their notifications (and then hopefully they scale back their polling :) - otherwise they can stick to polling.

Also webmasters can monitor their traffic looking for PIMP headers to know when it'll make sense to upgrade to PIMP. Not everyone is gonna need PIMP and it'll be a no brainer from looking at your logs to determine both when you've sufficient mass of PIMP enabled pollers along with knowing what the reduction in polling traffic upgrading to PIMP would save you.

I'm with Sam in the thinking of this as another form of caching. In implementing PIMP some folks might be able to create update notifications internally in their system when resources change to push out change messages into some kinda queue for posting to the callback URL. This would involve significant work for many sites though.

However it'll surely be pretty trivial to just install a PIMP-enabled caching web proxy inside your data centre in front of your servers - that does the usual cache thing, but also detects these extra PIMP cache headers and does a background poll of resources (respecting your existing cache & time to live headers) to detect changes both to update the cluster of front web caches (so non-PIMP pollers get more real time data) but also to drive the pushing of updates out to PIMP subscribers.

i.e. I can see this as a pretty easy upgrade to most web sites - folks just update their front end web proxies to a PIMP-enabled version and hey presto you can now support PIMP consumers. Am sure the web proxies could include an XMPP firehose too pretty easily for heavy hitters.

It should be pretty easy to hack the web proxies to do this I'd have thought? Even the problem thats been noted earlier in this thread - of trying to push updates to a URL endpoint might be slow, unresponsive or unavailable - the web proxies have to deal with already right in case a *local* server is borked.

Anyway - its a very interesting blog post and particularly the comments. Interesting stuff.

Running Nexus with launchd on OS X

I've finally got Nexus running for maven builds to help boost the speed downloading and checking repos etc.

This gave me the excuse to finally take a quick look at using launchd which is the preferred OS X way to run daemons and services. First look it appears cool and much nicer than rc/init.d/xinit.d et al.

Here's a really simple always-run nexus script, sonatype.nexus.plist. Just drop it into your ~/Library/LaunchAgents/ directory and you should be good to go.

From the command line you can then do this if you want to boot it up straight away - but it should restart on reboot (which I'll test out next time I've gotta reboot :)

launchctl start sonatype.nexus

I did try get clever and wait for port 8081 to be used before booting up nexus but couldn't get it to work properly so figured just starting it up on boot was easier :)

Update: BTW the script is available under the Apache License 2.0 if anyone wants to copy it or include it in any distro of Nexus

Neat eclipse templates for working with the Java or Spring DSLs for Camel

If you're an Eclipse user who works with Camel you might be interested in the Eclipse templates that Jon has just created - nice work Jon!

Another great Camel tutorial from Claus

Claus has done it again with part 4 of his excellent Camel tutorial. Check it out if you are interested in Enterprise Integration Patterns or Camel

Apache Camel 1.4.0 released with 261 new features, improvements and fixes

Claus beat me to it, so being lazy I'm just gonna quote his post :)

Just after 3½ months since release 1.3.0 of Apache Camel we have been very busy and have resolved 261 tickets.

Check out the release notes and go grab it from the download page.

If you are not familiar with Apache Camel then check out the FAQ or the Getting Started guide.

If you have more time and a fresh brew of coffee then I encourage you to read a somewhat different tutorial that focus on introducing Camel into an existing project step by step. The tutorial is work in progress, so check it out from time to time. The tutorial is based on a real life use-case.

If you have less time check out the regular tutorial that demonstrates how Camel easily work well together with Spring for message exchanges over JMS.

If you have questions about Camel then please check out the forums/mailinglists.

And then the answer to the mother of all questions about Camel.

There's tons of stuff in there. One of the most trivial changes to implement but one of my 'DOH why didn't we do that a long time ago' changes is the new tracer; very handy! Great work camel riders!

Incidentally its interesting to see how popular Camel is getting. For example looking at the Apache mailing list activity at nabble there's currently ActiveMQ in first place, ServiceMix in second and Camel doing a pretty respectable 7th behind Wicket, Maven, Struts and Lucene. Pretty good - particularly as its way above all of the Incubator projects combined (including a fair few that have graduated a while ago :), all Apache Web Services projects combined, Tomcat and Gerornimo etc

ActiveMQ, Camel and ServiceMix are doing pretty well in the Java software community rankings too

Are people blogging less?

Maybe its a bug with google reader or something but for the first time in ages my great and good folders of feeds I track (my kinda 2 tier way of keeping on top of blogs) are nearly empty. Do folks just twitter now or something?

Setting your bash command prompt to subversion or git repo info

I love this tip to set your bash command prompt to the svn/git repo, branch and version - its installed. Neat!

TimeCapsule & TimeMachine saved my ass!

My MacBookPro died on me. It kinda kept freezing so I did a hard reboot then after that it wouldn't boot at all :) Took it to the Apple Store; they figured out it was some kinda disc corruption; so wiped the disk (after managing to restore the files I was hacking on, bless that genius at the bar), reinstalled Leopard and things are OK (the disk may be faulty, we'll see soon).

Luckily the TimeCapsule had all my stuff so I could use the Migration Assistant to restore my apps & user accounts from the backup on the Time Machine. The UI did freak me out a bit - when the thing started it kept saying 'connecting...' then hanging for ages. I kept thinking it wasn't working so trying all kinds of things. Turns out, its just wacky slow. The next screen shows the list of user accounts - again thats wacky slow - takes maybe an hour for a 100Gb backup to show the few user accounts in the backup!

The 2 massive delays in the UI are kinda irritating; I mean why can't it keep a little index of what machines & users its got in the backup and let me pick 'em in a second then leave the thing for a few hours while it restores?

Anyway - all is well - once I got past the 2nd screen, chose the things to restore I left it chugging away for a few hours and I'm now restored. The only thing I've missed so far is I had to reinstall my VPN client as it shoved stuff in /System and maven is hardwired in /usr/bin to point to mvn 2.0.6 in /usr/share - other than that it worked fine.

One final tip if you try and restore from Time Capsule/Time Machine; when you reinstall Leopard don't create a user account with the same ID as the one you are gonna restore - as the Migration Assistant forced me to rename the restored one (which caused some problems that took me a little while and some 'chown'ing to fix :).

Other than those little gremlins; nice job Apple! If I ever have another catastrophic failure, the next restore should be pretty painless