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
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
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
> 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
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
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
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
> 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
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
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
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
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,
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
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
14 matches
Mail list logo