James Strachan's Blog

Scalate 1.5.3 Released

2011-11-14T22:17:00.001Z

The Scalate team is pleased to announce the availability of Scalate 1.5.3

Scalate is a Scala 2.9.1 based template engine which can be used stand alone, with servlets or web frameworks like JAXRS, Lift or Play or in integration frameworks like Apache Camel.

The following template languages are supported through the same common API:

Ssp which is like a Scala version of Velocity, JSP or Erb from Rails
Scaml which is a Scala dialect of Haml for very DRY markup along with the Jade syntax
Mustache which is a Scala dialect of Mustache for logic-less templates which also work inside the browser using mustache.js

All expressions inside Ssp, Scaml and Jade benefit from the full power and expressiveness of Scala plus they are typesafe and checked at edit/compile time to ensure you don't leave any mistakes in your templates.

Scalate 1.5.3 Highlights

Scalate now uses the Scala Presentation Compiler to boost performance of template compilation 3-10X
Support for compiling stand alone CoffeeScript files on the server, CoffeeScript filters and various CoffeeScript related bug fixes
A pure Java API to working with Scalate

For more detail see the Full Change Log

Feedback is always welcome!

Posted via email from implicit.ly

Scalate 1.5.2 Released

2011-09-10T07:28:00.001Z

The Scalate team is pleased to announce the availability of Scalate 1.5.2

Scalate is a Scala 2.9.1 based template engine which can be used stand alone, with servlets or web frameworks like JAXRS, Lift or Play or in integration frameworks like Apache Camel.

The following template languages are supported through the same common API:

Ssp which is like a Scala version of Velocity, JSP or Erb from Rails
Scaml which is a Scala dialect of Haml for very DRY markup along with the
Jade for even more DRY Scaml
Mustache which is a Scala dialect of Mustache for logic-less templates which also work inside the browser using mustache.js

Scalate 1.5.2 Highlights

Server side compilation of CoffeeScript in the :coffeescript filter - many thanks for the patch Dag!
Provide a Scala 2.8.1 distribution of Scalate (version 1.5.2-scala_2.8.1) for easier Play integration and working with other Scala 2.8.x projects.
Minor improvements in the use of the ScalaCompiler to make it easier to support Lifty as a plugin inside SBT - thanks for the help and welcome to the team Mads
Fixed #260 : Scalate distro does not include all the jars required for textile support

For more detail see the Full Change Log

Feedback is always welcome!

Posted via email from implicit.ly

CamelOne and Scala eXchange were awesome!

2011-06-17T16:20:00.000Z

Its been a busy few weeks lately! 3 weeks ago we had CamelOne which was a really great conference; one of the best I've been to for a while. Great talks & conversations - loads of energy around the Apache Camel community. I'm already looking forward to the next one! We should have the various presentations from it online.

I got the chance to demo the new beta of Fuse IDE which is coming out soon; its packed with some really awesome features for working with ActiveMQ, Camel and ServiceMix. We're hard at work getting that ready...

Then yesterday I had the pleasure of giving the day 2 keynote at Scala eXchange in London. I had heaps of fun, met loads of the Scala folks I've only met online before (including Martin, finally!) & even managed to get a few laughs in my talk (mostly at JSPs expense I think :). It was a very similar conference to CamelOne in many ways; heaps of fun, loads of energy & passion around and lots of fun was had by all.

My keynote was on the Scalate template engine; there's details here or go straight to the slides or video. The samples I used in the talk are in github.

CamelOne, Fuse IDE, Fuse Fabric, oh my...

2011-05-20T11:59:00.001Z

I've been way too busy to blog for a while; will try to do better going forward.

A little while ago we released the GA version of Fuse IDE; folks seem to really like it. If you use Apache Camel I highly recommend you try it out - also check out Jon's recent article on it.

Since then we've been working hard on a bunch of cool new features for it; we'll be releasing the 1.2 beta next month & its gonna rock even more :). I'm hoping to demo some of the newer features of Fuse IDE in my keynote at next weeks CamelOne conference.

In parallel we've been working hard on Fuse Fabric, open source software for weaving your application containers into an easy to configure, provision and manage system. Have a browse of the user guide if you want to know more.

Hopefully see you in Washington DC at CamelOne next week?

speaking at QCon, TSSJS, CamelOne, Scala eXchange, oh my

2011-03-04T12:05:00.001Z

I've a fairly busy speaking time coming up in the next couple of months. Here's my current schedule...

QCon London, Wednesday 9th March @ 15:35 I'll be presenting "Take a Ride on Camel"
TSSJS Vegas, Thursday 17th March @ 10:00 "Apache Camel: Tales from the Leading Camel Experts" along with Claus Ibsen. I think I'm gonna be on the Other languages on the JVM panel at 3:55pm which sounds fun too
CamelOne in DC, May 24th not exactly sure yet when I'll be speaking but expect a talk or two and a demo of Fuse IDE at least :). I'll also be trying to get my copy of Enterprise Integration Patterns and Camel in Action signed by the authors - you're most welcome to try too! :)
Skillsmatter Scala eXchange in London Wed 15th-16th June.

More details of other FuseSource folks speaking here. If you're going to be at any of these conferences it'd be good to meet up and say hi!

Scalate 1.4.0 Released

2011-02-10T12:32:00.001Z

The Scalate team is pleased to announce the availability of Scalate 1.4.0

Scalate is a Scala 2.8.1 based template engine which can be used stand alone, with servlets or web frameworks like JAXRS, Lift or Play or in integration frameworks like Apache Camel.

The following template languages are supported through the same common API:

Ssp which is like a Scala version of Velocity, JSP or Erb from Rails
Scaml which is a Scala dialect of Haml for very DRY markup along with the Jade syntax
Mustache which is a Scala dialect of Mustache for logic-less templates which also work inside the browser using mustache.js

Scalate 1.4.0 Highlights

Upgraded to Scala 2.8.1
Added new SBT plugins for precompiling templates and site generation
Site generation is now available in the scalate command line tool and shell and it alsonow supports a simpler directory layout.
Added pygmentize, css, and cdata filters
Added Textile support and filters
Mustache can now be used for creating layouts and refer to parts of the generated template by navigating the html section.
Mustache automatically unwraps Option types.
Improved OSGi support

For more detail see the Full Change Log

Feedback is always welcome!

Posted via email from implicit.ly

Wanna try our Apache Camel developer tools for Enterprise Integration Patterns?

2011-01-28T17:45:00.001Z

When I first created Apache Camel one of my design goals was to let folks describe the Enterprise Integration Patterns as easily as possible using concise and declarative domain specific languages instead of reams of confusing opaque bean configurations. So whichever the developer prefers, a DSL in Java, XML, Scala, Groovy, Ruby etc. It was always part of the plan to actually have a visual domain specific language too and we've finally created one.

We're just starting the public beta of Fuse IDE for Camel, our Eclipse tool suite that lets you visually create, edit and configure Enterprise Integration Patterns easily using Apache Camel and its huge selection of patterns and components.

If you use Apache Camel or have always meant to give it a try then please install it, take it for a spin and see what you think. We'd love to hear your feedback on the tool & how we can improve it!

We've lots of things planned for the tool; this is just the beginning...

Camel in Action is complete!

2010-12-13T10:03:00.000Z

Just in time for Christmas, my fellow FuseSource colleages Claus and Jon have finished their excellent book, Camel in Action. Congratulations guys!

Its a great read & highly recommended if you have integration problems you want to solve with the best of breed open source solutions.

There's more history and background in Claus's post or to quote from Jon's post...

So we did it. Camel in Action is headed to the press! Time for beers and all that, but first a little blog post :)

I had to actually search through my mail to find out when I started on this project. Turns out I got involved mid September 2009 which puts the time in about 15 months. Claus started before that so his month count is higher - poor guy ;) So it was a pretty big chunk of time for both of us but not too bad for a technical book I'm told.

We set out to create something that the growing Apache Camelcommunity needed badly - a great reference for newbies and experts alike. I'd like to think we accomplished that goal. Seems the early access readers agree too.

Thanks to all who were involved in producing this book. We had tons of very helpful reviewers, Manning staff, and even multiple foreword writers - there were a lot of people involved in creating this other than Claus or myself. Of course, we officially thanked the folks involved in the acknowledgements section so be sure to look there if you helped out :)

I have yet to see anything other than a PDF copy of the book (which should be released tomorrow) so I'm really looking forward to when the print copies start showing up in 10 days!

Also, feel free to use the "camel50" code for 50% off when ordering through http://manning.com/CamelinAction

Festive beers to both of you! :)

Scala is awesome!

2010-10-26T12:29:00.000Z

I got caught unawares by Debbie from FuseSource with her video camera and she managed to get me rambling about programming languages and what I thought of Scala.

The sound is a bit quiet you might need to turn it up when Debbie's not talking :)

Here's the video or try it embedded below:

FuseSource has launched!

2010-10-25T15:04:00.000Z

Rob has explained the background along with Larry's interview and Dana's podcast much better than I could have.

From a personal perspective I'm really excited about the future of FuseSource; we're growing fast, have some amazing customers & a great team including the folks who created Apache ActiveMQ, Apache Camel and Apache ServiceMix and now we have autonomy so we can stay nimble & fast like a startup while we innovate and iterate to help our customers solve their integration problems with open source; all the while having the security of being backed by a large company. This is gonna be fun! :)

Scalate 1.3 Released

2010-10-08T10:42:00.002Z

The Scalate team is pleased to announce the availability of Scalate 1.3.

Scalate is a Scala 2.8 based template engine which can be used stand alone, with servlets or web frameworks like JAXRS, Lift or Play or in integration frameworks like Apache Camel.

The following template languages are supported through the same common API:

Ssp which is like a Scala version of Velocity, JSP or Erb from Rails
Scaml which is a Scala dialect of Haml for very DRY markup along with theJade syntax
Mustache which is a Scala dialect of Mustache for logic-less templates which also work inside the browser using mustache.js

Scalate 1.3 Highlights

Jade template syntax is now supported which is a dialect of Haml or Scaml
New Servlet Filter which allows more flexible mapping of templates in a web application. For example you can have the request /foo.xml automatically bound to /foo.xml.ssp if the template exists letting you easily implement views without requiring a controller or routing in your MVC layer.
JSP Converter helps you migrate your existing JSP web application across to Scalate
HTML Converter lets you migrate your existing HTML files easily to Scaml orJade for extra DRY markup
DRY template imports, values and logic thanks to Scalate Package objects which allow imports, values and methods to be shared across some or all of your templates to reduce noise inside your templates.
Site Generator lets you generate static or dynamic websites using templates and/or wiki markup together with exporting wiki content from Confluence wikis to migrate to using git/svn as your wiki content repository. You can also use a common bootstrap approach now across both static website generation and web applications - such as to configure wiki macros in a canonical way. We now eat our own dog food and generate this site using Scalate.
More filters and pipelines supported such as confluence as well as the existing markdown which are particularly useful for website generation (static or semi-static).
The Scalate Tool now comes with a full interactive shell with full tab completion to make it easier to use the tool either for ad hoc or interactive shell use.

For more detail see the Full Change Log

Feedback is always welcome!

Scalate 1.2 Released

2010-07-30T13:52:00.001Z

The Scalate team is pleased to announce the availability of Scalate 1.2.

Scalate is a Scala 2.8 based template engine which can be used stand alone, with servlets or web frameworks like JAXRS, http://scalate.fusesource.org/documentation/lift.html">Lift or Play or in integration frameworks like Apache Camel.

The following template languages are supported through the same common API:

Ssp which is like a Scala version of Velocity, JSP or Erb from Rails
Scaml which is a Scala dialect of Haml for very DRY markup
Mustache which is a Scala dialect of Mustache for logic-less templates which also work inside the browser using mustache.js

All expressions inside Ssp and Scaml benefit from the full power and expressiveness of Scala plus they are typesafe and checked at edit/compile time to ensure you don’t leave any mistakes in your templates.

Scalate 1.2 Highlights

Scalate now supports the Mustache template language which is a Scala dialect of Mustache for logic-less templates which also work inside the browser using mustache.js. Support for Mustache uses the same common Scalate API so it works with all the existing Scalate adapters such as servlets, JAXRS, http://scalate.fusesource.org/documentation/lift.html">Lift or Play and Apache Camel
Scalate is now built on top of Scala 2.8.0 final release
Scuery for jQuery style transformation of HTML or XHTML using CSS3 selectors
the console can be more easily reused in your application without using WAR overlays and templates can be loaded via the classloader to help make more modular web applications without relying on WAR overlays
improvements in associating different template languages to files/URIs/strings/streams in a more flexible API
various improvements in the accuracy of the mapping of scala compiler errors to positions in the template source file which are then shown and linked in the console

For more detail see the Full Change Log

Feedback is always welcome!

Posted via email from implicit.ly

FUSE Community Day in Frankfurt May 25th

2010-05-20T14:57:00.003Z

Along with Claus, Rob and others, I'll be speaking at the next FUSE community day. If you're in the area please do pop along and say hi.

It will be held on May 25th 2010 in Frankfurt, Germany. We start at 9:00 am and have a full packed day with great speakers.
At 4:30 pm its time for "evaluation" where you can join us for a drink and a "one-on-one" chat with the many great minds at FUSE and network/mingle with the other participants.

You can see the agenda which is listed on the FUSE site.

Get the latest news on Apache ServiceMix, ActiveMQ, CXF, Camel.

Hear from committers, founders like Rob Davies, James Strachan and Claus Ibsen and users who have successfully implemented Apache in projects.

Meet and network with peers at this free educational community day.

Date
25th of May

Time
9:00AM to 4:30PM

Location
Radisson Blu Hotel, Franklinstrasse 65, 60486 Frankfurt am Main

Who Should Attend
Developers, architects, engineers and IT managers

How to register
Use this link

Scalate 1.1 Released

2010-04-28T17:04:00.001Z

The Scalate team is pleased to announce the availability of Scalate 1.1.

Scalate is a Scala 2.8 based template engine which can be used stand alone, with servlets, in JAXRS, with the Play Framework or in Apache Camel. (Work on lift integration is in progress).

All expressions inside Scalate benefit from the full power of Scala plus they are typesafe and checked at edit/compile time to ensure you don’t leave any mistakes in your templates.

Two template languages are currently supported:

Ssp which is like a Scala version of Velocity, JSP or Erb from Rails
Scaml which is a Scala dialect of Haml for very DRY markup

Scalate 1.1 Highlights

Ssp now supports Velocity style directives for more concise looping and branching.
new Scalate Tool for creating new projects with Scalate more easily
improved API for working with templates from different sources (file, URL, Source, String etc) via the helper methods on TemplateSource object and methods on TemplateEngine which take a TemplateSource
easier to configure whitespace handling via the escapeMarkup property on TemplateEngine and RenderContext so its easy to configure markup escaping for an entire project or enable/disable it within templates.

For more detail see the Full Change Log

Feedback is always welcome!

Posted via email from implicit.ly

Scalate 1.0 Released

2010-04-06T19:09:00.001Z

The Scalate team is pleased to announce the availability of Scalate 1.0.

Scalate is a Scala 2.8 based template engine which can be used stand alone, with servlets, in JAXRS, with the Play Framework or in Apache Camel. (Work on lift integration is in progress).

All expressions inside Scalate benefit from the full power of Scala plus they are typesafe and checked at edit/compile time to ensure you don’t leave any mistakes in your templates.

Two template languages are currently supported:

Ssp which is like a Scala version of JSP or Erb from Rails
Scaml which is a Scala dialect of Haml for very DRY markup

Further information:

Feedback is always welcome!

Posted via email from implicit.ly

if you need an excuse for buying an iPad, try this...

2010-02-02T15:52:00.004Z

There's a ton of noise out there about the new iPad. One common response is folks finding it hard to justify buying one if you have a MacBook Pro and an iPhone.

So one thing I really like about the iPad (apart from the speed & bigger screen than the iPhone) is the gap around the screen - which at first I thought looked odd. Let me explain...

I'm constantly amazed by how easy the iPhone is to use, especially by people who've never really used a computer. My daughters have been able to use my iPhone for drawing & browsing photos for a long time (and they are 3 and 1 year old right now) - without me ever really showing them how. They just picked it up, played with it and figured it all out. (I might have shown them the two finger tap on the drawing app to change the pen). When they are a bit older and can actually read, am sure they'll feel right at home browsing too.

The biggest problem my daughters have found (particularly with my youngest, she was 1 year old in November) is holding the iphone without accidentally pressing one or more fingers on the screen - causing confusion in the multi-touch detection.

You've gotta be quite careful with an iPhone not to touch the screen while using it (something adults master quite quickly). So for kids, the iPad is gonna be so much simpler to use with its nice wide thumb/finger area when holding the device.

Lots of cars have DVD screens on the back of the headrests so kids in the back can watch movies while travelling. I can see iPad's being the long term replacement very soon...

So if you're a geek and need a reason to buy an iPad; just say you're getting one for the kids! Thats gonna be my excuse and I'm sticking to it...

Using SBT on your Scala Maven project for continous testing

2010-01-13T12:36:00.004Z

Continuous testing is the practice of rerunning test cases whenever you change source code. Its a great way to write code in a mostly test-first way and it gives you very rapid feedback as you change code.

It can take a while to rebuild & rerun tests on a Scala project when using Maven (and IDEs can be a little slow sometimes too when it comes to continuous testing and scala).

You can buy Infinitest as an IDE plugin which is triggered whenever you do a build. Though I've found the console view isn't great when running ScalaTests (there's no way to navigate to the code that fails) - and you have to explicitly hit 'build' when you're editing your code. I prefer tests to just rerun automatically (reusing IDEA's auto-save feature).

So another approach is to use sbt, the simple build tool for scala.

Installing sbt
I use 0.6.9 (or xsbt as its often called) so I can work with scala 2.8.0.Beta1-RC7 nicely. Basically download the jar and create script called 'sbt' or 'xsbt' if you prefer, then you can run sbt from the command line.

You can then run sbt in the directory of your pom.xml and it'll configure itself with whatever project & version you want to use and version of sbt/scala etc.

Setting up sbt for maven projects
For those new (like me) to sbt, here's a quick way to get your maven build converted to use sbt. If you don't have a maven build for your project you can skip this step.

To cut corners and not configure all the maven repos you want to use to download your dependencies, you can just let sbt reuse your local maven repo to find jars.

So create a scala file in the project/build directory. sbt will have created the project directory for you, along with a boot subdirectory but you will need to create the build directory.

Call the file whatever you like, such as project/build/Foo.scala...

import sbt._

class FooProject(info: ProjectInfo) extends DefaultProject(info) {

val mavenLocal = "Local Maven Repository" at
"file://"+Path.userHome+"/.m2/repository"
}

Now you can start sbt and update it to load all the maven dependencies from your project

sbt
update
compile

The first execution of sbt puts you in the sbt shell which has completion and help so you can find the various options available. The 'update' task loads & downloads all the dependencies from your pom.xml. Refer to the docs for more details on repositories and dependencies.

Now you've got your dependencies imported, lets do some continuous testing.

Continuous Testing
From the sbt shell just type

~ test

Now sbt will monitor your code, detect when its changed, rebuild and rerun all the tests for you showing the results in nicely colour coded output in the terminal.

When you fancy playing in the Scala interactive shell (REPL) just type

console-project

And you're good to go. Enjoy!

Have you figured out a neater way of doing continuous testing with IDEA and Scala?

I guess someone could hack a JRebel plugin for Maven so that you could use the scala:cc goal to incrementally compile your scala code as you edit it; then JRebel automatically reloads the changed classes, then the new continuous testing plugin would just need to use a trigger in the JRebel SDK so that when a class is reloaded it reruns the relevant test cases (or all of them - maybe sorted by previously failed ones first).

A similar technique works great when running projects with jetty:run or scala:console - letting JRebel reload any classes rebuilt via scala:cc

Update: using Time Machine on a network drive with Snow Leopard or Leopard

2009-12-16T12:39:00.005Z

I now have much simpler instructions thanks to Jon who commented on my previous blog post. Forget all those icky complex command lines! Here's the simple way...

download the CreateBackupVolume application from Jon's excellent backmyfruitup project
run it - tell it how big to make the sparse bundle thingy
a sparse bundle file then gets created on your desktop (the name of the file starts with your machine name)
mount your network drive if its not already
drag the sparse bundle onto your network drive (you can delete the local one)
set TimeMachine to use your network drive
wait :)

I've repeated the above now on 3 different macs including one old G4 and it worked like a charm each time. It seemed kinda faster than my previous Time Capsule too :)

Many thanks Jon! Using Time Machine with a network drive just got loads simpler!

Update: these instructions should work on any Mac with Time Machine, so it works just fine on Leopard too

Using a network drive with Time Machine on Snow Leopard

2009-12-03T11:49:00.006Z

I bought one of these after my TimeMachine died and figured it'd just work with Time Machine. After some messing about it still didn't work & I was left scratching my head so I started to look for backup software alternatives.

Then @dancres pointed me at these awesome instructions on how to do it. The only trick is the sparse band size needs to be changed on Snow Leopard as mentioned here.

So the only change from the above instructions is the big meaty command I used to create the sparse bundle was this (my changes in bold)...

HN=`hostname | cut -f1 -d.`;MA=`ifconfig en0 | grep ether | sed "s|:||g" | cut -f2 -d' '`;hdiutil create -size 350g -tgtimagekey sparse-band-size=262144 -fs HFS+J -volname "TM_$HN" $HN\_$MA.sparsebundle

Then rsync it to your network drive as per the instructions above and it just works - yay!

rsync -avE mymachinename_12345.sparsebundle /Volumes/Whatever

(in the above you use the real generated sparse bundle name, and the real name of your network drive volume :)

Fuse Community days in NY & SF next week - come hear about ActiveMQ, Camel and ServiceMix

2009-12-01T16:05:00.004Z

Next week we're hosting two Fuse Community day events in the states

Tuesday 8th December - New York at the Hyatt Hotel in New York City
Thursday 10th December - San Francisco at the Hyatt Hotel in Burlingame

If you're in the area pop by and say hello - you'll need to register on the above links.

We'll have a bunch of presentations on various popular open source Apache projects like ActiveMQ, Camel and ServiceMix. Schedule in the links above. See you there if you can make it!

Here's a flavour of what to expect, the devoxx talk I did recently.

a groovy scala example

2009-07-10T08:26:00.004Z

So my last post caused a bit of a stir (though some excellent comments!). Sorry about that! :) I think a few folks got the wrong end of the stick thinking my post was some kinda put down of dynamically typed languages. I still like Groovy/Ruby/JavaScript etc. I tried to focus the blog post purely on folks who were hacking statically typed code in javac; that Scala was a natural long term replacement which is a much better, powerful & more elegant statically typed language. If you've already stopped using javac and using Groovy/Ruby/JavaScript/Clojure/whatever then the post wasn't really meant for you as you don't need a javac replacement as you've already stopped using javac :)

Charles Nutter explains what I was trying to say way more elegantly

Scala, it must be stated, is the current heir apparent to the Java throne. No other language on the JVM seems as capable of being a "replacement for Java" as Scala, and the momentum behind Scala is now unquestionable

Anyway the reason for this post was to show how Scala is very Groovy based a nice example posted to the comments by James Iry. Here's the Scala code first

val (minors, adults) = people partition (_.age < 18 )

I'm sure most of you will agree its pretty clean, concise code and easy to read. It partitions a collection of people into two collections of minor and adults based on age.

Guillaume LaForge posted the Groovy equivalent

def (minors, adults) = people.split { it.age < 18 }

Notice how apart from some pretty minor surface syntax differences they are kinda identical to read. Mostly Groovy forces the dot between people and the split method (I think thats still true?) and uses 'it' for the default parameter name in a closure block rather than the Scala equivalent of _ if no name is specified. (Scala the _ is the wildcard symbol in various parts of the language as * is an operator on lots of objects like numbers).

So Scala and Groovy code can look about the same; nice concise, easy to read - describing the intention of the developer, rather than lots of noisy lines of code, or maybe ugly anonymous inner class noise using non-standard helper libraries to try simulate having nice core language support for working with very common data structures in a powerful expressive way.

There's a ton of Java libraries out there trying to tack on the ability to work with common collections & data structures in the modern Scala/Groovy/Ruby/Python/C#/VB way (dare I use the monad word here?) - I even helped create one many years ago. FWIW if you're stuck on Javac, do take a look at google collections which is really good.

My main criticism of these approaches in Java is they are non-standard (there's a ton of them out there - which to use?) and they are separate to the objects you want to work with. You can't just use a List, Set, Array or Map directly - you have to remember the separate class in a separate package you need to import so you can just do simple basic operations on data structures concisely. This kinda stuff is so basic, it should be a core feature of the programming language you use IMHO.

So both the Scala and Groovy examples above are a big improvement IMHO over their Java equivalents. I just wanted to demonstrate one of the additional benefits the Scala version has. While the code looks about the same, the Scala one creates immutable variables (which are great for concurrency) but the main difference is that the values are all statically typed. That means the compiler / IDE / documentation tool knows the exact types of the variables (minors, adults, people). Big deal I hear some of you say.

Well here's a handy example of why that is useful. Imagine you exposed this line of code as an API folks could invoke. Here's a PersonThingy object which defines a method minorsAndAdults as follows

def minorsAndAdults() = people partition (_.age < 18)

Now notice how the generated API documentation describes the return type of minorsAndAdults() as being (List(Person),List(Person)). i.e. you know its gonna return a 2 value tuple with a list of people for both values. This is very handy when you want to expose your code to other people; you don't have to write documentation (which gets out of date fast) describing what it is you return, the compiler can do all this for you. Plus when folks try to invoke your method their compiler & IDE will type check their code as they type it to ensure its used correctly (e.g. in case the user forgot to extract the first value from the tuple etc).

This also works nicely when using map. For example here is a little example which defines two methods greetings and lengths using the same value and a map method call but just using different expressions in the function passed

def greetings = names map ("Hello " + _)

def lengths = names map (_.size)

which return List[String] and List[Int] respectively.

So while dynamically typed languages and Scala can look as equally as concise; being statically typed can save you yet more typing explaining stuff the compiler/IDE/documentation generator already knows - and it avoids documentation going stale after refactoring - for example to change the data structure.

One closing observation. A common put down (usually from folks who've never read a good Scala book or really tried using Scala in earnest) is "oh its too complex". Yet the code you frequently write when working with objects, collections and data structures often looks very similar to the Ruby/Groovy/JavaScript/Python equivalents - yet folks rarely use the complexity word with those languages.

I wonder if part of the problem is, Scala & its community tends to describe Scala code and what the language is in terms of various (slightly academic) programming language concepts so that you can understand how the language works internally so advanced users can see how you can bend it to do what you need in a more concise & expressive way. For example back to James Iry's example

val (minors, adults) = people partition (_.age < 18)

That one example uses a tuple, pattern matching, a lambda, and partial function application. Describing how the language works tends to make it sound more complex (especially if you use the monad word) than just saying 'here's how to partion a collection'. If you were to take the similar Groovy/Ruby/Python code and tried to explain how the language actually implemented that line of code it would sound about as complex (often with meta object programming in there somewhere).

Scala is frequently described as a unification of functional programming and OO programming language concepts. A common push back from OO folks is, "I don't like functional programming, I just wanna do OO". Yet those same OO folks seem to really like closures, lambdas, for/list comprehensions and so forth. For example VB has lambdas, C# them too and has list comprehensions. Folks tend to really like them - whether they are developers using VB, C#, Ruby, Python, Groovy, JavaScript etc.

i.e. it seems most of us all really like an OO language with functional language features; we just don't like to think of ourselves as functional language developers :) Microsoft BTW is doing really well at turning C# and VB into OO and functional languages - but just avoiding using the 'f' word to avoid scaring folks off. I wonder if the Scala community should use the 'f' word a little less? :)

Scala as the long term replacement for java/javac?

2009-07-06T08:50:00.004Z

Don't get me wrong - I've written tons of Java over the last decade or so & think its been a great evolutionary step from C++ and Smalltalk (lots of other languages have helped too like JavaScript, Ruby, Groovy, Python etc). However I've long wanted a long term replacement to javac. I even created a language to scratch this itch.

Java is a surprisingly complex language (the spec is 600 pages and does anyone really grok generics in Java?), with its autoboxing (and lovely NPE's hiding in there), primitive types, icky arrays which are not collections & general lack of polymorphism across strings/text/buffers/collections/arrays along with extremely verbose syntax for working with any kind of data structure & bean properties and still no closures (even in JDK7) which leads to tons of icky try/catch/finally crapola unless you use frameworks with new custom APIs & yet more complexity. Java even has type inference, it just refuses to use it to let us save any typing/reading.

This issue becomes even more pressing with there being no Java7 (which is even more relevant after Snorcle - I wonder if javac is gonna be replaced with jdkc? :). So I guess javac has kinda reached its pinacle; closures look unlikely as does any kind of simplification or progression.

So whats gonna be the long term replacement for javac? Certainly the dynamic languages like Ruby, Groovy, Python, JavaScript have been getting very popular the last few years - lots of folks like them.

Though my tip though for the long term replacement of javac is Scala. I'm very impressed with it! I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.

So why Scala? Scala is statically typed and compiles down to the same fast bytecode as Java so its usually about as fast as Java (sometimes a little faster sometimes a little slower). e.g. compare how well Scala does in some benchmarks with groovy or jruby. Or this. Note speed isn't everything - there are times when you might want to trade code thats 10x slower for more productivity and conciseness; but for a long term replacement for javac speed is important.

Yet Scala has type inference - so its typically as concise as Ruby/Groovy but that everything has static types. This is a good thing; it makes code comprehension, navigation & documentation much simpler. Any token/method/symbol you can click on to navigate to the actual implementation code & documentation. No wacky monkey patching involved, or doubting of who added a method, when and how - which is great for large projects with lots of folks working on the same code over long periods of time. Scala seems to hit the perfect sweet spot between the consise feel of a dynamic language, while actually being completely statically typed. So I never have to remember the magic methods that are available - or run a script in a shell then inspect the object to see what it really looks like - the IDE/compiler just knows while you edit.

Scala has high order functions and closure support along with sequence comprehensions so you can write beautifully concise code. Scala also unifies functional and OO paradigms beautifully together into a language thats considerably simpler than Java (though the type system is of a similar order to truly understand than generics - but then thats usually an issue for framework creators rather than application code developers). It also lets folks gradually migrate from a traiditional OO/Java way of coding to a more functional way - which is particularly relevant for folks writing concurrent or asynchronous code (which due to the GHz of chips no longer going up but instead we're getting more cores is becoming more necessary). You can start the OO way and migrate to using immutable state if/when you need its benefits. Increasingly functional programming is becoming more and more important as we try and make things more concise and higher level (e.g. closures, higher order functions, pattern matching, monads etc) as well as dealing with concurrency and asynchrony via immutable state etc.

Scala also has proper mixins (traits) so you don't have to muck about with AOP wackiness to get nice modular code. There's even structural types in case you really do need some duck typing.

The thing which most impresses me is the core language syntax is pretty small and simple (the spec is about a quarter the size of Java's); but its way more powerful and flexible and is very easy to extend in libraries to add new semantics and features. For example see the Scala Actors. So its ideal for creating either embedded DSLs or external DSLs. There's really no need to have Java , XPath, XSLT, XQuery, JSP, JSTL, EL and SQL - you can just use Scala with some DSLs here and there (examples of this later...).

Scala does take a little bit of getting used to - I confess the first few times I looked at Scala it wasn't that pleasing on the eye - with Java you're kinda used to dumb verbose code which doesn't do very much - it can be quite a shock to see quite a few symbols at first. (It took me a while to get over the use of _ in scala which is the 'wildcard' symbol since * is an identifier/method).

If you've been doing lots of Java then Scala does feel quite different at first - (e.g. the order of types & identifiers in method/variable/parameter declarations - though the reason for that is to make it easy to miss out redundant type information).

e.g. in Java

List<String> list = new ArrayList<String>()

in Scala

val list = new List[String]

or if you want to specify exact typing

val list : List[String] = new List[String]

However if you keep at it, the beauty of Scala soon becomes apparent; its simplified so many of the gremlins in the Java language, allows you to write very concise code describing the intent behind the code rather than the implementation cruft - together with providing a nice migration path to elegant functional programming which is awesome for building concurrent or distributed software.

I highly recommend you take a look at Scala - with an open mind - and see if (once you're brain adjusts) you can see its beauty too.

Some scala links and online presentations

I can highly recommend the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners - its a great read and describes the features of Scala and design choices very well. Its a big book - but you can skip chunks and come back to it later.
I've only skim read it a little so far but the O'Reilly Scala book looks great too
the Tour of Scala is a good read if you're short on time and want a quick look at its syntax; though it can take a little while to truly appreciate why things are different to Java
Martin Odersky's Scala talk at JavaOne 2008
Jonas Bonér's presentation on Real-World Scala
Gert's presentation on how he created the Apache Camel DSL for Scala
speaking of internal cool DSLs try this blog post on program like you mean it with links to some other great internal DSLs for Scala
a scala version of LINQ for type safe querying of JDBC also check out dbc
a great presentation on using Scala and OSGi with DSLs
how to work with Scala and XML (kinda embedded XML, XPath, XSLT, XQuery in neat syntax in the language :) more here
Scala by example
Scala cheat sheet
an example showing how to create bean style properties (or C# style getters)
creating a chat demo using Lift or more on the Lift site

If you have a spare hour or so these video talks are great to watch

The Feel of Scala by Bill Venners
Scala: Bringing Future Languages to the JVM by Lex Spoon

Handy Scala frameworks and libraries

liftweb the rails of scala
specs and ScalaTest for BDD and more literate testing showing how a typesafe DSL can help you write more consise and expressive code that is very IDE friendly
scalaz a handy library of utilities
dispatch for working with HTTP/JSON services

BTW for those like me who love JAXRS you can now use lift templates with Jersey via the new jersey-lift module.

As an example of this in action you can check out RestMQ which is an open source project I've been working on lately to provide a RESTful API and web console to message orientated middleware which is built on JAXRS (Jersey), Scala and Lift.

From a tooling perspective there's Ant/Maven plugins, an interactive Scala console (REPL) and IDE plugins for IDEA, Eclipse, NetBeans along with the usual editors (TextMate/Emacs etc). The IDE plugins are not yet up to the Java grade, but they are very useful with good code navigation & completion.

I've tried the plugins for NetBeans, Eclipse and IDEA they all have strengths and weaknesses; it seems Scala folks are split between them all. For code navigation and completion along with maven support I've found IDEA to be quite good. When you open a Maven pom.xml it seems to grok the code nicely, finding the scala source so you can navigate through any type/method to see its documentation/source etc. (You do typically have to manually add the Scala facet to run/debug stuff). Though IDEA is not always the best at highlighting syntax errors as you type. They could all use some work to bring them up to line with their Java counterparts though - try them out and see which you prefer.

Scala nits
With any language there's gonna be bits you love and bits you're not so keen on. Early impressions of Scala do seem like there's a bit of an attempt to use a few too many symbols :-; but you don't have to use them all - you can stick to the Java-ish OO side of the fence if you like. But then I guess longer term its probably better to use symbols for the 'special stuff' to avoid clashing with identifiers etc.

I'm not a massive fan of the nested import statement, using _root_.java.util.List to differentiate a 'global' import from a relative import. I'd have preferred a child prefix. e.g. if you have imported com.acme.cheese.model.Foo then to import model.impl.FooImpl i'd prefer an explicit relative prefix, say: import _.impl.FooImpl which would simplify things a little and more in keeping with Scala's attempt at simplifying things and removing cruft (being polymorphic to import java.util._).

However compared to all the massive hairy warts in Java, these downsides of Scala are tiny compared to the beauty, simplicity and power of Scala.

Conclusion
Given that MrJava, MrJRuby and MrGroovy are all tipping Scala as javac's long term replacement, there might be something in it. So what are you waiting for; get the Programming in Scala book or the O'Reilly Scala book and start having fun :)

thoughts on the new @Inject JSR

2009-05-08T12:12:00.003Z

There's been some interesting feedback from JSR299 folks on the new @Inject proposal. (Though there is a bit of argument for argument sake in there :).

I can understand 299 folks wanting there to be just one spec that talks about IoC. However IoC is a large complex area that is still undergoing quite a bit of innovation (e.g. see the changes in Guice 2 and the JavaConfig which is part of Spring 3).

For me the great thing about the new @Inject JSR is that its small, simple and focusses on the common well understood part of IoC (the annotations you add to your objects so that popular IoC containers can inject your objects). This is the thing I most want - a standard set of annotations I can use everywhere in objects - then consumers of those objects can choose whatever IoC container they wish to wire things together be it Spring or Guice or a JSR 299 provider or whatever. The actual wiring code (in Java, XML or some other script/language) tends to be kinda small stuff relative to the tons of Java code for the objects themselves. Given the large variety and constant innovation in the wiring side of things, its probably a bad time to try lock that part down as I don't think there's consensus on how that part should look (though Guice 2 and Spring JavaConfig seem to get closer all the time).

299 however standardizes lots of things which only seem to be done in Seam; I don't see Spring, Guice or Pico implementing 299 any time soon as its a bit too big - however all IoC containers should be able to implement @Inject pretty easily; most IoC containers have already got something like @Inject in them today.

So as a practical kinda guy at heart, the best way forward IMHO to be able to write IoC container agnostic objects that can then be injected by Spring, Guice, Pico, Tapestry or indeed a 299 provider seems to be the @Inject JSR.

This doesn't mean 299 isn't useful; there's some interesting stuff in there particularly relating to eventing and JEE integration to IoC; but I see getting @Inject done and adopted by Spring, Guice & Pico (and hopefully the JSR 299 RI too!) to be most important for IoC in the Java ecosystem as a whole.

If you are using OSGi then give Pax Exam a try

2009-04-17T08:21:00.002Z

Pax Exam is a great piece of work! It makes it super easy to write JUnit4 tests which can then be run in multiple OSGi containers like Felix & Equinox using the exact bundles you require - plus it lets you inject BundleListener and so forth. Here's the tutorial which should get you started pretty quick.

I recently added an OSGi integration test to Apache Camel, here's the test case if you're interested. Notice how the versions of the bundles added to Felix and Equinox are not mentioned in this test case - they are inherited from the pom.xml from Maven.

The depends-maven-plugin from ServiceMix Kernel (soon to be Apache Karaf) generates the file target/classes/META-INF/maven/dependencies.properties which Pax Exam can then use to resolve the version dependencies of groupId/artifactIds. This lets you keep all your version information in your pom.xml and avoid having to update all your test cases whenever your pom.xml changes - keeping things nice and DRY!

Great stuff Pax-folks, keep up the good work!

Apache Camel switching from Java to BPEL, WSDL and RDF XML (with some XSLT)!

2009-04-01T07:38:00.005Z

The Apache Camel team has always strived to make complex integration challenges as easy as possible connecting pretty much all transports, protocols and middleware together easily using any of the enterprise integration patterns typically in a single line of Java code.

However our users have often said that Java is way too complex to understand. So to tackle that need we're dropping support for Java due to its complexity and instead we're switching to a combination of BPEL, WSDL and RDF XML Syntax instead (with maybe some XSLT too).

We're hopeful that a single XML document with 6 or 7 namespaces along with 2 or 3 spring ones should just about be able to route from one endpoint to another in a similar way to using a line of Java code - but using all the power of the various XML specifications; making it easy to add any WS-* specifications you fancy too!

One downside of this approach is that the XML header to define all the namespaces and their prefixes is about page or so of text but we're hoping a netbeans plugin will be completed soon that just hides the first page of your XML - making development much more agile!

We've also got a signed CLA on file so we can reuse Opera's new face gestures technologies to help typing in all those pointy brackets and XML namespaces; while giving yourself a great face workout at the same time. Agile integration and fitness in one!

More detailed design notes are available here from our new technical architect on the project.

Go Camel! :)

I met James Gosling last night & more on JWebPane

2009-03-19T13:08:00.004Z

James Gosling was giving a talk at BT on the future of Java (the evening was very well organised by Philip Milne - thanks for the invite & lovely curry! :) - and James is a thoroughly nice chap & much taller than he looks online :)

In the Q&A I asked, if he had a magic wand and could change anything in the Java ecosystem (platform, language etc) what would it be? His answer was getting WebKit into the Java platform via JWebPane! Awesome - go James! Along with closures in the Java language that would be mine too as I've mentioned before. Apparently work is still progressing on JWebPane - so despite the total silence for nearly a year, it may hopefully one day see the light of day. I just hope Sun releases something soon - it doesn't have to be perfect, then we can fix it in open source as a community.

I do wonder if the JWebPane guys have been a bit too ambitious for the first release (e.g. all the stuff about using Java2D and Swing JTextField widgets within a web kit pane etc). Just having a webkit panel which you can communicate with via Java & interact with the DOM via Java would be rocking! The other stuff I'm less sure on how important that is (e.g. the super tight integration of swing widgets with the DOM widgets - just being able to place swing widgets inside the DOM would be fine).

Incidentally I've been meaning to follow up from my previous post on webkit in the JVM. I got alot of great comments and feedback either privately or on the blog. Some were from Swing folks who didn't wanna touch all this new fangled web stuff with DOM/HTML/CSS/JavaScript. Thats fine - if you wanna stick to pure Swing please be my guest I didn't wanna imply we should remove anything from Swing.

For the others, they all pretty much agreed we need awesome browse integration in the JVM - it would open up a massive amount of potential for rich applications which embrace the web but work around the limitations of browsers (networking & security limitations) and above all the biggest issue with developing on the web - dealing with the zillions of ancient crappy browsers. Instead building rich applications on the JVM using a modern embedded webkit wouldn't have those issues & would make creating web apps way more fun :)

Quite a few folks replied with links to existing projects similar in scope to JWebPane which I should just mention...

JWebPane which hopefully will see the light of day one day, though its been eerily quiet for nearly a year...
Qt has a WebKit component in its UI library
SWT has a browser (FireFox) see the changelog and this eclipse con talk
CB4J bundles Chromium WebKit in a Java widget
Sage browser

I love competition; though I'd like to see a standard webkit component in the JVM and some consolitation though in APIs. I wonder if we could have some kinda JWebPane like API to interact with a 'Swing browser component' but let folks try different approaches to implementing that (e.g. using FireFox v WebKit etc)

JSR 299 (Contexts and Dependency Injection for Java) looks pretty good

2009-03-17T12:28:00.005Z

I remember looking at an early draft of what used to be called the Web Beans JSR and it kinda looked a bit like 'hey lets try standardize Seam'. It didn't strike me as being too relevant or useful to folks typically using Spring/Guice to build their applications.

However I've just had another look at the lastest draft and its now looking pretty good. The rename to Contexts and Dependency Injection for Java certainly helps.

Dependency Injection is such a cross cutting concern throughout the Java ecosystem - its also a very well understood problem space with a small number of popular implementations. We really should have a set of standard annotations for Dependency Injection above the basics in JSR 250 so we really can write framework agnostic code that can work in more than one DI container. So far JSR 299 is the best effort I've seen to try come up with a standard.

Ironcially the annotations used in JSR 299 are almost exactly the same as those used in Guice 2 (@Produces/@Provides, @Named, @BindingAnnotation/@BindingType etc). Also Spring has started adding more and more annotation based dependency injection support of late; so the various approaches are kinda unifying a little.

So with a bit of effort it should be pretty easy to implement the dependency injection parts of JSR 299 in both Guice and Spring; so then we'd have a real, useful, dependency injection standard working across all the main DI frameworks.

I wonder if the Spring & Guice folks will put petty politics aside and really get behind JSR 299 for the good of the Java ecosystem?

Apache Camel 1.6.0 released - 2.0 not far away!

2009-02-18T11:01:00.004Z

Both Claus and Jon beat me too it, so being lazy am just gonna link to their posts. You can grab the latest Apache Camel 1.6.0 release with its 169 improvements on top of the 266 improvements from the 1.5 version.

Get it while its hot! Work is progressing well on 2.0 which will hopefully be out soon too! Great work Camel Riders!

How Sun could fix Swing and promote innovation and unification in the UI space

2009-01-30T09:56:00.015Z

I saw Jonathan's post on Swing 2.0 and it was late, I'd had a nice glass of wine so I fired off a wacky idea on twitter which got some interesting feedback. I'd like to just expand on the background of the idea some more as I'm not so sure it is so wacky an idea afterall. Its feeling more and more like a no brainer and complete win win.

I'm afraid this post is gonna be quite long. (Holy crap - no blogging for ages and then two big posts in a week!) - first some background...

Programming Rich Java Applications Is Sucky
Imagine the scene. You're part of a team of Java developers; you're tasked to write a rich application. It might be a commerical app or some intranet enterprisey thing, or some rich application to improve the user experience of some web app (like the iphone versions of facebook/twitter/gmail etc) - whatever. So what do you do?

You've a mindnumbingly broad choice to choose from - here's just a few options...

Swing
SWT/JFace/EclipseRCP
web app with some combination of Ajax/JavaScript/GWT libraries
JavaFX?
Flex/Flash

Each have their own strengths and weakesss. Though they all totally different. Write for one of those then later on you're requirements change (making one of the other options more attractive) and you've gotta scrap it all and start over.

Write once and run everywhere - except if your application has any kind of user interface.

This is maybe why so many Java folks like writing server side apps; as the client side in the Java ecosystem is such a mess.

Helping Swing Developers
Lets imagine you pick Swing to develop rich applications. In its day, Swing was a good piece of work by Sun. However that day was in the nineties :)

I've done a fair bit of Swing in my time and worked on Swing projects; in my experience you can spend years trying to tart up a swing app and it still looks - well like Swing. You can get a day of a good web designers time and make any web application look stunning via HTML/CSS/images. It just seems so much easier to hack up HTML/CSS to look great. Just compare some great web 2.0 applications out there to your typical Swing UI. As an end user which would you rather use?

As a developer one of the big PITAs with Swing is layouts, styling and working with images and links. The standard layout managers suck. (GridBagLayout anyone?). Yes I know there's a zillion layout manager implementations out there - all doing different things well with different results & rendering bugs - and which one do you choose?

Generalizing hugely but most of the work that goes into most data entry-ish rich applications is creating loads of screens which are full of text, images, links and some rich widgets with plenty of documentation, popup help, cheat sheets and then laying it all out and styling it nicely. Swing is lousy at these UI basics. Sure its got a good JTable and JTree, something that many a web developer will probably have been envious of at some point or other when hitting gremlins in their JavaScript table/tree - but at laying out forms, dialogs, help screens, documentation and working with links and images - well its kinda sucky.

Swing developers should be using HTML/CSS for this - its great at it. The web browser is the best layout manager we have - and HTML/CSS is the best standard for laying out widgets. With HTML/CSS there's a ton of tooling out there too for viewing/editing/styling. You can then pass the HTML/CSS to your web designer while the Java Swing hacker focusses on the business logic or the complex widgets.

Plus any time you spend hacking HTML/CSS - being a simple, standard text format used inside web browsers means you can reuse your work in web applications as well as rich applications. You don't spend your time hacking up some Swing Java code thats only useful inside a Swing application.

My Proposal
So my proposal is, in Java 7 we integrate WebKit into the JVM. Why WebKit? Well its smaller and easier to integrate than Gecko; Apple chose it for Safari & iTunes and the iPhone and Google chose it for Chrome and Android. If its good enough for a cell phone surely we can fit it into a JDK/JRE for a rich desktop application?

If Sun wanted to get clever, the browser engine could be pluggable; letting folks pick different versions of WebKit or FireFox/Opera/IE - but lets not go there right now - lets just assume a recent WebKit version is baked into the JRE/JDK.

Some would argue it should be optional; but then given the size of the JDK/JRE there's a ton of not-that-useful stuff in there; I'd rather include it by default over loads of whats there :) But then the JDK/JRE is getting more modular right - so lets leave the optional nature of WebKit for when the JDK/JRE is truly modular - right now its huge; so if a cell phone can include it, so can a JDK/JRE :)

Next we have a standard Java API for creating a BrowserPanel which can be hosted inside any AWT/Swing/SWT/JFace based UI. So a browser window becomes a standard embeddable widget in Swing and SWT/JFace/Eclipse. There should also be an API for controlling the browser (loading/saving URLs and interacting with the DOM).

Finally I'd like any AWT/Swing/SWT/JFace/JavaFX component to be usable within the DOM of WebKit. So I could create a nice HTML page with nicely formatted and CSS'd text, images, tables but then include, say, a JTable and JTree in the middle somewhere; letting the browser do the layout stuff.

This last requirement might seem complex but thats exactly what Flash and JavaFX are already; plugins which create custom UI widgets within the DOM.

For those that are aware of GWT Hosted Mode; this proposal is very similar - embedding a web brower inside the JVM as a single process. The main differences are

we need a standard API to spin up browser windows and embed them inside any Panel and to be able to bind any UI Panel inside the DOM easily (e.g. finding a div by ID and binding it to a JTable)
we don't need the restriction of being able to turn the Java bytecode into JavaScript - as for standalone Swing/rich apps you can can leave it as it is :). So any Java code could work with the browser. So none of the GWT restrictions would apply - plus you could use Groovy/Ruby/Python/JavaScript/whatever

Benefits for Swing Developers
Swing would instantly get an awesome, standards based layout engine capable of easily rendering styled text, images and widgets while dealing with other kinds of media. Through the use of CSS Swing applications would be easily styled using all the existing HTML/CSS tooling.

Swing developers would then have the best of both worlds; their Swing widgets still working when they want to use them - but having the great power of the browser window around the widgets to make the layout easy, powerful and great looking.

Since the JVM would now have a standards based browser; and it can already run JavaScript (and pretty much all other languages) easily - any Swing application could make use of any of the current GWT or JavaScript frameworks out there. There's a ton of innovation happening in the JavaScript/GWT space right now leading to ever better UI capabilities. e.g. take a look at SmartGWT and jQuery to name but 2.

Benefits for Web Developers
So how will this move - aimed at helping Swing developers help Web developers? The common PITA for web folks is often the browser imposes restrictions (for good reason) such as

only being able to interact nicely with the single domain that serves the web page
not able to interact with the file system
only having 2 threads for communication
limited connectivity (kinda hard to use native sockets, Java web stacks, JMS, native JDBC etc)
unable to use things like Java2D/3D without via plugins

Plus there's dealing with the large number of different browsers of different capabilities & configurations & versions to support.

Now if you're making a public application; you're probably gonna have to deal with this (though now we're seeing custom apps for the iphone and android - maybe rich applications for public web sites are gonna be more common?). However loads of folks build web applications when they are really building internal, intranet applications.

So why not turn that web application into a desktop application making it run in a JVM? You can then package up your application with the exact, known browser you use and test with - and have access to all the features of the Java platform in your UI; whether its Java2D/3D, Swing/JFace, JavaFX or JMS/JDBC/JAX-WS etc

How this application is then made available to your users could come in different flavours; an application they install, Java Web Start (which might become cool again) or maybe even via JavaFX inside a browser?

So this could give a big safety net to folks building web applications. If you hit a browser limitation such as (say) a Canvas limitation? Just provide a Java2D version and ship a desktop application or Java WebStart it? It could end up that the JVM turns out to be the best place to host a web application reusing HotSpot?

Benefits for UI Developers
This single act of unifying the browser with Swing (and SWT/JFace) would provide a massive unification of standards based technologies for most UI development. More of the time spent building UIs would lead to creating more reusable standard artefacts (e.g. HTML and CSS) which are reusable in other contexts (e.g. transform HTML into PDFs or reuse the embedded microformats etc).

In these days of Dependency Injection; we're used to having a single code base then switching component implementations in different circumstances and environments; so we can start building more UIs which can be both web application and rich UI with each UI making the best use of its platform (zero install for web app, no limitations for desktop app).

Previously changing an application from a web application to a desktop application or vice versa was a massive undertaking (near total rewrite). Now it'll be pretty trivial to switch from one to the other as your requirements change. Applications will no longer be locked into one UI technology unable to move. UI code will become more aligned with the Write Once Run Anywhere mantra.

If folks create rich applications and web applications - there could be massive code reuse. While a web application and a Swing/JFace application are clearly going to have differences; they may use different views, components and features - there could be a huge amout of reuse of code. Even if the code reuse is only 30-50% its is big a saving; and we all need to do more with less these days. Though I can see - as UI frameworks improve, more and more chance of better code reuse across both.

Benefits for Sun
Folks have often said things in the past about Sun like

Sun doesn't get the desktop, its not its core business
Sun can't compete with Microsoft in its back yard (the desktop)

Sun is tightening its belt as is prudent for any company to do in the current climate. Sun has already de-funded SwingX. Also so far all the feedback and responses I hear from non Sun folks about JavaFX is at best lukewarm.

This move however would be a massive, positive move in the UI space and earn Sun a lot of kudos IMHO. Sun could then leverage all the innovation thats taking place in the browsers and WebKit in particular (HTML5, SVG, microformats et al) along with in the JavaScript worlds.

It would also mean there's not that much for Sun to do (other that integrate WebKit and provide APIs to control the browser and expose the DOM). All the innovation can then happen above this layer by the Swing, JFace & web developers and the WebKit & JavaScript communities. Immediately the Java ecosystem could then reuse all of the amazing work being done by the webby folks in JavaScript or by the GWT ecosystem.

i.e. the Java platform would then become a cool place to develop applications for (removing all the limiations with web browsers) with loads of buzz -and Sun doesn't really have to do much other than take all the credit :)

Heck they could even brand the WebKit-in-JVM as part of the JavaFX brand; so JavaFX doesn't have to beat Flash/Flex & Silverlight in the market to avoid looking like a turkey. JavaFX Platform (or whatever we call it - basically Java7 + WebKit) could turn into an instant success (anyone doing Swing or JFace would probably start using the embedded browser for better layouts & rendering) and if that helped the JavaFX Plugin (the JavaFX-as-browser-plugin) make some inroads to Flash/Silverlight its an added bonus. (Whereas right now JavaFX as just a browser plugin looks setup for failure to be honest, I don't see it ever eclipsing Flash).

Note its worth mentioning that there's similar moves to DOMs and whatnot being experimented with in the Eclipse ecosystem; who knows we could maybe finally unify on a single DOM?

Benefits for the Java Platform
Being able to build rich desktop and web applications in any language - without any browser limitations would be a massive boost to the Java platform; allowing folks to reuse all the good stuff from the OpenWeb and the Java platform (language diversity, IDEs and tooling, connectivity, Java2D/3D and even JavaFX).

We'd also hopefully see significant cross-pollination of the Swing / JFace folks and web folks to help UI innovation (which Sun doesn't have to try do itself).

If nothing else hopefully it will encourage more folks to write web applications and desktop applications to take advantage of both environments to provide better user interfaces for our users and customers for less effort.

Sounds like a win win for everyone doesn't it?

Update - JWebPane
So I should probably pay more attention to the JavaFX stuff :)

It seems that there is such a thing called JWebPane (see page 27 onwards of this presentation) which has been announced - so maybe this is gonna actually happen soon! :).

IMHO JWebPane sounds way more important to the Java ecosystem than JavaFX - I really hope it gets enough backing and funding from Sun to get completed and released real soon! Its not good to see nothing at all being released to the community despite it being announced about 7-8 months ago - so fingers crossed that whatever the legal/licensing issues are holding it back get resolved really soon.

We've just gotta lobby Sun to release it ASAP - then include it in Java 7... :-)

JAX-RS as the one Java web framework to rule them all?

2009-01-27T07:40:00.010Z

One of the things about Java that sometimes gets made fun of is the huge number of Java based web frameworks. There certainly are many, of all shapes and sizes! I suppose there are quite a lot of different shapes and sizes of web applications out there but it sometimes seems like there's a 1-1 mapping between applications and frameworks :).

Picking the right web framework is probably a managers nightmare (Which one to pick? Pick the wrong one and we might end up using a duff dead framework that few developers know etc?). But it has lead to a ton of innovation in the web framework space. On balance I think competition and innovation are good things.

I'm a big Rails fan, I think its a stunning piece of work and one of the most impressive open source frameworks created in the last 10 years which together with Ruby, Erb and Rake is a good alternative to Servlets + JSP + JSTL + Spring + Hibernate + WebFrameworkOfYourChoice + SiteMesh/Tiles + Ant/Maven + a few other bits all in a surpringly small and easy to grok codebase.

JAX-RS came along initially as a way of writing RESTful services on the Java platform; using annotations and loose coupling to bind resource beans and their public methods to URIs, HTTP methods and MIME content type negotiation. I've said before I think its awesome, one of the most impressive JSRs we've had.

From the perspective of the controller layer I actually prefer JAX-RS to Rails routes.rb & controllers as

the URI bindings are local to the resource beans which can be arbitrarily nested which makes refactoring much easier and avoids the complex routes.rb file with regex switches (I try and avoid regex whenever I can :)
the loose coupling between the objects returned by the resource methods and the actual entity providers is clean; helping the application programmer focus on returning DTOs and letting the framework deal with the XML / JSON /Atom / multi-part-form marshalling & data binding stuff really helps. e.g. its easy to drop in support for new representations in a DRY way without changing the code of your resource beans (controllers), you can just modify an annotation
static typing can be a handy thing when binding URIs and parameters to your controller. e.g. having String, integer, Date fields and parameters helps you having to explicitly convert things in your controller

There's lots of other stuff thats great in Rails though :-) but this post isn't a JAX-RS versus Rails post really - its focussing on the world of Java web frameworks for Java developers and the impact of JAX-RS.

So whats interesting is - if you want to build a web application with RESTful services (e.g. a human facing website with computer facing XML/JSON APIs) why would you use JAX-RS and another web framework? Why not just use JAX-RS as the web framework? So recently I've been musing, could JAX-RS be the one Java web framework to rule them all?

JAX-RS works well with dependency injection frameworks such as Spring, Guice, GuiceyFruit or JBossMC - you can basically pick whichever one you prefer. It also does all the heavily lifting of binding URIs and HTTP methods to resource beans and their methods along with supporting content type negotiation, headers and etags elegantly. For implementing great RESTful services in Java I've never seen anything close to touching it. The main question is what features are missing from JAX-RS being the main web framework?

Incidentally in this post I'm ignoring the server-side UI type frameworks like Wicket, Tapestry, JSF et al. I'm focussing on web frameworks that spend most of their time rendering HTML / XML / JSON and not building complex server side UI stuff and treating the browser as a kinda dumb terminal with the real UI work being done on the server side. Having had a horrid time using Tapestry and Hibernate together on some projects in the past, I'm kinda over the whole concept of server side UI web frameworks personally (I'm putting my flame-proof suite on now). I kinda think if you want to do complex rich web UIs, use wizards or complex flows, just use GWT or JavaScript on the client (or Flex/Flash for video or crazy highly graphical widgets) and keep the server side fairly simple and very RESTful. (But lets leave that discussion for another day... :)

In this post I'm only really considering frameworks like Struts, Stripes, SpringMVC etc. Thankfully WebWork and Struts merged together so at least there's been some consolidation in the space - and certainly Struts and Stripes are now kinda similar (and not too disimilar from SpringMVC). I wonder if JAX-RS will lead to further consolidation with web frameworks adding themselves as JAX-RS extensions?

So whats is missing from JAX-RS to be able to use just it for your entire web app and set of RESTful services and not have to use it with Struts/Stripes/SpringMVC and have to map some URIs into the web framework and some to JAX-RS?

Right now today there are definitely some holes; though currently I don't think there's that much missing. Here's my list of things I think are missing and how we could add them - I'm very interested in hearing if there's anything you'd particularly miss from Struts/Stripes/SpringMVC/whatever; please blog about it or post a comment and I'll do a follow up post!

Implict & Explicit Views
One great feature of Jersey is the support for Implicit and Explicit Views. Update: here's a link describing implict/explicit views. It basically allows the controller to delegate to the view layer (JSP/Velocity/Freemarker/GXP or whatever) using a default naming convention to find the template files in a directory named after the resource bean's class name and if required - the URI being requested. So a given Resource bean could have an index.jsp and edit.jsp templates for example - and referring to ${it.foo} inside the template would extract the foo property of the resource bean (you can override what 'it' is if you like but the resource bean is a very reasonable default).

Maybe the easiest way to understand implicit/explicit views is to look at the bookstore example in the Jersey distro; its basically the glue between JAX-RS resources and templates.

However there are some issues (which are being addressed particularly by the helpful folks on the Jersey list, particularly Marc and Paul) which basically revolve around having implicit/explicit views and (say) XML/JSON representations on the same resource bean using the same URIs and getting JAX-RS to pick the right one.

For example the URI "/customers" might return a HTML page for most web browsers but return XML/JSON if folks want to specify those MIME types in their Accept header. Right now Jersey tends to favour returning XML/JSON (long story but basically more specific URI paths are preferred over implicit views).

I'm pretty sure some kind of @ImplicitProduces annotation to allow implicit views to be associated to MIME types along with a higher priority/quality ranking specified in the next feature would solve pretty much all the issues with implicit/explicit views though am sure folks can think of other improvements...

Better Content Negotiation Support
It would be nice to see these issues resolved to be able to use RFC 2296 to be able to raise and lower the priorities (or quality) of the different representations.

e.g. you might want to prefer to return HTML over XML/JSON so unless folks ask specifically just for XML or JSON you return HTML.

Bizarrely Safari uses an Accept header of

text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

which kinda means it prefers to render XML over HTML (despite rendering XML as plain text! Truly bizarre - what was Steve smoking that day :). Most web apps I know of would rather return HTML by default :)

So you might want to specify something like this on a resource to declare that you want to return HTML by default for most users...

@ImplicitProduces("text/html;q=1.0")
@Produces("text/xml;q=0.5, application/xml;q=0.5; application/json;q=0.5")
public class MyResource {
...
}

Those MIME Strings could be static final constants BTW to keep things DRY and not have to repeat a ton of MIME expressions throughout your resource beans and making it real easy to add a new MIME type to your code without changing your controller methods.

You could argue the out of the box rankings for HTML should be 1.0 and XML/JSON something lower, say 0.9 or 0.5 as thats what most folks would want.

Dealing with static content
The Servlet spec is a tad smelly in this area (and even in servlet 3.0) of not easily allowing you to mark URI patterns as being handled by the container (e.g. for static content or for JSP files etc) and mapping all of the rest to your default servlet. Hopefully as Paul suggests we can get around this using servlet filters in Jersey; but it'd be nicer if there was a better fix for this. (Rails wins here hands down with using regex to map URIs to controllers). But this is more a servlet issue than JAX-RS / web framework.

Multipart support
Having support for Struts style form beans; binding a multipart to a bean is very handy. MrStruts himself has contributed jersey-multipart which goes most of the way there. Allowing direct binding with any bean to avoid having to use the MultiPart class directly would certainly help.

Standard JAX-RS client API like Jersey's
While not that relevant directly to web applications; being able to implement a REST service by invoking other RESTful services - or being able to test easily any RESTful service using an API like Jersey's client - while reusing the cool entity providers on both client and server side - would rock.

GWT and JAX-RS client integration
If you're building JAX-RS services and want a rich web client then GWT is a great solution; you can reuse all your Java code on the client and server side and its very easy to debug the whole application in a single JVM in your Java IDE.

GWT ships with its own RPC mechanism and there are various REST libraries for GWT such as gwt-rest it'd be nice if there was an easy way to reuse the same DTOs used on the server side like you can with Jersey's client library from inside GWT. Using JAXB inside GWT is probably non-feasaible :) but it should be pretty easy to just use GWT serialization and then support it as an entity provider in the JAX-RS runtime. (Is there a MIME type for GWT serialisation I wonder :).

Basically as an application developer it should be trivial to be able to reuse RESTful resources in JAX-RS inside the GWT client reusing all those DTOs if you want to.

Update: some other suggestions
Julio Faerman mentioned on the Jersey list mentioned the need for better validation. So maybe we could integrate the validation layer from Struts/Stripes into JAX-RS? Or use the the Bean Validation API (JSR 303)?

Also Julio and Jon in the comments mentioned the need for managing conversational state so integrating Web Beans (JSR 299) as an option for bijection of conversational state on resource beans sounds a good possibility.

What else?
Those are the things I can think of so far. Can you think of any others? What are there features in your favourite Struts/Stripes/SpringMVC/whatever framework on the server that you really can't live without?

I'd love to hear others thoughts; do you think I'm smoking crack or do you agree? :)

Apache Camel goes top level!

2009-01-20T10:45:00.003Z

Apache Camel is now a top level project at Apache - you can find it at http://camel.apache.org/. Yay!

Many thanks to all the Camel Riders who made this happen!

JAX-RS as the basis of a DRY web framework

2009-01-07T13:28:00.005Z

I'm with Sam that JAX-RS rocks and is a great basis for a RESTful framework for writing services. As I've said before, I think its the best JSR output since servlets and JPA. There's a great presentation by Stefan on it if you want to get up to speed fast.

I'd like to see something like the Jersey client standardised in JAX-RS - after all many restful resources are mashups of other resources and it makes testing of RESTful resources super simple. Also I love the implicit views in Jersey and hope they are kinda standardised some more; making the mapping between templates and resources more well defined across providers. But even in its current form, its great stuff.

Update: this is a good overview of JAX-RS I stumbled on the other day

Liking the File language in Camel 1.5.0

2008-10-14T10:39:00.001Z

Claus has a great write up on the new File language feature in Camel 1.5.0 - cool stuff! I'm really looking forward to the next release!

A favorite feature of mine in the next Apache Camel is a new feature to use file name patterns in the file component. What we have introduced is a new language, the file language, so you can leverage this feature anywhere in Camel where it uses Expressions, Languages etc. The file language currently support both the file and the FTP component as well.

As a lot of integrations is file based you need to be able to read (consume) or write (produce) files. Then you need to be able to specify file names. What's new in Camel 1.5.0 is that you can express this using patterns, for instance directly in the configuration of your endpoints. Prior you had to do this in Java code.

Simple example
Lets image you need to move consumed files into a backup folder after processing.

Now you can express this using the pattern: backup/${file:name}
Well then you need to use .bak as extension, and the pattern is:backup/${file:name}.bak

Okay next issue is that the backup folder should be grouped by dates using the yyyyMMdd pattern. Well the expression support thejava.text.SimpleDateFormat patterns also.
The pattern is:backup/${date:now:yyyyMMdd}/${file:name}.bak wherenow means current date. You can substitute this with different commands such as file for using the timestamp on the file instead.

Advanced example
In this sample you need to produce files (save) and you need to save the file using a generate unique filename. We use the divide and conquer pattern for this so you create a POJO class that generates the unique filename, then you as the developer have the full power how to do this. And then its very easy to unit test as its plain POJO that can be tested very easily with JUnit. Next step is to express this as a file pattern. As your POJO is a bean we use the bean langauge to invoke your pojo.

So the pattern is: myfile-${bean:myguidgenerator.generateid}.txt
Where myguidgenerator is the bean id of your POJO and generateidis the method name. You can omit the method name if there is no ambiguity which method Camel should invoke.

Camel routes
This feature is configurable directly in camel routing on your endpoints. So what we can do now is:

from("file://inbox?expression=backup/${date:now:yyyyMMdd}/${file:name}.bak").to("bean:processFile");

The route will consume files and process the files in the processFile bean, that is a plain POJO class. After processing the files is moved (renamed) using the pattern in the expression. So the file is moved to the backup subfolder, for example: backup/20081014/report-october-2008.bak

More to come
Well there is a ton of new features and improvements in Camel 1.5.0. Check out the current release note.

Using Guice as a JNDI provider

2008-10-09T11:51:00.005Z

In many ways a Dependency Injection framework is a replacement for looking things up in a registry like JNDI; but sometimes having some kind of registry or JNDI provider can be useful such as if you want to work with JSR250/EJB3 or some legacy code which expects JNDI to be used - or you want to use JNDI as a kinda loosely coupled registry between completely different modules of your system.

I've hacked up a simple JNDI provider which just uses Guice to create all the objects; so you stick to pure Java code for writing your Guice Modules to depenency inject your objects together then have a little properties file to enable/disable/tweak things.

When looking at Guice through spring-tinted glasses the most glaring difference (apart from the lack of XML) tends to be the absence of the ApplicationContext and a registry where you can look things up by name. This JNDI provider provides a more standard alternative to the ApplicationContext, as JNDI is in the JDK and it kinda gives you that crutch to lean on until you figure out the guicier way of doing your dependency injection :).

One neat thing is it combines JNDI naming with the @Named injection points in Guice and allows @Resource from JSR250/EJB3 all configured via the same jndi.properties file

Adding support for @PostConstruct, @PreDestroy and @Resource to Guice

2008-10-07T16:28:00.002Z

I do like guice as a Dependency Injection engine; I think it has a lot of promise; particularly if 2.0 is released soon :)

I still struggle sometimes, coming from a spring framework mindset, figuring out how to do some stuff. Though I love the @Provides support in trunk of Guice. Here's hoping 2.0 is out soon! :)

I've experimented recently adding support for ConstructorInterceptors into guice so you can add custom lifecycles like @PostContruct from JSR250/EJB3 or Spring's InitializingBean etc.

I've also created a patch to support closing of singletons such as via @PreDestroy or spring's DisposableBean.

Slightly more wacky is a patch adding support for custom injection point annotations which allows you to easily support things like

@Resource from JSR 250/EJB3
@PersistenceContext from JPA
the various JAX-RS annotations like @Context, @PathParam etc
WebBeans @In
Spring's @Autowire
Apache Camel's injection annotations like @EndpointInject or @Produce

Feedback greatly appreciated!

Enterprise Integration Designer preview

2008-10-07T10:59:00.003Z

From Oisin's blog.

Thanks to Enterprise Integration Patterns, architects have a clear and succinct way to describe integration within complex systems. It certainly beats a lot of MS-Word documents and monster integration architecture diagrams. And, with Apache Camel, we’ve got an open source runtime that allows us to create routes by chaining EIPs together, using Spring XML or Java fluent builders. That’s fantastic, but EIPs are as much about sharing pictures as creating message routing graphs, and where are the pictures?
We’ve made some tools that will allow you to load up Camel Spring XML files into Eclipse for visual inspection and editing. You can also create EIP diagrams in your Workbench and save them as Camel configurations. Finally, we’ve put in some debugging capabilities to allow you trace through the paths a message will take through your EIP graph.
We are earnestly seeking feedback - check out the FUSE Integration Designer Preview page to download the Eclipse plugins, or check out the video links under the Training Videos at the bottom of the page.

Looks great! Feedback greatly appreciated

Using Camel with ServiceMix Kernel

2008-09-29T10:33:00.002Z

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!

2008-09-18T12:56:00.003Z

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

2008-09-09T11:07:00.002Z

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!

2008-09-01T11:33:00.004Z

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

2008-08-29T10:21:00.006Z

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

2008-08-28T09:43:00.006Z

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

2008-08-27T17:00:00.001Z

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

2008-08-27T08:17:00.003Z

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

2008-07-24T10:04:00.003Z

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?

2008-06-23T18:53:00.001Z

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

2008-06-17T09:23:00.002Z

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!

2008-06-03T08:27:00.002Z

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

I'm liking JAX-RS and Jersey

2008-06-03T08:18:00.003Z

A great post by Paul Sandoz on MVCJ. Jersey rocks!

I'm loving the simple JAX-RS POJO based programming model (quite Rails-ish) for writing controllers and models which work beautifully in a hi-RESTful way which also now support a rails-like way of implicit templates via JSP/Velocity/whatever with a minimal amount of fuss.

I'm liking the controller-is-the-model-facade option with implicit MVC too; so the model is totally decoupled from the web and the controller just has a few annotations to deal with binding methods nicely to the URI/REST/content types and so forth - then you can have as many representations of a model as you want - just write views (e.g. index.jsp, detail.jsp, brief.jsp or whatever). Lovely and Rails-ish

Its now pretty easy to write hi-rest web apps in Java which render content as (X)HTML, XML, JSON with nice RESTful content negotiation and using good URIs.

Apache ActiveMQ 5.1 and Apache ServiceMix Kernel 1.0-m3 Released!

2008-05-14T17:28:00.004Z

Apache ActiveMQ 5.1.0 is now out. Both Bruce and Hiram cover this nicely - if you use ActiveMQ I'd recommend upgrading, its got tons of bug fixes.

Also things are really hotting up in the spiffy new OSGi based ServiceMix Kernel that has just released 1.0-m3. Both Guillaume and Bruce have the low down. Grab it while its hot!

Hopefully soon ActiveMQ may come built on ServiceMix Kernel by default which will certainly really help make it easy to hot-redeploy Enterprise Integration Patterns routing rules within the broker.

Squawk (simple queues using awk)

2008-05-12T18:56:00.002Z

I loved this article on using awk to work with message queues (via Apache ActiveMQ) by Andrew Birkett. Just shows you can be unixy and enterprisey at the same time :).

Getting hooked on twitter

2008-04-21T13:49:00.008Z

For a while I kept seeing twitter being mentioned and kinda thought: why would I wanna know what some random person on the internet had for lunch?

I just didn't get it. I'm not totally sure I do get it yet - but I've kinda convinced myself of twitter by just thinking of it as an open IRC where you subscribe to people rather than chat rooms.

To use messaging middleware speak, I've not been the biggest fan of IM as it tends to lead to loads of point-to-point conversations with lots of duplication. I find myself saying the same thing again and again to people on IM. Plus IM feels way too invasive; I tend to hide away from IM to avoid getting hassled these days :). With IRC I can say stuff to the room instead which avoids me having to say the same thing again. Plus IRC tends to feel less invasive; I can read it when I feel like it but otherwise kinda ignore it

Twitter so far is kinda feeling like a combination of blogs, IRC and SMS; where you subscribe to people rather than rooms which helps cut down the noise. If someone's getting annoying or boring, just stop following them. The brevity of posts (140 characters) also helps trim down the noise and fluff leaving a mostly interesting stream of kinda mini-blog-posts and banter. So far I'm hooked! :)

If you are on OS X try out twitterific as a Twitter client. While IM is a pretty reasonable way to work with twitter - I do like not running my IM client and using twitterific instead :)

If you have an iphone there's a bunch of clients available; so far I'm liking twinkle

Feel free to follow me if you like. Also check out twubble as a great way to find new folks to follow - nice work crazybob!

Google AppEngine is very impressive!

2008-04-18T13:47:00.008Z

After never having hacked any python before or looked closely at django and never having used BigTable, I spent a little over a day and managed to hack up, what is (to me anyway!)- is a very useful little web app I've wanted for a long time: http://latrz.appspot.com. Its highly scalable & available and resilient thanks to BigTable. Its kinda amazing really.

Sure Amazon has lots of similar stuff at the bits and bytes level. EC2, S3, SimpleDB and the new file system stuff are cool too, don't get me wrong. For some things the power and flexibility of the Amazon offerings are great.

Though for creating web apps I love how AppEngine takes all the hassle out of figuring out how to host, load balance, deploy and manage your app. I didn't have to mess with elastic IPs or DNS or web proxies or figure out some load balancing stuff, get scalr to work or install some ninja unix file system into a vmware image that mirrors itself onto S3 or anything. I just hacked up some simple python on my laptop, tested it locally with the AppEngine SDK, typed a command into my terminal (while on a train :) and within seconds its live on googles infrastructure and working really well.

I guess some web developers are gonna push back on the use of python but I'm sure google will release Java / JavaScript flavours of AppEngine soon making it not much of an issue. Who knows maybe even PHP too - not sure about Ruby though, I dunno if they've figured out how to make a ruby sandbox yet.

I'm sure ultimately this is gonna be a big game changer for those making public web applications; it takes so much hassle out of making web apps - and makes creating highly scalable & available web apps very rapid & fun. Well done googlers; I'm very impressed.

Latrz - a handy web app for reading stuff later (latrz)

2008-04-16T12:28:00.007Z

I've wanted something like this for the longest time! I've found when surfing, chatting online, working with email that I keep stumbling on loads of links to interesting stuff I wanna read - but just not right now - later.

I've often kept open loads of FireFox windows for stuff I should read soon (which then means I struggle to find what I am currently reading/working on from stuff I wanna read later). Then I've been through phases of cutting and pasting interesting articles into files/wikis for later. I've always felt this was sucky and wanted a nicer solution.

Now there's latrz and I confess to being totally hooked already :).

Basically if I'm on a page I know I wanna read, I click the Read Latrz bookmarket, then close the browser or carry on doing what I'm doing. Then when I've time I just click on the latrz site to read whatever takes my fancy, then mark it as read when I'm done to remove it from my reading list.

Go on, give it a try or subscribe to the Latrz Blog, you know you want to :)

Using Scala to create a better Camel DSL for Enterprise Integration Patterns

2008-04-16T12:23:00.003Z

Gert Vanthienen has been doing some amazing work creating a DSL for Camel using Scala. I'm amazed at how neat and concise it is. Go Gert! :).

I'd previously experimented with Groovy and Ruby DSLs and found them to be little more verbose (e.g. having issues of needing to pass 2 closures/blocks to methods like when or filter, one for the predicate and one for the block to execute if its true).

You can grab his slides from the recent ApacheCon talk. I'm really liking it. The Scala use of separate syntax for functions/predicates and blocks helps improve the Camel DSL hugely

Apache Camel 1.3.0 released with 208 new features & improvements

2008-04-10T10:37:00.002Z

Its taken a while to get there but we've finally got the new Camel 1.3.0 Release out of the door which includes 208 new features, improvements and bug fixes described below. Also as David has blogged recently we've MSMQ support now along with Esper and an Esper Demo. Many thanks to all those who helped ride this beast out the door. Enjoy!

improved Bean Integration
improved testing via Spring Testing along with the Mock, Test, DataSet components
browsing of endpoints via the BrowsableEndpoint with support in the JMS, List, Mock, SEDA and VM components
improved support for message exchange patterns such as InOut for JMS
various improvements in CXF, iBatis, Jetty, MINA components
improved XPath and XQuery support in Spring XML and with easier namespace configuration
default to more efficient JMS usage when working with Spring 2.5.x to avoid a previous Spring bug
various improvements in the DSL and with error handling
improved automatic Type Converter implementations
method invocations now supported in EL expressions
CXF transport API now supported in CXF component, you could leverage the power of Camel mediation in Apache CXF

New Components

AMQP
DataSet for easier load testing
JCR for JSR 170 support
List for UI and tooling integration
Stream for working with input/output streams
Test for easier functional testing
XQuery for easy XQuery based transforms for Templating

New Data Formats

CSV
XmlBeans
XStream

New Languages

Bean Language
JXPath

New Enterprise Integration Patterns

Load Balancer
Routing Slip

Please see Release Notes for more details. Download it now while is hot to trot!

[LazyWeb] a maven plugin to find resources on your maven dependency path

2008-03-27T18:06:00.002Z

Every now and again I get the dreaded log4j.properties / log4j.xml maven transitive dependency hell. Some resource is included in multiple jars so the one you think you're meant to be using isn't found first.

e.g. you try changing the log4j levels and nothing happens. Much scratching of head occurs. Normally through frustration you shove a load of System.out.println() calls in your app :)

So the idea is how about being able to do something like

mvn classpath:find -Dresource=log4j.properties

and the plugin would search all the test scoped jars on the classpath, including transitive dependencies letting you know all the jars (and the dependency path to them) which included the resource you specified.

It'd be handy right? Any volunteers... :)

Writing unit tests? Give hamcrest a try

2008-03-18T19:14:00.004Z

I'm not sure if its that well known but if you are writing unit tests in JUnit 3.x, 4.x or TestNG take a look at the tutorial, add hamcrest-all.jar to your classpath/project/pom.xml then give hamcrest a spin. I think you'll like it. Here's the pom.xml change...

<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-all</artifactId>
<version>1.1</version>
</dependency>

assertThat! :)

If you are tinkering with VMWare on OS X

2008-03-14T10:14:00.004Z

then a few links to save you a little googling. If you wanna use some of the public VMWAre images such as Ubuntu 7.10 desktop then you might wanna use BitTorrent to download it, then to unpack the RAR file try UnRarX. I've found the nicest way to use VMWare on Leopard is to run each VM image in a separate Space in full screen mode which is pretty neat...

UFace getting hotter

2008-03-07T12:01:00.002Z

Check out Tom's report on the latest improvements in UFace - pretty neat eh. Also using CSS cross web apps, Swing and Eclipse is hot.

Easier Integration & Pattern testing with Camel and Spring 2.5

2008-02-15T13:27:00.006Z

I'm really liking the testing features in Spring 2.5.x for easier unit testing with JUnit 3.8, 4.x or TestNG using Spring to do all your dependency injection before invoking your test classes.

I've just created a little document to show how to use Spring Testing with Camel, using the Camel Mock and Test endpoints for easier Enterprise Integration Pattern based testing. Incidentally Camel now has a new little Test endpoint which creates a Mock endpoint that automatically pulls its expected message bodies from another endpoint and auto-wires up the expectations for easier testing with minimal coding.

Public Training on Apache ActiveMQ and Apache ServiceMix

2008-02-15T13:23:00.002Z

As Bruce mentioned IONA is offering some public training courses on Apache ActiveMQ and Apache ServiceMix on the following dates for the first two...

London,UK - March 11-14
Waltham, MA - March 17-20

If you're using either ActiveMQ or ServiceMix then these training courses are highly recommended.

Using Apache Camel, ActiveMQ and Esper for Complex Event Processing

2008-02-06T18:05:00.000Z

David Greco just checked in a cute little demo that shows how to work with Apache Camel for Enterprise Integration Patterns, ActiveMQ as the message broker and Esper for Complex Event Processing. Enjoy!

Update: David bas blogged about this too :)

rest-ws looks great

2008-02-04T09:25:00.000Z

I've long been a fan of RelaxNG Compact Syntax (I guess RNC is the abbreviation) over XSDs. Now to avoid folks struggling with XSDs and WSDLs in nasty verbose angle brackets, there's the rather nice looking relax-ws. Now we just need a nice eclipse plugin... Enjoy!

[LazyWeb] using Subversion as a front end to Confluence?

2008-01-21T10:37:00.000Z

I hack a lot of Confluence spaces as part of my job. I've been working on the UFace project at Google Code so I've been getting used to the Google way.

One of the great things about google code is that the wiki is in subversion as *.wiki files; so you can edit them in any text editor (and TextMate comes with great MoinMoin syntax support, you just have to install the bundle...). So you can grab your wiki content, jump on a plane, hack it with your favourite editor then check in your changes when you're next online.

I wonder how hard it'd be to sync Confluence content with a subversion repo; so folks could still use the online Confluence site to edit content, which would get mirrored to an svn repo as *.wiki files - then folks could commit to the svn repo to update the confluence database? Anyone ever tried?

bored of your OS X desktop? Try DeskLickr

2008-01-18T17:03:00.001Z

DeskLickr rocks! Have your desktop change every few minutes/hours using a nice new picture from flickr using tagged queries. Neat!

Quick review of Leopard, the latest OS X

2008-01-17T10:27:00.000Z

I finally bought and upgraded to Leopard. Am liking it so far; Spaces is nice (though with a 30" and my 17" screens, I don't need many spaces, am mostly using a separate space for mail). The neatest thing of Spaces is when you use Expose to view your spaces (I'm using the move the mouse to the bottom right corner gesture), it shows both my 2 screens aligned for each space where I can drag and drop between both screens and spaces.

I love the new look and Cover Flow on Finder; don't much use the Dock as I use QuickSilver so the Stacks stuff doesn't get used.

I've gotta wait for me to buy a TimeCapsule before I can try out TimeMachine which does look cool. Apple are so good at sucking money out of my pocket :). Am gonna have to buy an Apple TV now too.... Wonder how long before they'll support the UK on movie rentals.

So far I still prefer iTerm to Terminal due to it being able to have preconfigured named shells & starting directories (I've often got tons of shells open).

The upgrade was great; I just installed the DVD, kicked off the install and came back later and it was all completed.

So far the only real nit was bash shells lost their prompt, so I had to add this to my .bashrc

export PS1="\w> "

Not an amazing upgrade or anything, but I am preferring Leopard.

Update : I've just noticed TextEdit now opens OpenDoc files natively - nice!

OpenSnoop is pretty handy!

2008-01-16T16:41:00.000Z

See the details of how to use it on Leopard. I just used it to track the progress of my S3 online backup which was most useful.

Develop rich UI applications in Eclipse/JFace, Swing, GWT, GWT-Ext or MyGWT using the same code via UFace

2008-01-10T21:58:00.000Z

UFace is hot! Its early days & needs more work, but check out Tom's post on UFace progress - or even better come along and join the fun :)

Apache ActiveMQ 5.0.0 Released!

2007-12-17T12:04:00.001Z

As Rob mentioned, its taken quite a while but I'm very pleased to say that the Apache ActiveMQ 5.0.0 Release has been made! Its packed with a ton of new features; I'm most happy about the awesome integrated support for Enterprise Integration Patterns via the Camel Integration. There's a bunch of other new features...

AMQ Message Store (Faster Persistence!)
Message Cursors (Producers don't block if you have a slow consumer)
Blob Messages
Command Agent
Enterprise Integration Patterns via Camel Integration
Logging a warning if you forget to start a Connection
Message Transformation
Mirrored Queues
Producer Flow Control

Apache Camel Integration Framework webcast tomorrow!

2007-12-10T15:23:00.000Z

If you fancy popping by, do checkout tomorrow's WebCast I'll be giving with Rob on Apache Camel, the Spring based Integration Framework and implementation of the Enterprise Integration Patterns.

I'll post a link to the archive once its available...

.Net, web browsers and Android should be certified Java Kernel platforms

2007-11-29T09:27:00.000Z

So I saw Why Microsoft Loves Google's Android (via Stefan) and I couldn't help thinking of the complete opposite position.

Imagine something totally different for a second. You're working at a software house making business applications for your users. You want your stuff to run everywhere, so you use Java on the server. Though you need to do some Office hackery, or maybe you wanna do some Windows specific Silverlight stuff or you've bought in to the MS hype about any day now the words really gonna go Rich Client so you better ditch Java and do .Net or else. So the .Net platform gets more tempting as a development platform to get all the MS crack.

So what do you do? Use Java and .Net and hire both .Net guys and Java guys then deal with rewriting code on both languages/platforms and training your folks on both stuff? Or have two different teams? Or just pick one standard language/platform/IDE etc. The temptation might be to go with more and more .Net - maybe even just .Net. And you know what - thats what MS want! To tempt you with all this Office / Windows / Silverlight crack so you stray from your nice open Java platform to be locked into this Windows / Office monopoly. They want you to leave the Java ecosystem and move over to the dark side.

However there's this thing called IKVM which is awesome - it effectively turns .Net into a Java Platform. Yes you read that right. You can take any Java bytecode and turn it into a normal .Net assembly of IL stuff and it runs like any other .Net thing. With .Net glasses on it looks just like .Net. However with your Java glasses on, its still standard Java code and it looks just like a Java platform. What IKVM does is take Java bytecode and translate it into .Net IL. For years its been able to run ActiveMQ (via Christopher Steen back in 2004!), Tomcat and yes, even Eclipse (think of all that native stuff in there for JFace, SWT).

Indeed with a bit of work (and particularly if Harmony and IKVM got together), .Net could actually get certified as a Java platform! Imagine that for a second. One of the main monopolies trying to tempt developers away from Java to lock them in to their proprietary windows/office platform could actually be a certified Java platform!

What would be really cool is if someone started to build open source APIs to abstract all the Windows / Office stuff using interfaces; so you could deploy on native .Net and use the real MS goodies - but folks could implement those APIs using open source or open alternatives like OpenOffice or Google Docs / Sheet or whatnot. i.e. remove the lock-in and reasons for switching to .Net.

I remember having a bit of a heated discussion with Graham Hamilton on this point at the first Sun Dynamic Language conference; his oppinion was that Java should remain 100% pure and be a single certified platform. I certainly see the value in this.

However another perspective to think of is the developer; and extending the Java platform to as many environments as is possible so that developers never have to leave the Java ecosystem even if they wish to develop on some platform which is not 100% pure and certified to run the "entire Java platform" - e.g. say you don't need AWT, Swing, RMI and CORBA. (Though now I work for IONA I now realise - CORBA rocks! :-)

As a developer in the Java platform ecosystem, its awesome to be able to use a Java IDE and tooling (with other languages for the JVM too like Groovy & Ruby etc) then deploy that same Java code on any certified Java platform plus these other huge platforms:-

.Net via IKVM which also means inside Office / WCF etc
inside any modern web browser without a JVM via JavaScript using GWT
as a C library using gcj so folks in unix/c land can use your stuff
on a mobile phone via Android on a platform optimised for phones

In each case today, these different platforms are huge and extremely useful. They extend the reach of the Java ecosystem (basically the bytecode) to run all over the place and avoid lock in by folks like MS to their proprietary platforms. They extend the reach of what it means to "write once and run everywhere" to more and more places including .Net, JavaScript browsers, mobile phones and shared libraries for C hackers. In each case, they take Java code written to a subset of the Java Platform and translate the code to run on another platform.

However today none of these are certified Java platforms.

Now lets talk a little bit about the "Java Platform"; its got a ton of stuff in there that noone really cares about any more. e.g. AWT / Swing is of no value to any of these 4 platforms I just mentioned. (I personally see GWT as a long term replacement for AWT / Swing / SWT)

The Java ecosystem is huge and diverse. IMHO core of Java (java.lang and java.util) should be separated out and made easily certifiable - say called the Java Kernel to indicate its the core language / VM only and not stuff on top like AWT/Swing/RMI/CORBA (that few folks care about any more).

Then we could say that any web browser with JavaScript, the .Net platform, C libraries and Android & mobile phones are all certified Java Kernel platforms; so there's not really any fragmentation like Richard thinks - and its a win-win for the Java ecosystem, extending the reach of the ecosystem to more and more places and further reducing the chances of fragmenting the Java ecosystems (since its not really a fork as Richard thinks - its just a smaller subset).

So I'm all for different platforms which might not support all of J2SE - but do support java.lang and java.util and the Java bytecodes - and I fail to see how tempting more and more folks to stick inside the Java ecosystem, whether its JRuby on Rails, Grails, Android, GWT or whatnot - is nothing but a good thing for the Java ecosystem and a very bad thing for the MS lock-in strategy.

While I'm on a long ramble - I thought I'd mention another of my long term irritations with this 100% pure approach. The Java platform (or Java Kernel platform :) should have amazing C integration for those rare cases when you really need it. There's a ton of great stuff available in native libraries only thats a total PITA to work with in the Java ecosystem. Platforms like Python, Ruby and .NET are still leagues ahead of the Java ecosystem at working with native libraries and sometimes you really need to. Of course we try to stick to 100% pure when we can but you know, sometimes the real world jumps in and we need to step outside the 100% pure mantra.

So in summary - I salute IKVM, gcj, GWT and Android - I hope more and more people figure out neat ways of expanding the reach so the same Java bytecode can run in more and more places than we previously thought possible.

Prism rocks! (Create desktop apps for web apps)

2007-11-26T14:15:00.001Z

Many thanks to Dejan who blogged about this - but Prism rocks. I can now use Expose / Tab to switch between Gmail windows and other FireFox/Safari windows. I've been using it for a day so far and am really liking it. I've often got a ton of windows open in safari/firefox and frequently just wanna switch back to GMail.

Changes I'd like to see

support multiple Prism executables to run concurrently. e.g. GMail, GoogleReader, GCal, JIRA could all be apps
allow the icons to be easily customized for when switching with TAB or adding things to the dock.

But so far, its looking good!

Update - many thanks to Dave Brondsema who mentioned in the comments that you can have multiple webapps running with custom icons using the provided bundes from http://wiki.mozilla.org/Prism#Bundles
Though I tried them and they didn't wor for me too well on the Mac (I've not upgraded to Leopard yet :)

ActiveMQ webinar archive available

2007-11-26T08:46:00.000Z

Our previously announced webinar on ActiveMQ is now available on IONA's webinar and screencast archive. You can view it here.

Nicer iPhone URLs for google stuff...

2007-11-26T08:44:00.000Z

I still prefer reading email via the web client for gmail on my iphone; for fellow iphoners, you might wanna try the optimised gmail client for mobiles. There's also a nice Google Reader specialised for mobile browsers.

More thoughts on RESTful Message Queues

2007-11-14T14:18:00.001Z

Just a small follow up on my previous Pure RESTful API to ActiveMQ via AtomPub. AtomPub rocks and all - I was thinking whats the easiest possible RESTful client to subscribe to a message queue.

GET queues/foo.bar?user=myUniqueId&timeout=5000

This would activate my subscription to the queue foo.bar (or help to keep it alive) and return my own list of messages as an Atom feed that I am allowed to view and DELETE when I have consumed them.

This operation is idempotent and would work great with proxies and caches (assuming the right HTTP headers / ETags stuff) letting clients to keep GETing as often as they like. Though if you don't use the subscription for period of time, your subscription can go stale and timeout; any messages in your message collection could be removed.

The slightly smelly thing here is we need to either use cookies (such as for HTTP session handling with servlets) or use a custom session ID header in the URL to uniquely differentiate the subscriptions. Anyone got a better idea?

I guess we could demand that clients PUT/POST to get a new Location URL on which to GET their subscriptions; but this would require a custom REST client.

Feedback on my Camel talk at the IJTC conference

2007-11-13T15:30:00.000Z

Thanks to John for the great feedback on my Camel talk (and other talks too). I started to write a huge reply and figured I'd post it here instead then link to it as its easier to reply to different parts.

Camel itself is not an ESB per-se, it is a component of an ESB

Agreed. The idea is Camel does the routing and Enterprise Integration Patterns - you can then use it inside a web service stack like Apache CXF, a message broker like Apache ActiveMQ or an ESB like Apache ServiceMix

1. One of the key messages that came out of the session was how Java-centric the Camel solution is - Strachan went so far as to articulate the view that coding in XML was a fundamentally bad idea.

Maybe being the author of Jelly and hating writing XSLT has made me a bit too sensitive to the idea of programming by XML. Quite a few customers I talk with report frustration of too much XML hacking with Spring (which is being addressed in Guice and Spring 2.5). But heck if you like programming in XML be my guest :)

He went on to cast aspersions on graphical tools also. His clear preference was that integration logic should be written in Java. Given that I have worked with highly skilled Java developers for many years now I was not too surprised to hear this - many good developers shy away from tooling, seeing it as compromising their style or the power of the underlying framework - hence the longevity of vi and emacs I suppose.

I didn't mean to cast aspersions on graphical tools; more that pretty much all developers understand Java these days, its pretty universal - whereas most complex graphical tools require a fair amount of learning to get used to them.

Personally I totally prefer writing in Java rather than XML or using visual tooling but one of the main requirements of Camel is that you can configure and specify routes in any way you like - via a graphical IDE (e.g. Cimero) or via XML or Java or Groovy or Ruby or one day hopefully a real DSL. Using XML is quite useful as you can just drop your routing rules inside a spring XML file such as inside the Apache ActiveMQ.

So we're working hard to allow folks to specify routing rules however they like - despite what I prefer :). Irrespective of how you write your routing rules, we can visualise them so anyone can easily understand them.

However it is important to note that all developers are not middleware experts and have no wish to be. Indeed the enterprises they work for want their developers to spend as little time and effort as possible on middleware plumbing. They need and demand tools which will enable them to get at least 80% of patterns done without having to understand the middleware architecture, it's threading model,

Thats one of the main things we're trying to attempt with Camel - letting folks who are not middleware experts easily use the Enterprise Integration Patterns using a single line of Java code - using any transport or component with minimal configuration required.

it's support for configurable expression languages etc.

I find it hard to understand how any tool can be usable by folks without some kind of expression language that they understand - whether its Java or SQL or XPath/XQuery or whatnot. Even a visual query definer is a language that users need to know.

Most people express their requirements in a declarative way- I have data at A that needs to get to B, on it's way I need to perform transformation, validation, logging etc. (indeed the EIP book itself does this) . However Camel has taken a very Java centric approach and I think this increases it's complexity unnecessarily.

We are actually trying to be as declarative as possible - don't let the fact that you can use Java as the DSL confuse you. e.g. here's what you just described in Camel using a single line of Java code...

from(a).
to("xsd:org/cheese/something.xsd").
to("xslt:com/acme/mytransform.xsl").
to("log:com.acme.MyLogger").
to(b);

Its hard to be more concise than that in Java code. But sure - you could use some other language or XML or UI tool etc

2. Camel presents transports as nice-simple looking endpoint URIs in Java. However configuration of these transports may not be as simple as it seems. There appears to me to be a potential disconnection between the Camel processors and the Camel Components in terms of configuration.

You can always configure anything in Camel via Java or Spring; a component, endpoint, processor etc. The URI is just a shorthand notation for configurating things; which tends to work well with endpoints as usually all the smart configuration is in the component.

In the presentation processors use endpoints which can be configured using Spring within Camel. However it would appear that many of the component implementations are inherited from ServiceMix and these properties will need to be set presumably within the ServiceMix container configuration?

Not so - all the components are configured in Spring via Camel. If you want to talk to ServiceMix components and endpoints you can use the NMR and the JBI endpoint.

When you have multiple XML configurations to use a transport then the pretty looking URI is hiding a lot of complexity under the hood.

I hear you. We've tried very hard to make things as easy as is possible with minimal configuration; for example most configuration tends to be on the Component rather than the Endpoint. But you can configure things however you like in Java code or Guice or Spring.

3. Some of the pattern implementations look a little short on credibility - take the aggregator pattern for example the "aggregator" pattern does not seem to have the concept of a store - so in essence one must have access to all of the messages which require aggregation or must hold aggregations in memory for the configurable timeout period. This will clearly not work in a scalable way. Likewise as regards clustering - if you are looking to aggregate 2 messages and they turn up on different servers you gotta problem.

You're right I purposely missed out some of the detail on a few slides (such as specifying some kind of persistence store or strategy for aggregator or for idempotent consumer) but that is easily done via a pluggable strategies Spring beans. However just because I missed out some detail on some slides (its kinda hard in an hour to present all the detail in all the patterns as well as the rest of Camel) please don't think that somehow Camel isn't short on capabilities.

To summarise Camel is clearly a worthy set of widgets and they will work for very simple applications without Enterprise requirements.

Ouch :). We've actually lots of customers using Camel today in production with very Enterprise requirements. Apache ActiveMQ 5.0 actually ships fully integrated with Camel so we've tons of users in production using Camel today.

I hope I've managed to straighten out some misunderstandings on Camel; its definitely a great fit for enterprise requirements. Thanks for your great feedback - I'll definitely take it on board on future presentations and try and avoid confusing other folks :).

webcast today on Apache ActiveMQ

2007-11-13T13:33:00.000Z

Sorry for the really late notice - bad James! - but I'm doing a webinar today on Apache ActiveMQ with my fellow committer Hiram Chirino. Feel free to pop by and join us - or if you're snowed you can catch the recording later on.

my slides on ActiveMQ and Camel from last weeks Dublin Conference

2007-11-13T13:10:00.000Z

They are not that useful if you missed me talk, as they are low on bullet points and high on pictures :) But if you were there, here are the slides in PDF format...

a great presentation on REST, JAX-WS and JSR 311

2007-11-13T13:09:00.000Z

A great presentation from Stefan Tilkov on REST, JAX-WS and JSR 311; highly recommended.

Speaking at the Irish Java Technology Conference on Thursday and Friday

2007-11-05T10:34:00.000Z

I'll be speaking this week at the Irish Java Technology Conference this week on Thursday and Friday. My talks are

Do pop along and say hi if you're gonna be in the Dublin area this week.

s3sync rocks!

2007-11-05T10:14:00.000Z

I finally got off my fat ass and setup an offsite backup of all my photos and other documents on Amazon S3. S3 is very impressive; very quick to setup and get going. I guess I'll find out in a month or so how cheap it really is :) but on paper it does look pretty cheap.

This article was a great overview of how to create backups using s3sync which is a ruby version of rsync which uses Amazon S3 under the covers. Neat! Add a little Anacron and hey presto, incremental online backups on all the macs in my house; and my wife won't kill me for loosing all the pictures of our daughter :).

(Yes I know flickr might be a better online backup for pictures; I just figured I wanted a general purpose backup mechanism that backed up anything I fancy, not just pictures).

Johnny CORBA

2007-11-05T08:55:00.001Z

In case you'd missed it here's Johnny!

AtomPub services and auto-detecting the schema type of XML based collections & feeds

2007-11-02T06:40:00.001Z

AtomPub rocks, its an excellent way of building RESTful services that are easy to discover, consume & they avoid the developer having to figure out for themselves a nice RESTful protocol for reliably exposing resources with all operations being idempotent etc. (Most developers miss that bit out :). I like the extra constraints AtomPub adds above REST; less mistakes for us developers to make :)

The content of Atom feeds can be text, XHTML or XML (entries can also link to arbitrary media types too). When using XML for the atom:content, it might be nice to be able to discover the schema up front - which could help tooling / UIs / frameworks.

e.g. from the AtomPub service document when looking at each collection provide an easy way to get the schema document. I've been googling to see if anyone has done such a thing; I've not yet found an obvious answer.

One idea is to use content types; something like

<collection>
<accept>application+xml; type=someSchemaURI</accept>
</collection>

another could be to add a new kind of link to the feed

<feed>
<link rel="content-schema" type="application/relax-ng-compact-syntax" href="/schemas/something.rnc">
...
</feed>

I guess a tool could always just look at the content of the feed and look at the namespaces then do some out of band google search for schemas for those namespaces :) but it might be nice to be able to make it a little easier to auto-detect the schema - particularly as AtomPub has gone to great lengths to make everything else (system, workspace, collections, entries) easily discoverable and navigable.

Anyone else figure out a neat way to expose the schema of the XML inside the content for collections or feeds?

Apache Camel 1.2 Released!

2007-11-01T07:19:00.000Z

We've recently released Apache Camel 1.2, take it for a ride! The release includes 61 new features, improvements and bug fixes such as...

Data Format to support pluggable marshalling and unmarshalling of data in various formats like JAXB, XML Beans, Serialization or Artix Data Services (ADS). Having great ADS support allows us to work natively with things like SWIFT, SEPA, FpML, TWIST, ISO 20022, CREST and FIX messages - or any binary, fixed width or delimeted file format.
hugely improved CXF integration for working with JAX-WS and Apache CXF while reusing powerful Camel routing.
improved support for Asynchronous Processing within components such as for HTTP and SEDA
improved OSGi support with both component discovery using the OSGi registry and turning Camel into OSGi bundles.
improved Visualisation
support for the full WSDL Message Exchange Patterns
more powerful Bean Integration

New Components

iBatis for easy integration with JDBC in addition to the JPA component
StringTemplate for template based services
Velocity for template based services

GridGain now usable by Apache projects!

2007-11-01T07:15:00.000Z

Thanks to Nikita and his team the core APIs of GridGain are now Apache Licensed, so we can build software at Apache for GridGain such as plugins in ActiveMQ, Camel or ServiceMix. Cool! BTW ServiceMix now really is top level at http://servicemix.apache.org.

free ringtones are really easy on hacked iphones...

2007-10-31T14:52:00.001Z

So this friend who hacked his iphone was telling me, you just use Fugu as an FTP client and copy any MP3 / AAC files you want into

/Library/Ringtones

And hey presto, they just work as ringtones on your phone. Neat!

[LazyWeb] maven pom trimmer plugin idea...

2007-10-31T14:08:00.000Z

So its so easy for maven pom.xml files to get a little large; full of stuff they don't really need - or more importantly, full of stuff the end user doesn't really need to use your library. Its even easier for the stuff you depend on to pull in heaps of stuff you don't need.

e.g. ever picked the wrong clogging pom.xml section and shoved in a dependency on log4j, logkit and avalon on your project? (Its such a shame sun messed up the clogging space btw).

Its way too easy in maven to not really see or care what dependencies you really have, including those transitive ones - and we end up with lots of unnecessary crap. It can be a bit scary to run 'mvn site' then look at dependencies.html to see all the stuff maven's pulling in.

So here's the idea. Its a bit like Jester. When all your tests pass; you run the pom-trimmer; what it does is try removing bits of your pom to see if your tests pass. It tries all the permutations to figure out how much crap it can miss out. (So commenting out sections/>).

Next though is it should walk the transisitve dependency graphs and find all the transitive dependencies and try avoid those (using tags on the dependency) so it can clean your pom down to just what you really need.

We should try get into the habit of running this before a release so we can all try keep released pom's as free from junk as possible.

So any volunteers to hacking up this little Mojo?

iPhones rock, even in the UK!

2007-10-19T15:52:00.000Z

This blog post is obviously about a friend of mine; as I'd never be naughty and hack an iphone. So i've got this friend right, he's a bit of a geek and lives in London m'kay. A friend of his showed him his iphone working beautifully in the UK with a normal UK SIM card. My friend was super jealous and got another friend to buy him an iphone while in the states.

The iphone then turned up in the usual gorgeous Apple packaging. After following these instructions (as it was a 1.0.2 firmware) it was activated and jailbreaked like a charm with some neato apps on it (and openssh etc). I love 'Sketch' BTW! :). Colloquy is pretty good for IRC too

Then these instructions were followed to unlock the SIM...

From your phone, open Safari and visit the following website: http://i.unlock.no - a dialog will appear and ask if you want to add a new package source. Tap on Yes. The Installer application will now automaticly launch, and it will refresh the list (if it doesn't refresh, tap the refresh button).

In the list of applications, scroll down almost to the bottom. Under the category "Utilities" you should now have "anySIM" there. Tap on it and install it (hit yes on the warning dialog). When done, press the home key, and wait for the phone to refresh. Now you should see an anySIM icon on your phone.

Before you start anySIM, go to Settings ? General ? Autolock and set it to Never. Now you can press home button, and tap on the anySIM icon.

Slide to unlock, and read to the bottom and tap the red button. This process will take some time, so just sit back and relax. When it's done, you get a message telling the result. If it's an error make note of that error, but don't worry yet.

Insert a SIM from a carrier of your choice.
If you get signal, your phone is unlocked and you are done!
See iphone.unlock.no for additional reference notes.

Finally these instructions were used to change the SIM card and hey presto - a totally working iphone in the UK with a normal SIM card.

My friend is really really happy with his iphone - and is especially glad he accidentally broke his previous phone by dropping it which meant he just had to get an iphone to replace it :). Other tips from this friend of mine is to surf your gmail use

http://mail.google.com/mail/x/

Though you didn't hear any of this from me m'kay. I've gotta say am really impressed with the iphone - its an awesome device.

Update: Screencast of Apache Camel and EIP - now for windows! :)

2007-10-03T14:45:00.001Z

Some folks on windows reported issues watching the screencasts (thanks James and Chuck for your feedback!). Well you could always treat yourself and just buy a Mac! :)

For those still waiting for their Mac who are still stuck on a windows box there's now some WMV formats of the quicktime movies. For example

Intro to Apache Camel and Enterprise Integration Patterns (high res) camel-intro.wmv
Intro to Apache Camel and Enterprise Integration Patterns (medium res) camel-intro-medium.wmv

Also thanks to Dan for converting them :)

Screencast: An introduction to Apache Camel and the Enterprise Integration Patterns

2007-10-01T08:32:00.000Z

I've created a short screencast introducing Apache Camel.

A high quality version of the screencast also available.

Hopefully I'll get a chance to create another screencast soon walking through a demo and showing the various visualisation tooling etc.

Great message from bob :)

2007-09-25T16:45:00.001Z

See this short film :)

ServiceMix is now a top level Apache project!

2007-09-20T04:31:00.000Z

From Guillaume's post...

I'm really pleased to announce that the ASF Board has approved Apache ServiceMix graduation :-) This means that ServiceMix now becomes a full Apache Top Level Project. So we will soon make our first official release of ServiceMix 3.1.2 and 3.2 coming later. This also means that the resource will be moved to their final location: the website will be moved to http://servicemix.apache.org/ and the svn repo to https://svn.apache.org/repos/asf/servicemix/.

In addition, I'm honored to have been voted as the Apache ServiceMix PMC Chair. The PMC (Project Management Commitee) is the group of people responsible for the project oversight, and its Chair is the interface between the Board and the project.

I just want to remind people the purpose of the Apache Incubator: its main responsibility is to watch new projects at the ASF to make sure that no IP problems remains and that there is a vibrant, diverse and sustainable community around the project that goes the "Apache Way". This is in no case about the quality or maturity of the software itself, as incubating projects greatly vary in these areas (from brand new projects to very mature projects joining the ASF).

Yay! Congrats to the entire ServiceMix team!

Pure RESTful API to ActiveMQ via AtomPub

2007-09-04T12:33:00.000Z

Here's an early draft of an attempt at describing a purely RESTful API to ActiveMQ using AtomPub. Mapping a message broker to REST and AtomPub turns out to be much harder than it looks.

The trick I've used in this draft is that consumers subscribe by creating a new subscription Entry (as a new Entry in the subscriptions Collection) which times out eventually if the consumer goes away. Then each consumer consumes from its own Feed, so that things are nicely load balanced etc.

As usual - any feedback most welcome

10 reasons to model XML with RELAX NG , not W3C XML Schema

2007-09-04T11:00:00.000Z

A great post by Griffin Brown is 10 reasons to model XML with RELAX NG , not W3C XML Schema

I'm really pleased to see the move away from J2EE to simpler POJO models; away from complex WS-deathstar to simpler REST, to JSON away from complex XML + namespaces + XSDs etc. Am hoping the trend continues with more and more people moving to RelaxNG Compact Syntax away from XSDs...

Got a Mac? Use TextMate? Try GetBundle

2007-09-03T14:53:00.001Z

If you've a Mac then do try TextMate; its an awesome editor and part of my favourite OS X software. Its not a replacement for your Java IDE; but is very handy for editing everything else :). I often type this into the command line...

mate someFolderName

To browse a Java project quickly, without doing the whole Java IDE create project thing; which can sometimes take a while...

Today I stumbled on the GetBundle bundle which is a really nice way of adding new bundles. Also the Groovy/Grails bundle looks good!

Whats happening with FUSE ESB

2007-08-31T11:23:00.001Z

Guillaume has a great post on FUSE ESB...

My company IONA provides support on Apache ServiceMix via a distribution called FUSE ESB available from the Open Source IONA site.

What's in FUSE ESB right now? Well, it's roughly a distribution of ServiceMix trunk. This implies that FUSE ESB is released ahead of the Apache ServiceMix distribution (the latest release is 3.1.1, whereas FUSE ESB is based on 3.2).

Why are you using the latest trunk instead of the most stable branch? Well, mostly because our customers needs some of the latest features available. We take great care of what is in our Fuse branch: we do not necessarily backport all new stuff from trunk. We may also add some specific customer needs inside our own distribution, features that are not present in the trunk version.

So is that a fork? Certainly not :-) We have always supported Apache ServiceMix and we will continue to do so. But our customers have specific needs, so we may need to do custom development or have custom branches for them to fullfill these needs. Over time, we put the features that we consider generic enough back to the community. But this level of support can not be provided in a community driven environment such as the Apache Software Foundation. Let alone the fact that our customers often require privacy regarding their issues or their specific needs, environments and projects, so that it becomes difficult to use the open mailing lists of the community.

So is that a closed source version? No. The Apache License would allow that (quite the opposite of the GPL), but this is not what we aim for. Our process is quite open: as an example, I've recently developed an AsyncBridge EIP pattern for FUSE ESB (see the issue) that will certainly be contributed back to the community...

Hopefully, this blog entry will clarify a bit the IONA policy with respect to the Apache projects it supports and the relationship between FUSE ESB and ServiceMix. Feel free to download it and give it a try...

Podcast on Apache Camel, Enterprise Integration Patterns and 1.1.0 release

2007-08-17T09:15:00.000Z

I had the pleasure to be interviewed by Dana Gardner, principal analyst at Interarbor Solutions about Apache Camel recently. You can listen to the podcast or read the online transcript. Apologies in advance for any rambling :) - I did enjoy it though.

In related Camel news, the Camel 1.1.0 Release has been cut and voted; its just about to move to the maven repo & Apache mirror system any moment now. Cool beans! It contains numerous new features...

hugely improved Bean Integration to work nicely with beans and Camel; making Camel even less intrusive
improved Spring XML support using JAXB2 and code-generating a nice XML Schema
new Enterprise Integration Patterns like Aggregator, Throttler, Delayer
new Languages Supported such as EL and OGNL
new Components like VM, Event, Log, Validation, Jing, MSV
new Examples such as Spring Example, ETL Example and BAM
improved distributed testing with via the Mock component
new Camel Maven Plugin for easier running of Camel routes and Examples in Maven

Incidentally I really love the new Visualisation plugin that can be easily integrated into your maven site generation as this example shows.

OpenJPA no longer requires mandatory bytecode postprocessing

2007-07-30T14:04:00.000Z

See OpenJPA no longer requires bytecode processing from Patrick.

Awesome! This makes it pretty trivial to switch Hibernate <-> OpenJPA

a pure RESTful way of working with ActiveMQ queues

2007-07-10T11:03:00.000Z

I've been snowed with the day job but really wanted to reply to niklas's post on A RESTful queue. It looks a great suggestion; I need to catch up on the discussion.

The REST support in ActiveMQ isn't really pure REST; as it uses non-idempotent GETs as a bit of a hack - though it does make it very easy to work with :). I’d LOVE a nice, proper, RESTful API to ActiveMQ. Though properly exposing message queues efficiently over REST while handling concurrency is a tricky problem, but its looking like some consensus is emerging. Niclas's suggestion sounds about right to me too.

Though I guess a proper REST API would involve more complexity on the client side (e.g. having to do a POST then follow a Location header to then do a DELETE or whatever). So even if we had the worlds most RESTful API, some folks might still want to use the non-idempotent GET hack (particularly if they no there's no caches in between :).

Ideally I was also thinking we should expose the entire broker on the Atom Publishing Protocol; so an APP client could discover all the queues & topics etc.

Am a bit snowed right now but ASAP I'd love to get a proper REST and APP protocol for ActiveMQ...