camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gert Vanthienen <>
Subject Re: [DISCUSS] OSGI improvements
Date Fri, 07 May 2010 08:34:14 GMT

Guillaume's suggestion is to create a separate JAR with the OSGi
helper bits and embed that in both camel-blueprint and camel-spring.
I don't think there's a real problem with a compile-time dependency,
as long as we mark the Maven dependency optional in the pom.xml  -- we
just have to make sure that we don't use the OSGi specific classes
when running in a non-OSGi environment and then we should be fine
there, shouldn't we?

I suppose the goal is to look for Camel bundles and register
components, converters, languages, ... in the OSGi Service Registry so
we can respond to changes in the environment for our Blueprint and
Spring DM deployed routes.  For example: for camel-blueprint, we could
set-up a component/converter/... locator class in an
OSGI-INF/blueprint/camel.xml file which would only get started in an
OSGi- and Blueprint-aware container to avoid the tight link.  I'm not
entirely sure about META-INF/spring/*.xml for camel-spring, but I
don't think that will get automatically picked up in a non-spring-dm
environment either.

One other question: shouldn't we consider to build support for
deploying Camel in a pure OSGi environment as well (like an embedded
environment or inside Eclipse) without requiring the use of either
Spring DM or Blueprint (although the latter is probably lightweight
enough to be installed in almost any environment) -- e.g. have a
ServiceTracker to track RouteBuilder instances in the OSGi Service
Registry and have a means of auto-starting them (e.g. by adding some
property when registering the service)?


Gert Vanthienen
Open Source SOA:

On 7 May 2010 09:19, Claus Ibsen <> wrote:
> On Fri, May 7, 2010 at 9:06 AM, Guillaume Nodet <> wrote:
>> I'm working on improving and refactoring the OSGi bits and I'd like to
>> propose the following:
>>  * make camel-osgi a plain jar just used to share common code between
>> camel-blueprint and camel-spring
>>      this jar would contain osgi specific classes and also common code for
>> jaxb parsing / factory logic
>>      both camel-spring and camel-blueprint would embed the classes defined
>> here as to simplify deployment
> How would that be possible for camel-spring to NOT require any osgi jars at all,
> for people who simply want to use Camel in non osgi environments?
> The problematic part as I see, is the "logic" which is required in
> camel-spring to prepare the routes before they are ready to be used at
> runtime.
> This logic is a bit extensive and would require to be duplicated for
> blueprint as well.
> This has annoyed me that camel-spring required this work, where as
> camel-core would not (eg there is a potential difference between Java
> DSL and Spring XML routes). Hence I have though of refactoring this
> logic into camel-core so both Java DSL and Spring XML leverages it.
> I have though of attempting that for Camel 3.0. But in light of this
> we could consider moving this forward.
> Then if implemented then camel-blueprint and camel-spring can be
> independent of each other, as they are today.
>>  * merge camel-spring-osgi back into camel-spring
>>      this would be easier for end users i think as they would just have to
>> deploy camel-spring and that's all
>>      whether they are in an osgi environment or not would be transparent
> Still I don't see this possible. Its important that OSGi does not
> become invasive in any way for people not using it at all.
> And that means no OSGi jars required at runtime.
>> Thoughts ?
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog:
>> ------------------------
>> Open Source SOA
> --
> Claus Ibsen
> Apache Camel Committer
> Author of Camel in Action:
> Open Source Integration:
> Blog:
> Twitter:

View raw message