> 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 <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
