activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: [DISCUSS] OSGi support for Artemis
Date Tue, 17 Nov 2015 12:06:05 GMT
2015-11-17 12:31 GMT+01:00 Christian Schneider <>:

> I think ordinary bundles will not work well regarding the mechanisms to
> e.g. find protoccols.
> Currently these assume all modules to be in the same classpath. So if you
> put them into individual bundles they probably will not work out of the box.
> Maybe we can solve this using the Aries spi-fly as it seems the
> Resourelocator mechanism is used. Not sure though.
> So an ueber jar would fix that problem. On the other hand I am not sure if
> we really would want to put all modules into it.
> So I would rather like to first check how far we can get with a real
> modularization.

As I said, my proposal of the uber-jar is just meant to be a short term
The locator pattern is not really ideal in OSGi either, the best way is
definitely to use OSGi services,
but it mainly depends how far we would want to go with modularisation.
We could decide to make protocols available in the OSGi registry and even
support them being changed on the fly why not impacting other protocols,
but this may be problematic with how the core is written (not sure that can
easily be supported, and that would also affect the configuration of those
If we don't go that way, using a locator pattern is good enough and we
should be able to easily tweak the code to support OSGi.

> Christian
> On 17.11.2015 12:02, Raul Kripalani wrote:
>> Thanks for your input Guillaume. I had understood that you didn't
>> generally
>> consider OSGi fragments fit for any purpose.
>> If the goal is to make Artemis a nice OSGi citizen, I agree with you that
>> proper modularisation with whiteboard pattern and OSGi services should be
>> the correct path.
>> If the goal was to make Artemis simply "work" in OSGi, I don't think an
>> uber jar is the optimal solution. Why? Even though I haven't dug into the
>> source, I'm pretty sure that not *all* modules present a split-package
>> situation. Therefore, building an uber-jar is killing flies with a bazooka
>> in my opinion, since you'll be forcing the user to drag in ALL optional
>> third party dependencies, whether they'll be using them or not.
>> That's why I think fragments are the right approach. You'd apply a
>> mix'n'match policy, where modules that present a split-package situation
>> would become fragments, whereas the rest would become normal bundles.
> --
> Christian Schneider
> Open Source Architect

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message