activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: [DISCUSS] OSGi support for Artemis
Date Tue, 17 Nov 2015 09:09:12 GMT
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