activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raul Kripalani <ra...@apache.org>
Subject Re: [DISCUSS] OSGi support for Artemis
Date Tue, 17 Nov 2015 11:02:59 GMT
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.

I appreciate this discussion with you, master!

Regards,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

On Tue, Nov 17, 2015 at 9:09 AM, Guillaume Nodet <gnodet@apache.org> wrote:

> 2015-11-17 1:52 GMT+01:00 Raul Kripalani <raul@evosent.com>:
>
> > Hi Guillaume,
> >
> > Out of curiosity, why do you think OSGi fragments are not a good solution
> > in general?
> >
>
> The original primary use case for fragments is to extend a given bundle.
> Using it as a workaround for proper modularisation is too much imho.
> A cleaner way to extend a given bundle's functionality is to use OSGi
> services which allow for more dynamism in OSGi.
> Installing a fragment will cause bundles to be refreshed
>
>
> >
> > As for everything, they have their use case, right? Or is there a reason
> to
> > avoid them altogether, beyond one's liking or disliking of the technique?
> >
>
> There are valid use cases for using fragments, but again, I don't think
> using those as a workaround for proper modularisation is one of them (even
> though it works and certainly has been used this way, especially when you
> don't have real control over the code you want to deploy in OSGi).
>
> In the Artemis use case, the best way is definitely to refactor the code as
> needed so that it becomes a nice OSGi citizen.  As a short term solution
> (especially if there are some incompatibilities that need to be pushed to a
> major version for example), the simplest way imho is to use an
> uber-bundle.  The benefits is that all the OSGi stuff is concentrated into
> a single maven module, and the amount of work is much less.  The only small
> disadvantage compared to fragments would be that a bunch of import package
> need to be optional, whereas with fragments, those could be mandatory for a
> given fragment.  But at the end, both are similar as you can't really force
> an unresolvable fragment to cause a failure, so that in both case, if
> something is missing, there will be a runtime exception such as
> ClassNotFoundException.
>
>
> >
> > Thanks,
> > Raúl.
> > On 16 Nov 2015 15:18, "Guillaume Nodet" <gnodet@apache.org> wrote:
> >
> > > I really don't see the point of using fragments.  Fragments are not a
> > good
> > > OSGi solution in general.
> > > The easiest way forward (even instead of using fragments) would be to
> use
> > > an uber-jar imho.
> > > At least, it has the benefit of limiting the code changes and locating
> > all
> > > the OSGi stuff in a single module.
> > >
> > > 2015-11-16 11:48 GMT+01:00 Raul Kripalani <raul@evosent.com>:
> > >
> > > > Once again, I do suggest you explore the OSGi Fragment route.
> > > >
> > > > I haven't digged into the Artemis source, but if your modularity
> scheme
> > > > consists of modules that provide classes and resources to a central
> > one,
> > > it
> > > > could fit well.
> > > >
> > > > This is the strategy I'm using with certain modules to OSGify Apache
> > > > Ignite.
> > > >
> > > > It also resolves the split package situation quite elegantly without
> > > being
> > > > a workaround (depending on the rationale of the split packages to
> begin
> > > > with).
> > > > On 16 Nov 2015 03:15, "artnaseef" <art@artnaseef.com> wrote:
> > > >
> > > > > How much work are we talking to get Artemis properly OSGi-ready?
> An
> > > > > uber-jar
> > > > > is a work-around.  If nothing better can be accomplished, then we
> may
> > > > have
> > > > > to live with it in the near-term, but it is important to understand
> > > what
> > > > > challenges are driving us toward a work-around.
> > > > >
> > > > > Also, we have an individual showing interest to make this happen,
> so
> > > > let's
> > > > > encourage that effort!  Thank you Guillaume.
> > > > >
> > > > > I may be a bit tainted as these days I'm spending large amounts of
> > time
> > > > > refactoring code and eliminating the impacts of work-arounds and
> > > > shortcuts.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > View this message in context:
> > > > >
> > > >
> > >
> >
> http://activemq.2283324.n4.nabble.com/DISCUSS-OSGi-support-for-Artemis-tp4703943p4703972.html
> > > > > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
> > > > >
> > > >
> > >
> >
>

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