camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [DISCUSS] OSGI improvements
Date Fri, 07 May 2010 11:45:49 GMT
On Fri, May 7, 2010 at 10:34, Gert Vanthienen <gert.vanthienen@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.ibsen@gmail.com> wrote:
> > On Fri, May 7, 2010 at 9:06 AM, Guillaume Nodet <gnodet@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message