I'm really glad someone already noted the various disadvantages of uber jars that I thought of when reading the original email. Saved me some typing.
I'd only expand upon the "Every update to a dependency will require a full ActiveMQ release" point to more directly call it out as being a security concern as well. You can't as easily establish what potentially vulnerable bits are being used in an uberjar, and even if you know everything in there you then still need the whole thing released. On Tue, 12 Sept 2023 at 05:26, 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
