I ack your point (even if I don't necessarily agree regarding my experience with AMQ/Karaf/OSGi :)), and we have a consensus. As I said, I will continue the current approach with the required upgrades.
Regards JB On Tue, Sep 12, 2023 at 11:01 AM Christoph Läubrich <m...@laeubi-soft.de> wrote: > > > I agree with the overhead but is it really an issue > > Of course it is an issue (depending on how much you embedd), at least it > vast disk, cpu, ram and network resources > > > AMQ broker is a black box in Karaf/OSGi > > So no configuration? No plugins? No management possible? Client only > ever use plain JMS standard API? > > > nobody is doing Spring update or Jetty update in ActiveMQ without > > upgrading the whole ActiveMQ > > Not in ActiveMQ but in OSGi... so if you require Spring version 9.3 or > later and Spring releases 9.3.1 I can upgrade the Spring bundles and I'm > done, with uber-jar/bundle/war/... I need to ask for a new ActiveMQ > release and then get additional delay even if it would be released fast... > > > The big advantage is to avoid OSGi coupling at build time > > for developers > > Why should a developer ever be "coupled" to OSGi at build time and why > should this change that there is one or multiple bundles? And even for > ActiveMQ build itself you can always just generate the OSGi metadata > separately and don't need to think about OSGi at all. > > As Karaf can even wrap bundles dynamically you even don't need OSGi > metadata at all for third party libs you depend on. > > > Am 12.09.23 um 07:53 schrieb Jean-Baptiste Onofré: > > About your points: > > - I agree with the overhead but is it really an issue ? Having an > > atomic bundle is not a bad thing imho > > - that's why I said "most of" import packages and today, AMQ broker is > > a black box in Karaf/OSGi, so I don't see a difference here > > - nobody is doing Spring update or Jetty update in ActiveMQ without > > upgrading the whole ActiveMQ, and actually I think it's a good thing > > as it's more predictable > > - I'm not sure projects actually really try and it really depends of > > the use case. Definitely for a library it's not a good approach, but > > for "middleware" like AMQ it works fine. I experimented with the same > > approach for Camel components and it works just fine. The big > > advantage is to avoid OSGi coupling at build time for developers (else > > the consequence will be that OSGi will be just removed from the > > project like in Camel 4). > > > > Just background: today, ActiveMQ 5.19.x (or 6.x :)) requires updates > > that are not yet available in OSGi/Karaf (Spring 6, Jetty 11, jakarta, > > ..., even if I rushed to provide the SMX bundles required for that, > > but it also needs JDK17+). So, as I want to release this new major AMQ > > version soon, I have to find a more sustainable approach (to avoid 5+ > > external releases just for OSGi). > > > > Regards > > JB > > > > On Tue, Sep 12, 2023 at 6:26 AM Christoph Läubrich <m...@laeubi-soft.de> > > wrote: > >> > >> > I disagree > >> > >> on what particular point? > >> > >> > I don't understand why people are against uber bundle. > >> > >> Because it has many bad properties: > >> > >> - You duplicate the code in your bundle, especially for large frameworks > >> like spring this can be a major overhead, if someone else is using that > >> framework it will be loaded effectively twice (or three time or four if > >> other follow your example) > >> > >> - You will expose your code to subtile class space problem, how will you > >> test/ensure that none of the "private" dependencies will ever leak to > >> the outside if you still want to allow collaboration? > >> > >> - Every update to a dependency will require a full ActiveMQ release as > >> it is no longer possible to upgrade the dependency independently > >> > >> - I don't know any project that followed this path with success, > >> felix-http even has dropped now their support for embedded jetty (what > >> is one of the rare case where this could work quite well). > >> > >> > >> Am 12.09.23 um 06:15 schrieb Jean-Baptiste Onofré: > >>> Hi, > >>> > >>> I disagree, I don't understand why people are against uber bundle. The > >>> export packages stay the same, so ActiveMQ can still "collaborate" > >>> with other bundles. Most of import (not all) will go private, not > >>> necessary all (I'm on a PoC right now). > >>> > >>> Regards > >>> JB > >>> > >>> On Tue, Sep 12, 2023 at 5:48 AM Christoph Läubrich <m...@laeubi-soft.de> > >>> wrote: > >>>> > >>>> Making "uberbundles" is really bad not only for file-size, OSGi was made > >>>> with sharing in mind and embedding "everything" will make this > >>>> impossible if you not at the same time rexport the packages what has > >>>> other implications. > >>>> > >>>> Also keep in mind that he activemq could not participate in any other > >>>> things so it never should expose any object from "inside" to the user > >>>> code, also if you now has a refresh you replace these (local) refreshes > >>>> with one big classloader that looses all its state at once, not sure if > >>>> this is better here. > >>>> > >>>> If you want to avoid such issues it is generally better to reduce the > >>>> dependency count, e.g. check if this SMX bundles are really required or > >>>> if they are just used for historic reasons (e.g many things today can be > >>>> replaced by standard java features). > >>>> > >>>> Regarding coupling "OSGi with Karaf" I know for sure some projects using > >>>> activemq without karaf, so this is again just a convenience thing, it is > >>>> easier to use with a karaf feature, but if you have other deployment > >>>> targets why not check what they use and make it convenient there as well? > >>>> > >>>> Am 11.09.23 um 14:07 schrieb Jean-Baptiste Onofré: > >>>>> Hi all, > >>>>> > >>>>> As you know, ActiveMQ 5.19.x is in preparation with importants > >>>>> changes: JMS 2, Jakarta namespace, Spring 6, ... > >>>>> > >>>>> For ActiveMQ 5.19.x, I propose to change the OSGi packaging (client > >>>>> and broker). Today we have OSGi bundles for client and broker, with > >>>>> Karaf features installing all dependent features/bundles (spring, > >>>>> commons-*, etc). > >>>>> This approach has few issues: > >>>>> - any update requires SMX bundles or Karaf features, coupling ActiveMQ > >>>>> OSGi with Karaf (jetty, spring, ...) > >>>>> - it's very hard to install ActiveMQ OSGi without Karaf > >>>>> - we can have some side effects depending of what's installed in the > >>>>> Karaf runtime (we already had refresh issues in the past, amd > >>>>> cascading refresh) > >>>>> > >>>>> My proposal is to use a new uber bundle approach for ActiveMQ OSGi > >>>>> client and broker. The idea is to provide OSGi bundles that > >>>>> self-contains everything needed to use/run ActiveMQ. The export > >>>>> packages are the same, but the import packages will be very minimal, > >>>>> most the packages will go private. > >>>>> The advantage is that ActiveMQ OSGi doesn't depend on anything at > >>>>> runtime, it's just a single bundle to install (one bundle for client, > >>>>> one bundle for broker), no extra dependency (so not release > >>>>> dependencies like ServiceMix Bundles or Karaf features), dedicated > >>>>> classloader avoiding refreshes, etc. > >>>>> The only drawbacks are the size of the ActiveMQ client & broker > >>>>> bundles (as they ship other packages, is it really a big deal ?) and > >>>>> the fact that ActiveMQ won't share packages with other bundles (I'm > >>>>> thinking about Spring bundles for instance). > >>>>> It's basically using something similar to the apache-activemq > >>>>> distribution but in OSGi/Karaf. > >>>>> > >>>>> Thoughts ? > >>>>> > >>>>> Regards > >>>>> JB
