activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: [DISCUSS] OSGi support for Artemis
Date Tue, 17 Nov 2015 11:31:26 GMT
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 


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

View raw message