Hello Maybe not very constructive, but I have to add my 2¢...
wt., 19 wrz 2023 o 05:16 John Taylor <[email protected]> napisał(a): > Hi JB, > > >> . If we have clear signs that people are interested in colocation and > Minho runtime paradigm, it could change :) > This probably isn't exactly what you're referring to, but I'll express > interest as I'm concerned that I won't be able to do things like I have > preferred to and Minho might(?) somehow be a solution. My preference has > been to run all my Camel routes in the Karaf OSGi runtime and not have to > go the multiple spring boot/whatever apps for each context. It's not a > sophisticated setup for sure, but it looks like Camel on OSGi support was > dropped entirely in Camel 4 (components are no longer built with OSGi) so I > won't be able to keep doing that as simply. > You touched very important aspect of OSGi here. I work with OSGi for almost 10 years now and I joined this technology almost at the end of its popularity. You know what happened next - Kubernetes, which made Dockerfile based "application" the golden hammer. Spring Boot (IMO) is better suited to be used as flat-classpath application framework with lots of functionality that makes writing typical applications easier. On the other hand, OSGi is very well designed paradigm based on a network (not hierarchy) of classloaders. And it's OSGi's biggest value and biggest curse to be honest. While I worked on OSGi on "the provider side", I almost never used OSGi as application developer (I was working on frameworks, not applications that work on those frameworks). And yes - you can have multiple Camel contexts, each within its own bundle processed by blueprint extender. Perfectly isolated, tied using OSGi services or Camel routes. With OSGi you can install 3 versions of Jackson libraries and 13 versions of Guava (trust me - I've been there). And this is biggest OSGi problem - not only the "bundles" from Maven central have OSGi manifests because of some ancient contributions, it really requires a lot of discipline to "integrate" complex applications within OSGi - despite its great design. Camel is great example - there are hundreds of components, lots of them are external contributions added to Camel and accepted by PMCs. Some of these components were never maintained since then and were stuck with, say, Guava 13. This made this component using `Import-Package: com.google.common.base; version="[13.0,14)"` - see the problem? It CAN'T work with Guava 14. I believe (but that's my opinion) Camel 4 dropped OSGi support just because of this issue. And also moving from javax to jakarta, where OSGi still lags behind this transition... Kubernetes made most of us think in terms of µservices. But not every problem/system requirement can be solved using this "architecture"... That's just random thought... regards Grzegorz Grzybek > > Sorry, probably out in left field for the discussion. :) > > -John >
