Gert Vanthienen wrote:
L.S.,
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)?
If we can get the component, language , converter from the OSGI service
registry, it could be no problem for us to start a camel context with
the RouteBuilder.
BTW, we can consider to add a extender to support the camel route with
guice. There is camel-example-guice-jms to have this kind of requirment.
Willem
Regards,
Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On 7 May 2010 09:19, Claus Ibsen <claus.ib...@gmail.com> wrote:
On Fri, May 7, 2010 at 9:06 AM, Guillaume Nodet <gno...@gmail.com> 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: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
