David Dossot has released a JCR component for the Mule ESB, that watches for notifications in a Java Content Repository. The purpose is to route notifications to interested endpoints or components, enabling them to trigger actions like instantiating work-flow sequences or flushing caches. The JCR Transport for Mule "supports JCR 1.0 (Java Content Repository 1.0, as defined by JSR 170) repositories and is a receiver only. It leverages the asynchronous notification mechanism, named observation, to receive events whenever a change occurs in the repository and is not intended for storing nor reading messages from a content repository." It's an interesting idea. One might also wonder if it'd be valid to have an ESB component that did retrieve content from a repository; anyone know of or have experience with such a component? (If not, would it be a bad idea to have?)

What a great idea! Dossot, you're the man now dog.

One might also wonder if it'd be valid to have an ESB component that did retrieve content from a repository; anyone know of or have experience with such a component? (If not, would it be a bad idea to have?)

That is a very valid point! Before writing this transport, I have seriously considered the option to persist messages directly in JCR but I came to the conclusion that it would have been ill fitted. Let me explain: to my sense, if the ESB needs to send a message to some sort of persistent store, the natural destination should be a MOM, like JMS. Doing so allows a natural message oriented semantic between the bus and the messaging framework instead of persistence semantic, which I think is more desirable in the overall context of the ESB. For the ones convinced that, as David Nuescheler would say, "Everything is content" hence messages should be persisted in JCR, I would suggest to look at Graffito (http://incubator.apache.org/graffito) and see if it comes to the point of being used as a persistence manager for your favorite MOM.

David, Awesome implementation -- thanks! This will work out great in a project I'm involved in. This article couldn't have come at a better time. I just finished writing a Mule service object that gets a Communiqué notification for a content update, then builds an OpenLaszlo component, and finally hands the results back to Communiqué. On recommendation from Day Software we're using their RESTful API... now, with your component being available, I think I can provide an even better solution, including retrieval. Let me talk to the Day guys and I'll post that later. Cheers, E Non-stop action. A vulnerable hero. A quest to save the world. It's the most exciting novel of the decade: The Tesla Testament by Eugene Ciurana ISBN: 1-4116-7317-4 - BISAC: FIC031000

Eugene, I am glad this transport comes on time for your project. Should you hit bugs or come with feature requests, please post them in JIRA: http://mule.mulesource.org/jira/browse/JCR David -- http://dossot.net

It's worth noting that we haven't officially launched the MuleForge yet (we're still in beta testing) so the the Look and Feel is a little off. This is being worked on currently and will fixed by the time we launch next month. However, it is usable in it's current state. People are welcome to sign up and start hosting projects! Cheers, Ross MuleSource