Saturday, 8 February 2014

Fabric8, JBoss Fuse and Apache Karaf versions

This question came up on twitter and it wasn't a quick answer so thought I'd answer here.

So right now fabric8 is aligned with the JBoss Fuse 6.1 release thats coming out soon which is based on Apache Karaf 2.3.x (along with Apache Camel 2.12.x and Apache ActiveMQ 5.9.x).

We've lots of production customers on Fuse 6.0; so are not yet ready to take a major update of Karaf (3.x) which has lots of major changes in it and we've not yet put it through our QA process. (3.0.0 hasn't been out 2 months yet so its still pretty new).

As soon as the JBoss Fuse 6.1 release is out, fabric8 will move to support Karaf, Tomcat, WildFly containers (hopefully vertx and jetty too) along with stand alone JVMs like DropWizard and Spring Boot - in addition to its current support for managed processes, OpenShift and jclouds.

We've migrated fabric8 to be completely based on Declarative Services and moved away from OSGi blueprint; as its leaner, meaner, avoids dynamic proxies and is easier to deal the asynchronous modular nature of OSGi as things are dynamically added and removed. An added benefit is the use of Felix DS annotations lets us auto-generate nice stand alone OSGi tooling and fabric8 based fabric-aware tooling in hawtio for all of the services in fabric8).

Ideally it'd be good to migrate fabric8 straight to Karaf 4.x (or whatever it ends up being called) thats based on pure Declarative Services; as it'd make the OSGi based distribution of fabric8 leaner & meaner. But we'll see in a couple of months how things are looking in Karaf-land.

We're very excited about fabric8 being completely poly-container; so we can use fabric8 to provision and manage Karaf, Tomcat, Wildfly & vertx containers; stand alone JVMs along with working great with docker, OpenShift and jclouds - all with a lovely hawtio console for everything! Its going to totally rock! :)

5 comments:

Vincent Crépin said...

When you say moving away from osgi blueprint do you mean that it will not be supported anymore ? This is my preferred way of using camel and beans in the container right now. Does it mean I should use another method instead (Spring or Java DSL) ?

Vincent Crépin said...

When you say "We've migrated fabric8 to be completely based on Declarative Services and moved away from OSGi blueprint" what do you mean exactly ?

Blueprint is my preferred way of declaring my routes and binding beans right now in Fuse. Does it mean it will not be supported anymore and I have to use Spring instead for the future ?

Or I did not understand at all what you meant...

James Strachan said...

Hi Vincent

Apologies if my comment caused any panic; I just meant that internally we've found Declarative Services to be leaner & meaner, deal with services coming and going easier and helps us provide better configuration tooling.

However we will always support spring, blueprint and DS; so pick which ever DI approach you prefer.

Going forward; I hope we can create more documentation & examples showing how DS can be used to encourage a POJO based programming model without requiring any XML; which uses Config Admin property files and comes with great tooling to view/create/edit/delete configurations. Though blueprint & spring will always be supported too though!

Unknown said...

DS seems nice, but how can one declare CXF stuff with it? How about JPA/JTA stuff, just like one can do with Blueprint?

This is my main concern as I've been blocked a few times when trying DS.

Also, moving to Karaf 3.x is of real interest to me and my projects. Especially, because of Java 8 support, PAX-CDI and such!

I for one truly believe in the power of fabric8 and have been releasing example code on pretty much everything I try related to it at http://github.com/pires.

Vincent Crépin said...

I've been playing with declarative services lately and I must say that I like the architecture a lot. I'm mainly interested in Remote Declarative Services which are exposed from a simple configuration accompanying the service.

My question: is there a Maven archetype that would generate a base project for such a need ? If not, which one should I use that would be closer ? The automatic generation of the pom would be of great value for my team.