Ok fair enough. I will update the features and OSGi bundles accordingly.
Regards JB Le mar. 12 sept. 2023 à 10:41, Robbie Gemmell <robbie.gemm...@gmail.com> a écrit : > 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 >
