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.