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 <fpa...@apache.org> 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 >
