You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Bert Speckels <be...@gmail.com> on 2022/09/04 13:42:53 UTC
Camel and OSGI support
Hello there
I'm a bit desperate at the moment: We're switching our Camel routes (in a
monolith, Camel 3.14.2) to OSGI bundles (Apache Karaf and upgrade to Camel
3.18.1). Unfortunately I have some difficulties with this.
For one thing, I'm missing a few Camel features: Unfortunately,
"camel-endpointsdsl" doesn't exist as an OSGI feature/bundle, right?
Neither 3.14.2 nmor 3.18.1 has OSGI support for that.
Also missing in Camel 3.18.1 is the OSGI support of MongoDB, which still
exists in 3.14.
Also using CDI is quite confusing for me. Aries, Blueprint, Pax CDI,
Camel-CDI... so many combinations... @Service, @OsgiServiceProvider,
@Inject, @Reference... so many annotations, some of which are apparently
deprecated. Currently we are using weld in our monolith: weld-se-shaded,
deltaspike-cdictrl-weld with Camel-CDI.
Overall, many (all?) tutorials and examples seem to be very outdated: I
rarely find examples from 2020 or later. Apparently, even after 2020, so
much has changed at Camel. Maybe you can point me to one or the other
problem where I can get current information: OSGI-Mongo-Support, CDI,
camel-endopointsdsl...
With kind regards
Bert Speckels
Re: Camel and OSGI support
Posted by George Daswani <ge...@hotmail.com>.
Personally, I've used blueprint with OSGI, Camel for several years now -
still works just fine even with the latest version of Karaf (4.3.X -
haven't tried 4.4.1), Camel (3.18.1), and JDK 11.
On Tue, Sep 6, 2022 at 4:03 AM Bert Speckels <be...@gmail.com>
wrote:
> Some (all) good points Raymon
>
> I think this is a very good summary and I have nothing to add :-)
>
> Currently we are trying to use some workarounds:
> - Live without CDI ... I think this is less painful than we think at the
> moment.
> - Build our own Endpoint DSL :-) ... not quite difficult
> - Wrap Morphia for MongoDB in our own OSGI bundle (may that works)
>
> And last but not least: Contributing to open source is definitely an option
> for me. But first I have to "get my feet wet" ...
>
> With kind regards
> Bert.
>
> Am Di., 6. Sept. 2022 um 10:35 Uhr schrieb ski n <raymondmeester@gmail.com
> >:
>
> > Hi Bert,
> >
> > The mailing list is fine for general discussions regarding Camel. It's
> > surely not just about questions on errors, but some share experience,
> > blogs, releases, projects or just need to some help with decisions they
> > need to make. This is all community based, so sometimes you are lucky
> that
> > people have time and the knowledge to help you, in other times there is
> no
> > one. We just help each other the best we can.
> >
> > Just note that the Camel Framework is both old and huge. It supports
> > hundreds technologies. Some have very good documentation, some are not so
> > well documented. You are very welcome to help when you have the time.
> >
> > More on Karaf. I personally have not a lot of knowledge on OSGi and CDI
> in
> > particular. I did run Camel with various runtimes including Karaf,
> Wildfly,
> > Spring Boot, Main and I build my own runtime Assimbly runtime (See also
> > discussion on runtimes:
> > https://lists.apache.org/list?users@camel.apache.org:2022-1 in the
> > archive).
> >
> > My personal experience is that every runtime has its advantages and
> > disadvantages. I had the easiest experience with Spring Boot, but for
> sure
> > other runtimes have their appeal. I agree that Karaf is very strong in
> > concept, but in practice can be complicated. Karaf actually was one of
> (or
> > the first) supported runtime for Camel, but that was purely focussed at
> > XML. Over the years it lost some traction, this is because modularization
> > in general (whether it's through OSGi or Java Modularization/Jigsaw) adds
> > complexity to applications and integrations. A lot of developer and
> > projects like frameworks and libraries abbondon this idea. For OSGi they
> > need for example build seperate jars and maintain extra files. The
> > popularity is fading. However there are still some developers that
> provide
> > excellent work in this area (like Jean-Baptiste Onofre) and who knows
> when
> > more people/companies will work on it will gain popularity.
> >
> > I think OSGi still have many advantages like:
> >
> > 1. BuildTime Modularity
> > 2. Runtime Modularity
> > 3. Hybrid (Works equally good on premisse and the cloud)
> >
> > That said I too had some issues with it. For example getting Groovy to
> > work properly:
> >
> > https://issues.apache.org/jira/browse/KARAF-7397?filter=-2
> >
> > At the end I found that for most runtimes one needs to adjust too much
> > code to let it run for the specific runtime. I just want to write plain
> > Java/Camel code and used Maven/Docker for
> modularization/containerization.
> > That's why I created my own runtime project (
> > https://github.com/assimbly/runtime). In comparison to my project, Karaf
> > however is excellent documented :)
> >
> > My point is that in open source there are always multiple strategies to
> > work on problems:
> >
> > 1. Report/Ask
> >
> > Use channels to ask/report. For Camel these are the mailing list, Zulip
> > (chat), StackOverflow and Jira. The mailing list/zulip are the most
> > approachable, but there you probably only get a direction how to get to a
> > solution (or even nothing, when there is no one to help on that subject.
> Or
> > Claus is on vacation...). StackOverflow and Jira have more chance that it
> > will get solved, but then it is expected that you provide a clear
> > description of the problem, the versions/runtime/os you need and often
> code
> > to reproduce the problem. But also this is best effort.
> >
> > 2. Workaround
> >
> > In a lot of cases, because Camel is just Java there are ways to
> workaround
> > an issue. I would say 9 out of 10 I could find some solution for things I
> > run into and that weren't well documented. Sometimes I asked a collegue
> and
> > we did some pair programming.
> >
> > 3. Commercial offerings
> >
> > If you need dedicated support (for example because you are in a large
> > organization) you can get commercial support from for example Red Hat,
> > Talend (and other
> > https://camel.apache.org/manual/commercial-camel-offerings.html). As a
> > free contractor I am dependent on the organization where I work for how
> > this is arranged, so this is not always on option.
> >
> > 4. Multiple middleware
> >
> > Though it may complicate your stack, it's sometimes good to mix
> middleware
> > tools. For example do some work on low-code level, and some in Camel
> code.
> > Maybe you don't need such difficult use cases in your code anymore when
> you
> > combine Camel with other middleware. There are Camel based platforms
> > (Syndesis, Dovetail, Assimbly Gateway) or non-camel based (Apache NiFi,
> > Apache Hop, Apache Kafka). Such middleware complement each other well.
> >
> > 5. Contribute
> >
> > Of course, the best way to make open source project better, is to deep
> > dive and contribute yourself by code or documentation.
> > https://camel.apache.org/community/contributing/
> >
> > In open source your are the driver. Rock on.
> >
> > Raymond
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Sep 6, 2022 at 8:47 AM Bert Speckels <be...@gmail.com>
> > wrote:
> >
> >> Thank you for clarification.
> >>
> >> Documentation about Camel Blueprint always reads only as an XML version
> of
> >> the Java DSL, which I don't particularly like. Maybe this is not
> entirely
> >> correct, but all blueprint documentation is about camel routes as XML,
> >> nothing about annotation based CDI (@Service + @Inject etc). Do I miss
> >> something?
> >>
> >> The other obstacle is a MongoDB ORM library for OSGI (currently we use
> >> Morphia). But that is of no concern to the Camel community ;-)
> >>
> >> All this disappoints me mainly because I actually think Camel and Karaf
> >> are
> >> perfect for our purpose ... for many use cases ... but in the end there
> is
> >> a lack of OSGI support for important frameworks/libraries. OSGI doesn't
> >> seem to be popular in the Java community...otherwise there would be more
> >> documentation and support here. I think OSGI is the best solution
> between
> >> microservices and monoliths, although I think Java is only partially
> >> suitable for microservices, at least if you want to run 100+ camel
> routes
> >> as individual microservices.
> >>
> >> Please forgive me for using this mailing list for such general
> >> "discussions" and sharing of experiences. I know: Normally, this mailing
> >> list is about very specific error situations...
> >>
> >> With kind regards
> >> Bert Speckels
> >>
> >> Nicolas Filotto <nf...@talend.com> schrieb am Mo., 5. Sept. 2022,
> >> 17:17:
> >>
> >> > Hi,
> >> >
> >> > Regarding camel-cdi, it has been deprecated in 2.x and removed in 3.x
> >> > AFAIK now you are supposed to use camel-blueprint instead.
> >> > Regarding camel-mongodb, it has been removed in 3.16.0 because we met
> >> some
> >> > problems when upgrading the version of the driver, if really needed
> >> please
> >> > create a Jira ticket in the Camel project, I will try to find a
> >> solution to
> >> > put it back.
> >> >
> >> > Regards,
> >> > Nicolas
> >> >
> >> >
> >> >
> >> > ------------------------------
> >> > *From:* Bert Speckels <be...@gmail.com>
> >> > *Sent:* Monday, September 5, 2022 12:44
> >> > *To:* users@camel.apache.org <us...@camel.apache.org>
> >> > *Subject:* Re: Camel and OSGI support
> >> >
> >> >
> >> >
> >> > Hi Again
> >> >
> >> > In fact, I'm extremely frustrated now. So excuse me if I sound a
> little
> >> > rude at this point. Actually I'm not like that. But not much remains
> of
> >> the
> >> > promising approach with Camel and Apache Karaf... similar to our first
> >> > approach with Quarkus.
> >> >
> >> > So far I've only encountered obstacles trying to use the following in
> >> > Karaf.
> >> >
> >> > CDI (most important)
> >> > camel-cdi apparently no longer exists as an OSGI bundle and pax-cdi
> >> alone
> >> > is not enough, because CDI (injection) is mainly used when building
> >> routes.
> >> > As far as I understand, this is only possible with Camel-CDI.
> >> >
> >> > MongoDB
> >> > Camel-mongo doesn't seem to exist either. It may be sufficient here to
> >> > address the MongoDB driver directly, since we probably do not
> >> necessarily
> >> > need the Camel-specific MongoDB API. The only thing missing is a
> >> suitable
> >> > OR mapper with OSGI support.
> >> >
> >> > EndpointDSL
> >> > camel-endpointsdsl does not support OSGI. However, there is an
> >> alternative
> >> > to this, although I don't really like concatenating configuration
> >> > parameters in a string.
> >> >
> >> > It's extremely frustrating right now having to figure all of this out
> >> > yourself. I just hope that one of you can explain to me that CDI still
> >> > works with Camel and Karaf.
> >> >
> >> > WIth kind regards
> >> > Bert.
> >> >
> >> > Am So., 4. Sept. 2022 um 15:42 Uhr schrieb Bert Speckels <
> >> > bert.speckels@gmail.com>:
> >> >
> >> > > Hello there
> >> > >
> >> > > I'm a bit desperate at the moment: We're switching our Camel routes
> >> (in a
> >> > > monolith, Camel 3.14.2) to OSGI bundles (Apache Karaf and upgrade to
> >> > Camel
> >> > > 3.18.1). Unfortunately I have some difficulties with this.
> >> > >
> >> > > For one thing, I'm missing a few Camel features: Unfortunately,
> >> > > "camel-endpointsdsl" doesn't exist as an OSGI feature/bundle, right?
> >> > > Neither 3.14.2 nmor 3.18.1 has OSGI support for that.
> >> > >
> >> > > Also missing in Camel 3.18.1 is the OSGI support of MongoDB, which
> >> still
> >> > > exists in 3.14.
> >> > >
> >> > > Also using CDI is quite confusing for me. Aries, Blueprint, Pax CDI,
> >> > > Camel-CDI... so many combinations... @Service, @OsgiServiceProvider,
> >> > > @Inject, @Reference... so many annotations, some of which are
> >> apparently
> >> > > deprecated. Currently we are using weld in our monolith:
> >> weld-se-shaded,
> >> > > deltaspike-cdictrl-weld with Camel-CDI.
> >> > >
> >> > > Overall, many (all?) tutorials and examples seem to be very
> outdated:
> >> I
> >> > > rarely find examples from 2020 or later. Apparently, even after
> 2020,
> >> so
> >> > > much has changed at Camel. Maybe you can point me to one or the
> other
> >> > > problem where I can get current information: OSGI-Mongo-Support,
> CDI,
> >> > > camel-endopointsdsl...
> >> > >
> >> > > With kind regards
> >> > > Bert Speckels
> >> > >
> >> >
> >> > *As a recipient of an email from Talend, your contact personal data
> will
> >> > be on our systems. Please see our privacy notice.
> >> > <https://www.talend.com/privacy/>*
> >> >
> >> >
> >> >
> >>
> >
>
Re: dynamic naming dlq
Posted by Bing Lu <mf...@yahoo.com.INVALID>.
thank you very much, sir.
On Tuesday, September 6, 2022 at 10:36:13 AM EDT, Claus Ibsen <cl...@gmail.com> wrote:
Hi
No but you can use a direct route, where you use toD to send to dynamic
queue,
something ala:
deadLetterChannel("direct:to-dlq")
from direct:to-dlq
toD("activemq:myerror-at-${routeId}")
On Tue, Sep 6, 2022 at 4:16 PM Bing Lu <mf...@yahoo.com.invalid> wrote:
> Hi, is there a way to dynamic name the dlq name based on routeid? I
> currently have it as the following which means every error is going to the
> same dlq. thanks
> errorHandler(deadLetterChannel("activemq:queue:sth.dlq"))
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: dynamic naming dlq
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
No but you can use a direct route, where you use toD to send to dynamic
queue,
something ala:
deadLetterChannel("direct:to-dlq")
from direct:to-dlq
toD("activemq:myerror-at-${routeId}")
On Tue, Sep 6, 2022 at 4:16 PM Bing Lu <mf...@yahoo.com.invalid> wrote:
> Hi, is there a way to dynamic name the dlq name based on routeid? I
> currently have it as the following which means every error is going to the
> same dlq. thanks
> errorHandler(deadLetterChannel("activemq:queue:sth.dlq"))
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
dynamic naming dlq
Posted by Bing Lu <mf...@yahoo.com.INVALID>.
Hi, is there a way to dynamic name the dlq name based on routeid? I currently have it as the following which means every error is going to the same dlq. thanks
errorHandler(deadLetterChannel("activemq:queue:sth.dlq"))
Re: Camel and OSGI support
Posted by George Daswani <ge...@hotmail.com>.
> Personally, I've used blueprint with OSGI, Camel for several years now -
still works just fine even with the latest version of Karaf (4.3.X -
haven't tried 4.4.1), Camel (3.18.1), and JDK 11.
Just to add more info, our camel routes are bundled as OSGI / JAR files,
and use BLUEPRINT with the JAVA DSL. The camel-context.xml file embedded
in the META-INF folder just bootstraps the Java DSL routebuilders. You
can bundle POJO's and standard Java code when implementing Processors etc,
the only XML file needed is that camel-context.xml.
On Tue, Sep 6, 2022 at 4:36 AM George Daswani <ge...@hotmail.com>
wrote:
> Personally, I've used blueprint with OSGI, Camel for several years now -
> still works just fine even with the latest version of Karaf (4.3.X -
> haven't tried 4.4.1), Camel (3.18.1), and JDK 11.
>
> On Tue, Sep 6, 2022 at 4:03 AM Bert Speckels <be...@gmail.com>
> wrote:
>
>> Some (all) good points Raymon
>>
>> I think this is a very good summary and I have nothing to add :-)
>>
>> Currently we are trying to use some workarounds:
>> - Live without CDI ... I think this is less painful than we think at the
>> moment.
>> - Build our own Endpoint DSL :-) ... not quite difficult
>> - Wrap Morphia for MongoDB in our own OSGI bundle (may that works)
>>
>> And last but not least: Contributing to open source is definitely an
>> option
>> for me. But first I have to "get my feet wet" ...
>>
>> With kind regards
>> Bert.
>>
>> Am Di., 6. Sept. 2022 um 10:35 Uhr schrieb ski n <
>> raymondmeester@gmail.com>:
>>
>> > Hi Bert,
>> >
>> > The mailing list is fine for general discussions regarding Camel. It's
>> > surely not just about questions on errors, but some share experience,
>> > blogs, releases, projects or just need to some help with decisions they
>> > need to make. This is all community based, so sometimes you are lucky
>> that
>> > people have time and the knowledge to help you, in other times there is
>> no
>> > one. We just help each other the best we can.
>> >
>> > Just note that the Camel Framework is both old and huge. It supports
>> > hundreds technologies. Some have very good documentation, some are not
>> so
>> > well documented. You are very welcome to help when you have the time.
>> >
>> > More on Karaf. I personally have not a lot of knowledge on OSGi and CDI
>> in
>> > particular. I did run Camel with various runtimes including Karaf,
>> Wildfly,
>> > Spring Boot, Main and I build my own runtime Assimbly runtime (See also
>> > discussion on runtimes:
>> > https://lists.apache.org/list?users@camel.apache.org:2022-1 in the
>> > archive).
>> >
>> > My personal experience is that every runtime has its advantages and
>> > disadvantages. I had the easiest experience with Spring Boot, but for
>> sure
>> > other runtimes have their appeal. I agree that Karaf is very strong in
>> > concept, but in practice can be complicated. Karaf actually was one of
>> (or
>> > the first) supported runtime for Camel, but that was purely focussed at
>> > XML. Over the years it lost some traction, this is because
>> modularization
>> > in general (whether it's through OSGi or Java Modularization/Jigsaw)
>> adds
>> > complexity to applications and integrations. A lot of developer and
>> > projects like frameworks and libraries abbondon this idea. For OSGi they
>> > need for example build seperate jars and maintain extra files. The
>> > popularity is fading. However there are still some developers that
>> provide
>> > excellent work in this area (like Jean-Baptiste Onofre) and who knows
>> when
>> > more people/companies will work on it will gain popularity.
>> >
>> > I think OSGi still have many advantages like:
>> >
>> > 1. BuildTime Modularity
>> > 2. Runtime Modularity
>> > 3. Hybrid (Works equally good on premisse and the cloud)
>> >
>> > That said I too had some issues with it. For example getting Groovy to
>> > work properly:
>> >
>> > https://issues.apache.org/jira/browse/KARAF-7397?filter=-2
>> >
>> > At the end I found that for most runtimes one needs to adjust too much
>> > code to let it run for the specific runtime. I just want to write plain
>> > Java/Camel code and used Maven/Docker for
>> modularization/containerization.
>> > That's why I created my own runtime project (
>> > https://github.com/assimbly/runtime). In comparison to my project,
>> Karaf
>> > however is excellent documented :)
>> >
>> > My point is that in open source there are always multiple strategies to
>> > work on problems:
>> >
>> > 1. Report/Ask
>> >
>> > Use channels to ask/report. For Camel these are the mailing list, Zulip
>> > (chat), StackOverflow and Jira. The mailing list/zulip are the most
>> > approachable, but there you probably only get a direction how to get to
>> a
>> > solution (or even nothing, when there is no one to help on that
>> subject. Or
>> > Claus is on vacation...). StackOverflow and Jira have more chance that
>> it
>> > will get solved, but then it is expected that you provide a clear
>> > description of the problem, the versions/runtime/os you need and often
>> code
>> > to reproduce the problem. But also this is best effort.
>> >
>> > 2. Workaround
>> >
>> > In a lot of cases, because Camel is just Java there are ways to
>> workaround
>> > an issue. I would say 9 out of 10 I could find some solution for things
>> I
>> > run into and that weren't well documented. Sometimes I asked a collegue
>> and
>> > we did some pair programming.
>> >
>> > 3. Commercial offerings
>> >
>> > If you need dedicated support (for example because you are in a large
>> > organization) you can get commercial support from for example Red Hat,
>> > Talend (and other
>> > https://camel.apache.org/manual/commercial-camel-offerings.html). As a
>> > free contractor I am dependent on the organization where I work for how
>> > this is arranged, so this is not always on option.
>> >
>> > 4. Multiple middleware
>> >
>> > Though it may complicate your stack, it's sometimes good to mix
>> middleware
>> > tools. For example do some work on low-code level, and some in Camel
>> code.
>> > Maybe you don't need such difficult use cases in your code anymore when
>> you
>> > combine Camel with other middleware. There are Camel based platforms
>> > (Syndesis, Dovetail, Assimbly Gateway) or non-camel based (Apache NiFi,
>> > Apache Hop, Apache Kafka). Such middleware complement each other well.
>> >
>> > 5. Contribute
>> >
>> > Of course, the best way to make open source project better, is to deep
>> > dive and contribute yourself by code or documentation.
>> > https://camel.apache.org/community/contributing/
>> >
>> > In open source your are the driver. Rock on.
>> >
>> > Raymond
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Tue, Sep 6, 2022 at 8:47 AM Bert Speckels <be...@gmail.com>
>> > wrote:
>> >
>> >> Thank you for clarification.
>> >>
>> >> Documentation about Camel Blueprint always reads only as an XML
>> version of
>> >> the Java DSL, which I don't particularly like. Maybe this is not
>> entirely
>> >> correct, but all blueprint documentation is about camel routes as XML,
>> >> nothing about annotation based CDI (@Service + @Inject etc). Do I miss
>> >> something?
>> >>
>> >> The other obstacle is a MongoDB ORM library for OSGI (currently we use
>> >> Morphia). But that is of no concern to the Camel community ;-)
>> >>
>> >> All this disappoints me mainly because I actually think Camel and Karaf
>> >> are
>> >> perfect for our purpose ... for many use cases ... but in the end
>> there is
>> >> a lack of OSGI support for important frameworks/libraries. OSGI doesn't
>> >> seem to be popular in the Java community...otherwise there would be
>> more
>> >> documentation and support here. I think OSGI is the best solution
>> between
>> >> microservices and monoliths, although I think Java is only partially
>> >> suitable for microservices, at least if you want to run 100+ camel
>> routes
>> >> as individual microservices.
>> >>
>> >> Please forgive me for using this mailing list for such general
>> >> "discussions" and sharing of experiences. I know: Normally, this
>> mailing
>> >> list is about very specific error situations...
>> >>
>> >> With kind regards
>> >> Bert Speckels
>> >>
>> >> Nicolas Filotto <nf...@talend.com> schrieb am Mo., 5. Sept. 2022,
>> >> 17:17:
>> >>
>> >> > Hi,
>> >> >
>> >> > Regarding camel-cdi, it has been deprecated in 2.x and removed in 3.x
>> >> > AFAIK now you are supposed to use camel-blueprint instead.
>> >> > Regarding camel-mongodb, it has been removed in 3.16.0 because we met
>> >> some
>> >> > problems when upgrading the version of the driver, if really needed
>> >> please
>> >> > create a Jira ticket in the Camel project, I will try to find a
>> >> solution to
>> >> > put it back.
>> >> >
>> >> > Regards,
>> >> > Nicolas
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------
>> >> > *From:* Bert Speckels <be...@gmail.com>
>> >> > *Sent:* Monday, September 5, 2022 12:44
>> >> > *To:* users@camel.apache.org <us...@camel.apache.org>
>> >> > *Subject:* Re: Camel and OSGI support
>> >> >
>> >> >
>> >> >
>> >> > Hi Again
>> >> >
>> >> > In fact, I'm extremely frustrated now. So excuse me if I sound a
>> little
>> >> > rude at this point. Actually I'm not like that. But not much remains
>> of
>> >> the
>> >> > promising approach with Camel and Apache Karaf... similar to our
>> first
>> >> > approach with Quarkus.
>> >> >
>> >> > So far I've only encountered obstacles trying to use the following in
>> >> > Karaf.
>> >> >
>> >> > CDI (most important)
>> >> > camel-cdi apparently no longer exists as an OSGI bundle and pax-cdi
>> >> alone
>> >> > is not enough, because CDI (injection) is mainly used when building
>> >> routes.
>> >> > As far as I understand, this is only possible with Camel-CDI.
>> >> >
>> >> > MongoDB
>> >> > Camel-mongo doesn't seem to exist either. It may be sufficient here
>> to
>> >> > address the MongoDB driver directly, since we probably do not
>> >> necessarily
>> >> > need the Camel-specific MongoDB API. The only thing missing is a
>> >> suitable
>> >> > OR mapper with OSGI support.
>> >> >
>> >> > EndpointDSL
>> >> > camel-endpointsdsl does not support OSGI. However, there is an
>> >> alternative
>> >> > to this, although I don't really like concatenating configuration
>> >> > parameters in a string.
>> >> >
>> >> > It's extremely frustrating right now having to figure all of this out
>> >> > yourself. I just hope that one of you can explain to me that CDI
>> still
>> >> > works with Camel and Karaf.
>> >> >
>> >> > WIth kind regards
>> >> > Bert.
>> >> >
>> >> > Am So., 4. Sept. 2022 um 15:42 Uhr schrieb Bert Speckels <
>> >> > bert.speckels@gmail.com>:
>> >> >
>> >> > > Hello there
>> >> > >
>> >> > > I'm a bit desperate at the moment: We're switching our Camel routes
>> >> (in a
>> >> > > monolith, Camel 3.14.2) to OSGI bundles (Apache Karaf and upgrade
>> to
>> >> > Camel
>> >> > > 3.18.1). Unfortunately I have some difficulties with this.
>> >> > >
>> >> > > For one thing, I'm missing a few Camel features: Unfortunately,
>> >> > > "camel-endpointsdsl" doesn't exist as an OSGI feature/bundle,
>> right?
>> >> > > Neither 3.14.2 nmor 3.18.1 has OSGI support for that.
>> >> > >
>> >> > > Also missing in Camel 3.18.1 is the OSGI support of MongoDB, which
>> >> still
>> >> > > exists in 3.14.
>> >> > >
>> >> > > Also using CDI is quite confusing for me. Aries, Blueprint, Pax
>> CDI,
>> >> > > Camel-CDI... so many combinations... @Service,
>> @OsgiServiceProvider,
>> >> > > @Inject, @Reference... so many annotations, some of which are
>> >> apparently
>> >> > > deprecated. Currently we are using weld in our monolith:
>> >> weld-se-shaded,
>> >> > > deltaspike-cdictrl-weld with Camel-CDI.
>> >> > >
>> >> > > Overall, many (all?) tutorials and examples seem to be very
>> outdated:
>> >> I
>> >> > > rarely find examples from 2020 or later. Apparently, even after
>> 2020,
>> >> so
>> >> > > much has changed at Camel. Maybe you can point me to one or the
>> other
>> >> > > problem where I can get current information: OSGI-Mongo-Support,
>> CDI,
>> >> > > camel-endopointsdsl...
>> >> > >
>> >> > > With kind regards
>> >> > > Bert Speckels
>> >> > >
>> >> >
>> >> > *As a recipient of an email from Talend, your contact personal data
>> will
>> >> > be on our systems. Please see our privacy notice.
>> >> > <https://www.talend.com/privacy/>*
>> >> >
>> >> >
>> >> >
>> >>
>> >
>>
>
Re: Camel and OSGI support
Posted by Bert Speckels <be...@gmail.com>.
Some (all) good points Raymon
I think this is a very good summary and I have nothing to add :-)
Currently we are trying to use some workarounds:
- Live without CDI ... I think this is less painful than we think at the
moment.
- Build our own Endpoint DSL :-) ... not quite difficult
- Wrap Morphia for MongoDB in our own OSGI bundle (may that works)
And last but not least: Contributing to open source is definitely an option
for me. But first I have to "get my feet wet" ...
With kind regards
Bert.
Am Di., 6. Sept. 2022 um 10:35 Uhr schrieb ski n <ra...@gmail.com>:
> Hi Bert,
>
> The mailing list is fine for general discussions regarding Camel. It's
> surely not just about questions on errors, but some share experience,
> blogs, releases, projects or just need to some help with decisions they
> need to make. This is all community based, so sometimes you are lucky that
> people have time and the knowledge to help you, in other times there is no
> one. We just help each other the best we can.
>
> Just note that the Camel Framework is both old and huge. It supports
> hundreds technologies. Some have very good documentation, some are not so
> well documented. You are very welcome to help when you have the time.
>
> More on Karaf. I personally have not a lot of knowledge on OSGi and CDI in
> particular. I did run Camel with various runtimes including Karaf, Wildfly,
> Spring Boot, Main and I build my own runtime Assimbly runtime (See also
> discussion on runtimes:
> https://lists.apache.org/list?users@camel.apache.org:2022-1 in the
> archive).
>
> My personal experience is that every runtime has its advantages and
> disadvantages. I had the easiest experience with Spring Boot, but for sure
> other runtimes have their appeal. I agree that Karaf is very strong in
> concept, but in practice can be complicated. Karaf actually was one of (or
> the first) supported runtime for Camel, but that was purely focussed at
> XML. Over the years it lost some traction, this is because modularization
> in general (whether it's through OSGi or Java Modularization/Jigsaw) adds
> complexity to applications and integrations. A lot of developer and
> projects like frameworks and libraries abbondon this idea. For OSGi they
> need for example build seperate jars and maintain extra files. The
> popularity is fading. However there are still some developers that provide
> excellent work in this area (like Jean-Baptiste Onofre) and who knows when
> more people/companies will work on it will gain popularity.
>
> I think OSGi still have many advantages like:
>
> 1. BuildTime Modularity
> 2. Runtime Modularity
> 3. Hybrid (Works equally good on premisse and the cloud)
>
> That said I too had some issues with it. For example getting Groovy to
> work properly:
>
> https://issues.apache.org/jira/browse/KARAF-7397?filter=-2
>
> At the end I found that for most runtimes one needs to adjust too much
> code to let it run for the specific runtime. I just want to write plain
> Java/Camel code and used Maven/Docker for modularization/containerization.
> That's why I created my own runtime project (
> https://github.com/assimbly/runtime). In comparison to my project, Karaf
> however is excellent documented :)
>
> My point is that in open source there are always multiple strategies to
> work on problems:
>
> 1. Report/Ask
>
> Use channels to ask/report. For Camel these are the mailing list, Zulip
> (chat), StackOverflow and Jira. The mailing list/zulip are the most
> approachable, but there you probably only get a direction how to get to a
> solution (or even nothing, when there is no one to help on that subject. Or
> Claus is on vacation...). StackOverflow and Jira have more chance that it
> will get solved, but then it is expected that you provide a clear
> description of the problem, the versions/runtime/os you need and often code
> to reproduce the problem. But also this is best effort.
>
> 2. Workaround
>
> In a lot of cases, because Camel is just Java there are ways to workaround
> an issue. I would say 9 out of 10 I could find some solution for things I
> run into and that weren't well documented. Sometimes I asked a collegue and
> we did some pair programming.
>
> 3. Commercial offerings
>
> If you need dedicated support (for example because you are in a large
> organization) you can get commercial support from for example Red Hat,
> Talend (and other
> https://camel.apache.org/manual/commercial-camel-offerings.html). As a
> free contractor I am dependent on the organization where I work for how
> this is arranged, so this is not always on option.
>
> 4. Multiple middleware
>
> Though it may complicate your stack, it's sometimes good to mix middleware
> tools. For example do some work on low-code level, and some in Camel code.
> Maybe you don't need such difficult use cases in your code anymore when you
> combine Camel with other middleware. There are Camel based platforms
> (Syndesis, Dovetail, Assimbly Gateway) or non-camel based (Apache NiFi,
> Apache Hop, Apache Kafka). Such middleware complement each other well.
>
> 5. Contribute
>
> Of course, the best way to make open source project better, is to deep
> dive and contribute yourself by code or documentation.
> https://camel.apache.org/community/contributing/
>
> In open source your are the driver. Rock on.
>
> Raymond
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Sep 6, 2022 at 8:47 AM Bert Speckels <be...@gmail.com>
> wrote:
>
>> Thank you for clarification.
>>
>> Documentation about Camel Blueprint always reads only as an XML version of
>> the Java DSL, which I don't particularly like. Maybe this is not entirely
>> correct, but all blueprint documentation is about camel routes as XML,
>> nothing about annotation based CDI (@Service + @Inject etc). Do I miss
>> something?
>>
>> The other obstacle is a MongoDB ORM library for OSGI (currently we use
>> Morphia). But that is of no concern to the Camel community ;-)
>>
>> All this disappoints me mainly because I actually think Camel and Karaf
>> are
>> perfect for our purpose ... for many use cases ... but in the end there is
>> a lack of OSGI support for important frameworks/libraries. OSGI doesn't
>> seem to be popular in the Java community...otherwise there would be more
>> documentation and support here. I think OSGI is the best solution between
>> microservices and monoliths, although I think Java is only partially
>> suitable for microservices, at least if you want to run 100+ camel routes
>> as individual microservices.
>>
>> Please forgive me for using this mailing list for such general
>> "discussions" and sharing of experiences. I know: Normally, this mailing
>> list is about very specific error situations...
>>
>> With kind regards
>> Bert Speckels
>>
>> Nicolas Filotto <nf...@talend.com> schrieb am Mo., 5. Sept. 2022,
>> 17:17:
>>
>> > Hi,
>> >
>> > Regarding camel-cdi, it has been deprecated in 2.x and removed in 3.x
>> > AFAIK now you are supposed to use camel-blueprint instead.
>> > Regarding camel-mongodb, it has been removed in 3.16.0 because we met
>> some
>> > problems when upgrading the version of the driver, if really needed
>> please
>> > create a Jira ticket in the Camel project, I will try to find a
>> solution to
>> > put it back.
>> >
>> > Regards,
>> > Nicolas
>> >
>> >
>> >
>> > ------------------------------
>> > *From:* Bert Speckels <be...@gmail.com>
>> > *Sent:* Monday, September 5, 2022 12:44
>> > *To:* users@camel.apache.org <us...@camel.apache.org>
>> > *Subject:* Re: Camel and OSGI support
>> >
>> >
>> >
>> > Hi Again
>> >
>> > In fact, I'm extremely frustrated now. So excuse me if I sound a little
>> > rude at this point. Actually I'm not like that. But not much remains of
>> the
>> > promising approach with Camel and Apache Karaf... similar to our first
>> > approach with Quarkus.
>> >
>> > So far I've only encountered obstacles trying to use the following in
>> > Karaf.
>> >
>> > CDI (most important)
>> > camel-cdi apparently no longer exists as an OSGI bundle and pax-cdi
>> alone
>> > is not enough, because CDI (injection) is mainly used when building
>> routes.
>> > As far as I understand, this is only possible with Camel-CDI.
>> >
>> > MongoDB
>> > Camel-mongo doesn't seem to exist either. It may be sufficient here to
>> > address the MongoDB driver directly, since we probably do not
>> necessarily
>> > need the Camel-specific MongoDB API. The only thing missing is a
>> suitable
>> > OR mapper with OSGI support.
>> >
>> > EndpointDSL
>> > camel-endpointsdsl does not support OSGI. However, there is an
>> alternative
>> > to this, although I don't really like concatenating configuration
>> > parameters in a string.
>> >
>> > It's extremely frustrating right now having to figure all of this out
>> > yourself. I just hope that one of you can explain to me that CDI still
>> > works with Camel and Karaf.
>> >
>> > WIth kind regards
>> > Bert.
>> >
>> > Am So., 4. Sept. 2022 um 15:42 Uhr schrieb Bert Speckels <
>> > bert.speckels@gmail.com>:
>> >
>> > > Hello there
>> > >
>> > > I'm a bit desperate at the moment: We're switching our Camel routes
>> (in a
>> > > monolith, Camel 3.14.2) to OSGI bundles (Apache Karaf and upgrade to
>> > Camel
>> > > 3.18.1). Unfortunately I have some difficulties with this.
>> > >
>> > > For one thing, I'm missing a few Camel features: Unfortunately,
>> > > "camel-endpointsdsl" doesn't exist as an OSGI feature/bundle, right?
>> > > Neither 3.14.2 nmor 3.18.1 has OSGI support for that.
>> > >
>> > > Also missing in Camel 3.18.1 is the OSGI support of MongoDB, which
>> still
>> > > exists in 3.14.
>> > >
>> > > Also using CDI is quite confusing for me. Aries, Blueprint, Pax CDI,
>> > > Camel-CDI... so many combinations... @Service, @OsgiServiceProvider,
>> > > @Inject, @Reference... so many annotations, some of which are
>> apparently
>> > > deprecated. Currently we are using weld in our monolith:
>> weld-se-shaded,
>> > > deltaspike-cdictrl-weld with Camel-CDI.
>> > >
>> > > Overall, many (all?) tutorials and examples seem to be very outdated:
>> I
>> > > rarely find examples from 2020 or later. Apparently, even after 2020,
>> so
>> > > much has changed at Camel. Maybe you can point me to one or the other
>> > > problem where I can get current information: OSGI-Mongo-Support, CDI,
>> > > camel-endopointsdsl...
>> > >
>> > > With kind regards
>> > > Bert Speckels
>> > >
>> >
>> > *As a recipient of an email from Talend, your contact personal data will
>> > be on our systems. Please see our privacy notice.
>> > <https://www.talend.com/privacy/>*
>> >
>> >
>> >
>>
>
Re: Camel and OSGI support
Posted by ski n <ra...@gmail.com>.
Hi Bert,
The mailing list is fine for general discussions regarding Camel. It's
surely not just about questions on errors, but some share experience,
blogs, releases, projects or just need to some help with decisions they
need to make. This is all community based, so sometimes you are lucky that
people have time and the knowledge to help you, in other times there is no
one. We just help each other the best we can.
Just note that the Camel Framework is both old and huge. It supports
hundreds technologies. Some have very good documentation, some are not so
well documented. You are very welcome to help when you have the time.
More on Karaf. I personally have not a lot of knowledge on OSGi and CDI in
particular. I did run Camel with various runtimes including Karaf, Wildfly,
Spring Boot, Main and I build my own runtime Assimbly runtime (See also
discussion on runtimes:
https://lists.apache.org/list?users@camel.apache.org:2022-1 in the archive).
My personal experience is that every runtime has its advantages and
disadvantages. I had the easiest experience with Spring Boot, but for sure
other runtimes have their appeal. I agree that Karaf is very strong in
concept, but in practice can be complicated. Karaf actually was one of (or
the first) supported runtime for Camel, but that was purely focussed at
XML. Over the years it lost some traction, this is because modularization
in general (whether it's through OSGi or Java Modularization/Jigsaw) adds
complexity to applications and integrations. A lot of developer and
projects like frameworks and libraries abbondon this idea. For OSGi they
need for example build seperate jars and maintain extra files. The
popularity is fading. However there are still some developers that provide
excellent work in this area (like Jean-Baptiste Onofre) and who knows when
more people/companies will work on it will gain popularity.
I think OSGi still have many advantages like:
1. BuildTime Modularity
2. Runtime Modularity
3. Hybrid (Works equally good on premisse and the cloud)
That said I too had some issues with it. For example getting Groovy to work
properly:
https://issues.apache.org/jira/browse/KARAF-7397?filter=-2
At the end I found that for most runtimes one needs to adjust too much code
to let it run for the specific runtime. I just want to write plain
Java/Camel code and used Maven/Docker for modularization/containerization.
That's why I created my own runtime project (
https://github.com/assimbly/runtime). In comparison to my project, Karaf
however is excellent documented :)
My point is that in open source there are always multiple strategies to
work on problems:
1. Report/Ask
Use channels to ask/report. For Camel these are the mailing list, Zulip
(chat), StackOverflow and Jira. The mailing list/zulip are the most
approachable, but there you probably only get a direction how to get to a
solution (or even nothing, when there is no one to help on that subject. Or
Claus is on vacation...). StackOverflow and Jira have more chance that it
will get solved, but then it is expected that you provide a clear
description of the problem, the versions/runtime/os you need and often code
to reproduce the problem. But also this is best effort.
2. Workaround
In a lot of cases, because Camel is just Java there are ways to workaround
an issue. I would say 9 out of 10 I could find some solution for things I
run into and that weren't well documented. Sometimes I asked a collegue and
we did some pair programming.
3. Commercial offerings
If you need dedicated support (for example because you are in a large
organization) you can get commercial support from for example Red Hat,
Talend (and other
https://camel.apache.org/manual/commercial-camel-offerings.html). As a free
contractor I am dependent on the organization where I work for how this is
arranged, so this is not always on option.
4. Multiple middleware
Though it may complicate your stack, it's sometimes good to mix middleware
tools. For example do some work on low-code level, and some in Camel code.
Maybe you don't need such difficult use cases in your code anymore when you
combine Camel with other middleware. There are Camel based platforms
(Syndesis, Dovetail, Assimbly Gateway) or non-camel based (Apache NiFi,
Apache Hop, Apache Kafka). Such middleware complement each other well.
5. Contribute
Of course, the best way to make open source project better, is to deep dive
and contribute yourself by code or documentation.
https://camel.apache.org/community/contributing/
In open source your are the driver. Rock on.
Raymond
On Tue, Sep 6, 2022 at 8:47 AM Bert Speckels <be...@gmail.com>
wrote:
> Thank you for clarification.
>
> Documentation about Camel Blueprint always reads only as an XML version of
> the Java DSL, which I don't particularly like. Maybe this is not entirely
> correct, but all blueprint documentation is about camel routes as XML,
> nothing about annotation based CDI (@Service + @Inject etc). Do I miss
> something?
>
> The other obstacle is a MongoDB ORM library for OSGI (currently we use
> Morphia). But that is of no concern to the Camel community ;-)
>
> All this disappoints me mainly because I actually think Camel and Karaf are
> perfect for our purpose ... for many use cases ... but in the end there is
> a lack of OSGI support for important frameworks/libraries. OSGI doesn't
> seem to be popular in the Java community...otherwise there would be more
> documentation and support here. I think OSGI is the best solution between
> microservices and monoliths, although I think Java is only partially
> suitable for microservices, at least if you want to run 100+ camel routes
> as individual microservices.
>
> Please forgive me for using this mailing list for such general
> "discussions" and sharing of experiences. I know: Normally, this mailing
> list is about very specific error situations...
>
> With kind regards
> Bert Speckels
>
> Nicolas Filotto <nf...@talend.com> schrieb am Mo., 5. Sept. 2022,
> 17:17:
>
> > Hi,
> >
> > Regarding camel-cdi, it has been deprecated in 2.x and removed in 3.x
> > AFAIK now you are supposed to use camel-blueprint instead.
> > Regarding camel-mongodb, it has been removed in 3.16.0 because we met
> some
> > problems when upgrading the version of the driver, if really needed
> please
> > create a Jira ticket in the Camel project, I will try to find a solution
> to
> > put it back.
> >
> > Regards,
> > Nicolas
> >
> >
> >
> > ------------------------------
> > *From:* Bert Speckels <be...@gmail.com>
> > *Sent:* Monday, September 5, 2022 12:44
> > *To:* users@camel.apache.org <us...@camel.apache.org>
> > *Subject:* Re: Camel and OSGI support
> >
> >
> >
> > Hi Again
> >
> > In fact, I'm extremely frustrated now. So excuse me if I sound a little
> > rude at this point. Actually I'm not like that. But not much remains of
> the
> > promising approach with Camel and Apache Karaf... similar to our first
> > approach with Quarkus.
> >
> > So far I've only encountered obstacles trying to use the following in
> > Karaf.
> >
> > CDI (most important)
> > camel-cdi apparently no longer exists as an OSGI bundle and pax-cdi alone
> > is not enough, because CDI (injection) is mainly used when building
> routes.
> > As far as I understand, this is only possible with Camel-CDI.
> >
> > MongoDB
> > Camel-mongo doesn't seem to exist either. It may be sufficient here to
> > address the MongoDB driver directly, since we probably do not necessarily
> > need the Camel-specific MongoDB API. The only thing missing is a suitable
> > OR mapper with OSGI support.
> >
> > EndpointDSL
> > camel-endpointsdsl does not support OSGI. However, there is an
> alternative
> > to this, although I don't really like concatenating configuration
> > parameters in a string.
> >
> > It's extremely frustrating right now having to figure all of this out
> > yourself. I just hope that one of you can explain to me that CDI still
> > works with Camel and Karaf.
> >
> > WIth kind regards
> > Bert.
> >
> > Am So., 4. Sept. 2022 um 15:42 Uhr schrieb Bert Speckels <
> > bert.speckels@gmail.com>:
> >
> > > Hello there
> > >
> > > I'm a bit desperate at the moment: We're switching our Camel routes
> (in a
> > > monolith, Camel 3.14.2) to OSGI bundles (Apache Karaf and upgrade to
> > Camel
> > > 3.18.1). Unfortunately I have some difficulties with this.
> > >
> > > For one thing, I'm missing a few Camel features: Unfortunately,
> > > "camel-endpointsdsl" doesn't exist as an OSGI feature/bundle, right?
> > > Neither 3.14.2 nmor 3.18.1 has OSGI support for that.
> > >
> > > Also missing in Camel 3.18.1 is the OSGI support of MongoDB, which
> still
> > > exists in 3.14.
> > >
> > > Also using CDI is quite confusing for me. Aries, Blueprint, Pax CDI,
> > > Camel-CDI... so many combinations... @Service, @OsgiServiceProvider,
> > > @Inject, @Reference... so many annotations, some of which are
> apparently
> > > deprecated. Currently we are using weld in our monolith:
> weld-se-shaded,
> > > deltaspike-cdictrl-weld with Camel-CDI.
> > >
> > > Overall, many (all?) tutorials and examples seem to be very outdated: I
> > > rarely find examples from 2020 or later. Apparently, even after 2020,
> so
> > > much has changed at Camel. Maybe you can point me to one or the other
> > > problem where I can get current information: OSGI-Mongo-Support, CDI,
> > > camel-endopointsdsl...
> > >
> > > With kind regards
> > > Bert Speckels
> > >
> >
> > *As a recipient of an email from Talend, your contact personal data will
> > be on our systems. Please see our privacy notice.
> > <https://www.talend.com/privacy/>*
> >
> >
> >
>
Re: Camel and OSGI support
Posted by Bert Speckels <be...@gmail.com>.
Thank you for clarification.
Documentation about Camel Blueprint always reads only as an XML version of
the Java DSL, which I don't particularly like. Maybe this is not entirely
correct, but all blueprint documentation is about camel routes as XML,
nothing about annotation based CDI (@Service + @Inject etc). Do I miss
something?
The other obstacle is a MongoDB ORM library for OSGI (currently we use
Morphia). But that is of no concern to the Camel community ;-)
All this disappoints me mainly because I actually think Camel and Karaf are
perfect for our purpose ... for many use cases ... but in the end there is
a lack of OSGI support for important frameworks/libraries. OSGI doesn't
seem to be popular in the Java community...otherwise there would be more
documentation and support here. I think OSGI is the best solution between
microservices and monoliths, although I think Java is only partially
suitable for microservices, at least if you want to run 100+ camel routes
as individual microservices.
Please forgive me for using this mailing list for such general
"discussions" and sharing of experiences. I know: Normally, this mailing
list is about very specific error situations...
With kind regards
Bert Speckels
Nicolas Filotto <nf...@talend.com> schrieb am Mo., 5. Sept. 2022, 17:17:
> Hi,
>
> Regarding camel-cdi, it has been deprecated in 2.x and removed in 3.x
> AFAIK now you are supposed to use camel-blueprint instead.
> Regarding camel-mongodb, it has been removed in 3.16.0 because we met some
> problems when upgrading the version of the driver, if really needed please
> create a Jira ticket in the Camel project, I will try to find a solution to
> put it back.
>
> Regards,
> Nicolas
>
>
>
> ------------------------------
> *From:* Bert Speckels <be...@gmail.com>
> *Sent:* Monday, September 5, 2022 12:44
> *To:* users@camel.apache.org <us...@camel.apache.org>
> *Subject:* Re: Camel and OSGI support
>
>
>
> Hi Again
>
> In fact, I'm extremely frustrated now. So excuse me if I sound a little
> rude at this point. Actually I'm not like that. But not much remains of the
> promising approach with Camel and Apache Karaf... similar to our first
> approach with Quarkus.
>
> So far I've only encountered obstacles trying to use the following in
> Karaf.
>
> CDI (most important)
> camel-cdi apparently no longer exists as an OSGI bundle and pax-cdi alone
> is not enough, because CDI (injection) is mainly used when building routes.
> As far as I understand, this is only possible with Camel-CDI.
>
> MongoDB
> Camel-mongo doesn't seem to exist either. It may be sufficient here to
> address the MongoDB driver directly, since we probably do not necessarily
> need the Camel-specific MongoDB API. The only thing missing is a suitable
> OR mapper with OSGI support.
>
> EndpointDSL
> camel-endpointsdsl does not support OSGI. However, there is an alternative
> to this, although I don't really like concatenating configuration
> parameters in a string.
>
> It's extremely frustrating right now having to figure all of this out
> yourself. I just hope that one of you can explain to me that CDI still
> works with Camel and Karaf.
>
> WIth kind regards
> Bert.
>
> Am So., 4. Sept. 2022 um 15:42 Uhr schrieb Bert Speckels <
> bert.speckels@gmail.com>:
>
> > Hello there
> >
> > I'm a bit desperate at the moment: We're switching our Camel routes (in a
> > monolith, Camel 3.14.2) to OSGI bundles (Apache Karaf and upgrade to
> Camel
> > 3.18.1). Unfortunately I have some difficulties with this.
> >
> > For one thing, I'm missing a few Camel features: Unfortunately,
> > "camel-endpointsdsl" doesn't exist as an OSGI feature/bundle, right?
> > Neither 3.14.2 nmor 3.18.1 has OSGI support for that.
> >
> > Also missing in Camel 3.18.1 is the OSGI support of MongoDB, which still
> > exists in 3.14.
> >
> > Also using CDI is quite confusing for me. Aries, Blueprint, Pax CDI,
> > Camel-CDI... so many combinations... @Service, @OsgiServiceProvider,
> > @Inject, @Reference... so many annotations, some of which are apparently
> > deprecated. Currently we are using weld in our monolith: weld-se-shaded,
> > deltaspike-cdictrl-weld with Camel-CDI.
> >
> > Overall, many (all?) tutorials and examples seem to be very outdated: I
> > rarely find examples from 2020 or later. Apparently, even after 2020, so
> > much has changed at Camel. Maybe you can point me to one or the other
> > problem where I can get current information: OSGI-Mongo-Support, CDI,
> > camel-endopointsdsl...
> >
> > With kind regards
> > Bert Speckels
> >
>
> *As a recipient of an email from Talend, your contact personal data will
> be on our systems. Please see our privacy notice.
> <https://www.talend.com/privacy/>*
>
>
>
Re: Camel and OSGI support
Posted by Nicolas Filotto <nf...@talend.com>.
Hi,
Regarding camel-cdi, it has been deprecated in 2.x and removed in 3.x AFAIK now you are supposed to use camel-blueprint instead.
Regarding camel-mongodb, it has been removed in 3.16.0 because we met some problems when upgrading the version of the driver, if really needed please create a Jira ticket in the Camel project, I will try to find a solution to put it back.
Regards,
Nicolas
________________________________
From: Bert Speckels <be...@gmail.com>
Sent: Monday, September 5, 2022 12:44
To: users@camel.apache.org <us...@camel.apache.org>
Subject: Re: Camel and OSGI support
Hi Again
In fact, I'm extremely frustrated now. So excuse me if I sound a little
rude at this point. Actually I'm not like that. But not much remains of the
promising approach with Camel and Apache Karaf... similar to our first
approach with Quarkus.
So far I've only encountered obstacles trying to use the following in
Karaf.
CDI (most important)
camel-cdi apparently no longer exists as an OSGI bundle and pax-cdi alone
is not enough, because CDI (injection) is mainly used when building routes.
As far as I understand, this is only possible with Camel-CDI.
MongoDB
Camel-mongo doesn't seem to exist either. It may be sufficient here to
address the MongoDB driver directly, since we probably do not necessarily
need the Camel-specific MongoDB API. The only thing missing is a suitable
OR mapper with OSGI support.
EndpointDSL
camel-endpointsdsl does not support OSGI. However, there is an alternative
to this, although I don't really like concatenating configuration
parameters in a string.
It's extremely frustrating right now having to figure all of this out
yourself. I just hope that one of you can explain to me that CDI still
works with Camel and Karaf.
WIth kind regards
Bert.
Am So., 4. Sept. 2022 um 15:42 Uhr schrieb Bert Speckels <
bert.speckels@gmail.com>:
> Hello there
>
> I'm a bit desperate at the moment: We're switching our Camel routes (in a
> monolith, Camel 3.14.2) to OSGI bundles (Apache Karaf and upgrade to Camel
> 3.18.1). Unfortunately I have some difficulties with this.
>
> For one thing, I'm missing a few Camel features: Unfortunately,
> "camel-endpointsdsl" doesn't exist as an OSGI feature/bundle, right?
> Neither 3.14.2 nmor 3.18.1 has OSGI support for that.
>
> Also missing in Camel 3.18.1 is the OSGI support of MongoDB, which still
> exists in 3.14.
>
> Also using CDI is quite confusing for me. Aries, Blueprint, Pax CDI,
> Camel-CDI... so many combinations... @Service, @OsgiServiceProvider,
> @Inject, @Reference... so many annotations, some of which are apparently
> deprecated. Currently we are using weld in our monolith: weld-se-shaded,
> deltaspike-cdictrl-weld with Camel-CDI.
>
> Overall, many (all?) tutorials and examples seem to be very outdated: I
> rarely find examples from 2020 or later. Apparently, even after 2020, so
> much has changed at Camel. Maybe you can point me to one or the other
> problem where I can get current information: OSGI-Mongo-Support, CDI,
> camel-endopointsdsl...
>
> With kind regards
> Bert Speckels
>
As a recipient of an email from Talend, your contact personal data will be on our systems. Please see our privacy notice. <https://www.talend.com/privacy/>
Re: Camel and OSGI support
Posted by Bert Speckels <be...@gmail.com>.
Hi Again
In fact, I'm extremely frustrated now. So excuse me if I sound a little
rude at this point. Actually I'm not like that. But not much remains of the
promising approach with Camel and Apache Karaf... similar to our first
approach with Quarkus.
So far I've only encountered obstacles trying to use the following in
Karaf.
CDI (most important)
camel-cdi apparently no longer exists as an OSGI bundle and pax-cdi alone
is not enough, because CDI (injection) is mainly used when building routes.
As far as I understand, this is only possible with Camel-CDI.
MongoDB
Camel-mongo doesn't seem to exist either. It may be sufficient here to
address the MongoDB driver directly, since we probably do not necessarily
need the Camel-specific MongoDB API. The only thing missing is a suitable
OR mapper with OSGI support.
EndpointDSL
camel-endpointsdsl does not support OSGI. However, there is an alternative
to this, although I don't really like concatenating configuration
parameters in a string.
It's extremely frustrating right now having to figure all of this out
yourself. I just hope that one of you can explain to me that CDI still
works with Camel and Karaf.
WIth kind regards
Bert.
Am So., 4. Sept. 2022 um 15:42 Uhr schrieb Bert Speckels <
bert.speckels@gmail.com>:
> Hello there
>
> I'm a bit desperate at the moment: We're switching our Camel routes (in a
> monolith, Camel 3.14.2) to OSGI bundles (Apache Karaf and upgrade to Camel
> 3.18.1). Unfortunately I have some difficulties with this.
>
> For one thing, I'm missing a few Camel features: Unfortunately,
> "camel-endpointsdsl" doesn't exist as an OSGI feature/bundle, right?
> Neither 3.14.2 nmor 3.18.1 has OSGI support for that.
>
> Also missing in Camel 3.18.1 is the OSGI support of MongoDB, which still
> exists in 3.14.
>
> Also using CDI is quite confusing for me. Aries, Blueprint, Pax CDI,
> Camel-CDI... so many combinations... @Service, @OsgiServiceProvider,
> @Inject, @Reference... so many annotations, some of which are apparently
> deprecated. Currently we are using weld in our monolith: weld-se-shaded,
> deltaspike-cdictrl-weld with Camel-CDI.
>
> Overall, many (all?) tutorials and examples seem to be very outdated: I
> rarely find examples from 2020 or later. Apparently, even after 2020, so
> much has changed at Camel. Maybe you can point me to one or the other
> problem where I can get current information: OSGI-Mongo-Support, CDI,
> camel-endopointsdsl...
>
> With kind regards
> Bert Speckels
>