Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x
Hey JB- I’m not sure I agree about changing them. Current approach allows for ‘optional’ feautres. A couple things that this could impact: 1. Plugin extensions using xbean namespaces 2. The activemq-http component and other ’optional’ add-ons. 3. Other optional features— client-side blob transfer, zeroconf discovery, etc. Right now, the activemq-http requires add’l optional jars for client and server. Would the uber bundle include apache-http-client and other jars that are currently ‘optional’? Things like ‘xstream’ and Jackson can be problematic, as things with unmarshalling frequently have security issues. Today, we don’t have to install those so we dodge that security surface area altogether. Thanks, Matt Pavlovich > On Sep 11, 2023, at 7:07 AM, Jean-Baptiste Onofré wrote: > > 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
Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x
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 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 > > 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 > >>> 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
Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x
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é 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 > 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 >> 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.
Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x
> 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 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 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
Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x
Ok fair enough. I will update the features and OSGi bundles accordingly. Regards JB Le mar. 12 sept. 2023 à 10:41, Robbie Gemmell 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 > 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. > >
Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x
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 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 > > 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. > >>> > >>>
Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x
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 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 > > 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
Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x
> 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 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
Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x
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 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
Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x
Hi We already have shell commands to deal with the broker: we will still have it, it doesn't change there. Good comment about Spring, however, imho, it's not OSGi specific: we would need to replace Spring with something else in ActiveMQ iitself. Regards JB On Mon, Sep 11, 2023 at 11:27 PM fpapon wrote: > > Hi JB, > > Sounds good to me. > > Just some side questions: > > - You're talking about having an embedded broker in Karaf so does it > mean that we can also have some Karaf command to control the broker? > (like we can have with Camel) > > - About the client, should we will need to use Pax-JMS or not? If not, > users will use it by reference with an OSGi generic service through the > service registry? > > - If all import package will be private, that is a good thing (big > bundle size but not a big deal), is there a plan to remove Spring > framework dependencies and use another lighter IoC framework or be more > low level with the JDK17 and soon JDK21 for example? > > Thanks for your great job on ActiveMQ! > > regards, > > François > > On 11/09/2023 14:07, Jean-Baptiste Onofré wrote: > > 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 > > -- > -- > François >
Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x
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
Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x
Hi JB, Sounds good to me. Just some side questions: - You're talking about having an embedded broker in Karaf so does it mean that we can also have some Karaf command to control the broker? (like we can have with Camel) - About the client, should we will need to use Pax-JMS or not? If not, users will use it by reference with an OSGi generic service through the service registry? - If all import package will be private, that is a good thing (big bundle size but not a big deal), is there a plan to remove Spring framework dependencies and use another lighter IoC framework or be more low level with the JDK17 and soon JDK21 for example? Thanks for your great job on ActiveMQ! regards, François On 11/09/2023 14:07, Jean-Baptiste Onofré wrote: 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 -- -- François
Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x
I don't really know too much about how the Osgi stuff works so I will defer to you and others who use it in terms of what is best so this sounds ok to me if it is needed. On Mon, Sep 11, 2023 at 8:08 AM Jean-Baptiste Onofré wrote: > 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 >
