> 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 <georgedasw...@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 <bert.speck...@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 < >> raymondmees...@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 <bert.speck...@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 <nfilo...@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 <bert.speck...@gmail.com> >> >> > *Sent:* Monday, September 5, 2022 12:44 >> >> > *To:* users@camel.apache.org <users@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.speck...@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/>* >> >> > >> >> > >> >> > >> >> >> > >> >
