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/>* > > > > > > >
