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é <j...@nanthrax.net> 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

Reply via email to