Two Karaf related Camel components

While thinking about a centralized logging system for Karaf and FUSE ESB, I had this idea that instead of using a built-in JMS appender, such as the one provided by Log4j, we could instead easily use Camel for that. Camel is really the best fit for such a thing, as we'd be able to add advanced things such as redelivery, batching, compression and choose easily the transport we want (JMS or plain TCP).

The OSGi EventAdmin service is also an important point for monitoring events in the OSGi runtime, as most of the OSGi services do publish events to it (Blueprint bundles events, bundle events, etc...). So this was another need for a camel component.

Given Camel 2.5 will be released soon, I did not want to destabilize trunk just before the release so I've committed them to a github fork for now.

Those two components are really easy to use:

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
    <camelcontext xmlns="http://camel.apache.org/schema/blueprint">
        <route>
            <from uri="paxlogging:camel"/>
            <to uri="stream:out"/>
        </route>
    </camelContext>
</blueprint>

In your Karaf installation, add the osgi:camel as a root appender, and you'll see events printed to the console, though not in a nice way, as the goal is really to send them over the wire.

For the event admin component, things are really easy too:

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
    <camelcontext xmlns="http://camel.apache.org/schema/blueprint">
        <route>
            <from uri="eventadmin:*"/>
            <to uri="stream:out"/>
        </route>
    </camelContext>
</blueprint>

The name of the consumer endpoint identifies which topic the endpoint will consume from. This component can also be used as a producer to actually publish events to the Event Admin.

I think those components still miss a bit of configuration, but they seem to be a great way to distribute log events and OSGi events to the outside world in a very powerful configurable way.

As usual, feedback welcome. I think those two components can have some real use case, so I'd like them to be put back into the Camel trunk for 2.6.