On Fri, May 7, 2010 at 10:34, Gert Vanthienen <gert.vanthie...@gmail.com>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? > Yes, it would be a compile time dependency only. > > 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)? > We could do that too. I think it's already doable with camel-osgi. I plan to lower the dependencies so that it will be independant of spring, but there is a pure OsgiCamelContext which should work I think. One possible way would be to completely get rid of camel-osgi and move those bits directly into camel-core, so that camel-core itself would be sufficient when deployed in an osgi environment. I suppose we'd still need a maven module for the xml related bits in common though. > > 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 > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
