Guillaume Nodet's blog

Just an update on the SSHD project I started a few weeks ago. It has been accepted yesterday as a MINA subproject :-) You can find all the needed pointers on the web site .

David Greco has posted a nice blog entry about ServiceMix Kernel. I do totally agree: ServiceMix 4 is not only a JBI container, and more precisely the ServiceMix Kernel which can be run standalone is a universal container (which does not include JBI by default) where you can deploy virtually any kind of artifact from web applications, to JBI applications or plain JAX-WS services.

ServiceMix Kernel is a small container based on OSGi. The latest release allows external clients to connect to it and issue commands using a simple protocol implemented on top of TCP or SSL. However, this remoting protocol has some drawbacks as the internals makes it unable to do another remote login from a remote session. In addition to that, completion and history do not really work great. So I've been thinking about using the SSH protocol, which is widely used, secured, with tons of different clients available. Unfortunately, no SSH server is available in Java. Over the past weeks, I've been working on implementing this SSH server, based on the IEFT specifications, the JSch SSH client library, and the OpenSSH server source code. The server itself is based on Apache Mina which is a great framework for using NIO. The project is available at http://code.google.com/p/sshd/ and although there are lots of limitations right now, the basics of the SSH protocol work. I plan t...

FUSE ESB 4 has just been released . I welcome everybody to download and give it a try.

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 chan...

I'll just quote Rob 's blog entry : Progress completed its acquisition of IONA Technologies last Friday. The FUSE open source group will be running as its own business unit as part of the Progress Software Corporation - so we are still operating as before - but with considerably more investment. Progress saw the number and quality of enterprise customers we have using our integration products, saw that we consistently met and exceeded our sales targets and realized our potential to grow significantly. So although we currently employee a lot of open source developers - we will be recruiting even more - and have some exciting new software projects in development for release in 2009 :)

I'd like to talk a bit about third party dependencies in ServiceMix 4. ServiceMix 4 is based on OSGi and when deploying applications to it, you have two choices: use the JBI packaging use the OSGi packaging The first solution is a good thing if you want to abide by the JBI specification completely or if you want to use non OSGi aware components. However, you'll come into the known limitations of the JBI packaging with respect to classloaders: the JBI specification is quite limited in this area. The second solution is more powerful as, in addition to being able to leverage the OSGi classloader mechanisms, you'll also be able to access the OSGi registry, thus registering or retrieving services in the registry. However, when using the OSGi packaging, you need to deal with third party dependencies. OSGi is becoming more and more popular, so more and more projects are now distributing the jars as native OSGi bundles. But not all have converted to OSGi yet. And of course, you...

I found Fantastic Contraption a small, but very fun game to play. Here is my solution to the last free level. Enjoy!

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

Ross Mason, the CTO of MuleSource, recently started a discussion about JBI. His first point is that JBI is no TCP/IP, meaning somehow that JBI is targeted at vendors and not at developers. Well, I'm not sure about the TCP/IP thingy, but he's a bit right about JBI being targeted at vendors and not developers. Why? If you have some knowledge about JBI, you know that there are multiple JBI components (bindings that handle a particular protocol such as HTML, JMS, etc... and engines that provides business logic such as a rules engine, a BPEL engine and so on). The developer will mostly see those components, not the JBI APIs: if you work with a BPEL engine and write a process, you won't see the JBI APIs surface in the BPEL at all. If you write a WSDL to define a SOAP/HTTP service, you won't really see JBI there either. So, yes, at some point, he is right that JBI 1.0 hasn't focused on the developer, or I should say, the user. Because if you need a custom componen...

For ServiceMix 4, I've been working on making sure the Java EE specifications can be used in OSGi. The first step was to release OSGi versions of the various specifications by just adding the needed manifest entries to make them usable in OSGi. This was done inside the Geronimo project (on which I am a committer). This means that since a few months, most of the Java EE specification jars are available as OSGi bundles (you can grab those from maven 2 public repositories . However, this is not always sufficient. Some of these specifications (mostly JAXB, SAAJ, JAX-WS and Stax) do not work well in OSGi. The mean reason is that the implementation is discovered using different mechanisms by the API. The most commonly used one is to find a file on the classpath in the META-INF/services directory and find the main entry point class of the implementation. Unfortunately, to make this work in OSGi, the client bundle (the one using one of these APIs) has to have the required file in it...

I've working on implementing the security framework for ServiceMix 4. ServiceMix 3 used JAAS for the authentication part, and it also makes sense to use it in ServiceMix 4 for several reasons: reuse of existing login modules, integration with the JMX and the console security which are already based on JAAS. However JAAS is not very OSGi friendly (well, most of the JEE specifications are not, and I'll talk about the others in another post), mostly because is makes some strong assumptions upon the thread context classloader, and this, mainly on the client code. This means the client that uses the JAAS api to authenticate has to have all the login modules available in its thread context classloader. This is usually not the case in OSGi. So the solution is to use a proxy login module that will be available to all bundles (by using the boot framework delegation package). This proxy login module can use some OSGi properties on the login module configuration to determine the actua...

I've done some experiments today to check that ServiceMix 4 NMR can be easily deployed on Equinox instead of Felix. Have a look at this wiki page .

We've just released the third milestone of ServiceMix Kernel 1.0-m3. This small OSGi based container is really nice, if you haven't had a look at it yet, go and grab it . It adds a bunch of cool new features. For example you can run: osgi list | utils grep ServiceMix or log d | utils grep WARN If you want to have a quick run at it, go and look at the quick start guide .

I've just seen the annoucement that SpringSource has launched a new App Server based on OSGi (Spring-DM). I find it a bit weird that they tend to rewrite existing stuff: the JMS JCA layer in Spring 2.x is somehow derived from the Jencks project, Spring Integration looks a lot like Camel , and now this app server which looks very similar to ServiceMix Kernel with WAR support (which we already had in ServiceMix 4 from the Pax Web project).

A friend of mine has cracked an iPhone a few months ago (shame on him...) but was quite reluctant to upgrade to a newer version in case the phone would be bricked . Fortunately, I gave him a link to ZiPhone , which is the best way to unlock your iPhone I've found so far: just upgrade your phone using iTunes, launch the application and click. 5 minutes later, you have a jailbroken and unlocked iPhone with the latest firmware :-) Dan has also blogged about Fring , a very nice application to to VoIP over the iPhone. If you like to twitter , have a look at Twinkle too.

Bruce and I will be both at ApacheCon Europe in Amsterdam next week to talk about ServiceMix and Camel , so if you want to meet with us, send us a mail. There will be a BOF about ServiceMix on Wednesday, so it will be a good opportunity to meet too.

I've just seen this post saying: One of the major motivations for doing so is that currently, the Java community is still split between SCA and JBI. Well, this is somewhat true, I can't really deny it, but it should not be that way. JBI and SCA are not really competitors, even if they are usually seen that way. The JBI specification explains how to create an ESB that allows pluggable components to be wired easily thus allowing vendor independant components to be created. SCA defines a way to write composite applications in a clearly defined way that can be applied to different languages (though you can't really mix those, so you end up with one runtime per language you support). As a standard, SCA offers value, but I really think both could be supported in a single runtime like FUSE ESB . We've discussed several times about supporting SCA on top of JBI in ServiceMix , but I haven't heard much needs on that. We are currently working hard on ServiceMix 4, based...