Just to be clear: I will keep the current approach upgrading to spring 6 etc. In the meantime, I will work on SMX/Karaf requirements for ActiveMQ.
Regards JB Le mar. 12 sept. 2023 à 10:51, Jean-Baptiste Onofré <j...@nanthrax.net> a écrit : > 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 >> >
