Friday, June 26, 2015

Karaf 4.0 is about to be released !


Almost 3 years since I haven't blogged, so I'm using the fact that the Karaf 4.0 release in under vote to start again.

Karaf 4.0 brings a lot of new features, but one of the most important one is the new features service.  It is originally a port of the Fuse/Fabric agent resolver to Karaf 4, but has since been extended a lot (and has actually been integrated back into Fuse 6.2).

This new features services is used to install well known features, but even if it reuses the same features xml definition, it's not limited to those anymore and works in a very different way.  The main difference is that the original features service (in Karaf 2.x and 3.x) is quite blind when it comes to installing features.  When a user asks for a feature installation, the process was quite simplistic: the service mainly goes through the list of bundles listed in the feature and install them.  The introduction of the resolver flag brought some intelligence to the process, as the old and deprecated OBR library was used to compute which bundles were actually needed.  The goal was to be smarter and not install bundles if they were not needed.
However, OBR was quite limited, and the output of OBR could theorically not be supported by the OSGi framework, or at least, not give the expected results.

The new resolver reuses the OSGi resolver, the exact same one that is used by the OSGi framework.  It also reuses the same metadata extracted from the bundle headers.  The new OSGi resolver is really generic and supports any kind of requirements and capabilities, even though it contains specific rules for known kind of constraints.
The new features service uses this resolver, by translating feature definitions into resoures with their requirements and capabilities, including bundles, but also conditionals, feature dependencies, etc...  Once the modelling is done, the service asks the resolver for an output, and brings the framework into the desired state by installing, uninstalling, updating bundles as needed.

This is major change, even though the end-user does not always see it immediately.  The features service maintains a set of requirements (usually requirement on features), and the resolution will always satisfy those requirements.  This means that the installation of a feature can not fail previously installed features, nor can it installs a feature that can't be resolved.

There are lots of new stuff coming with this new features service, and I'll try to cover some of them over the next weeks.

Thursday, June 28, 2012

FuseSource acquired by RedHat

Yesterday, an important announcement was made: RedHat is acquiring FuseSource.  This news is following Progress announce a few weeks ago about FuseSource being divested as not being part of their new product strategy.

This is truly exciting. RedHat looks like a fantastic company, pure Open Source players as we are too.  We will be integrated into the JBoss Enterprise Middleware Group and even if there is some overlap on the products, I don't have any doubts that we'll be able to find the best way to leverage our respective strengths to build new awesome products for our users and customers.

This is definitely a good fit for both RedHat and FuseSource, and I'm definitely thrilled about it.

Friday, March 16, 2012

Camel Webinar

Je présente la semaine prochaine un webinar sur Camel en français intitulé "Introduction à Apache Camel".
Inscrivez-vous !

Thursday, February 23, 2012

JLine 2.6

I've released JLine 2.6 which should be available in central soon. The main change is that JLine is almost completely conform ant with GNU readline. This means that JLine will read the ~/.inputrc by default and now supports VI editing mode, macro recording and all the goodness you can find in your standard unix shell.
It will be used in Karaf 3.0 and in the next Fuse ESB.

Wednesday, January 18, 2012

Unit testing Camel Blueprint routes

Last week, while in Vegas, I discussed with my colleague Scott Cranton and he told me that something that was really making our users tend to stick with Spring-DM when using Camel Blueprint routes was that unit testing those routes was not possible.

So I hacked a small support library for Camel, leveraging PojoSR which provides a service registry without using a fully compliant OSGi container. This allows defining real unit tests (as opposed to integration tests using Pax Exam.

See the below example.

public class DebugBlueprintTest extends CamelBlueprintTestSupport {

    @Override
    protected Collection<URL> getBlueprintDescriptors() {
        return Collections.singleton(getClass().getResource("camelContext.xml"));
    }

    @Test
    public void testRoute() throws Exception {
        // set mock expectations
        getMockEndpoint("mock:a").expectedMessageCount(1);

        // send a message
        template.sendBody("direct:start", "World");

        // assert mocks
        assertMockEndpointsSatisfied();
    }

}
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">

 <camelcontext autostartup="true" id="camelContext" trace="true" xmlns="http://camel.apache.org/schema/blueprint">

  <route>
   <from uri="direct:start"/>
   <transform>
    <simple>Hello ${body}</simple>
   </transform>
   <to uri="mock:a"/>
  </route>
 </camelcontext>

</blueprint>

Tuesday, January 17, 2012

Back from Las Vegas

I'm back from Las Vegas where we had a fantastic FuseSource KickOff meeting.

As you can see below, a real camel had been brought from the west coast and James even had a short ride on it! On the technical side, we expect a bunch of exciting stuff this year, so you'll certainly hear from us soon.

Tuesday, October 11, 2011

WS-Notification implementation

Since the early days, Apache ServiceMix has had an implementation of the Oasis WS-Notification specifications. This implementation was built on top of Apache ActiveMQ and available inside the JBI bus as a service. Now that JBI is being put aside in ServiceMix, some questions arose about the future of this component.

So last week, I took a stab at rewriting the component using pure JAX-WS services. For those that are not familiar with WS-Notification, this specification, unlike most other WS-* specifications defines a service described by a WSDL, so there's no low level protocol implementation to write. I took most of the code from ServiceMix implementation and just rewrote the JBI specific bits to leverage JAX-WS instead.

The results have been committed into Apache CXF and should be part of the upcoming 2.5 release. Note that the implementation itself does not require CXF, though it can very well use it as the JAXWS provider.

If you want to give it a try, you need to build CXF trunk locally and then run the following commands in Karaf:
karaf> features:addurl mvn:org.apache.cxf.karaf/apache-cxf/2.5.0-SNAPSHOT/xml/features
karaf> features:install wsn 


To check that the WS-Notification broker is correctly started, you can try the following command:
karaf> cat http://0.0.0.0:8182/wsn/NotificationBroker?wsdl
...


The services are also exposed as OSGi services, so that they can be directly accessed if needed. If you use the awesome Fabric DOSGi implementation, it can be very interesting.

Some areas could still be enhanced, as the codebase is mostly the same as the old ServiceMix component. I'm thinking to complex topic expressions or persistence of subscriptions. If you have any real need for something, send an email to the CXF mailing lists ...