Ok I understand, thanks.
Unfortunately, I cannot guarantee that my consumer Bundle C is only
used in installations that have all the other bundles installed yet,
due to backward compatibility reasons.
I will go for dynamic imports for now and once we drop support for the
older versions and support only those that have the necessary
bundles/packages installed, I will change it again.
Regards,
- Dirk
On Fri, 15 Oct 2021 at 10:47, Neil Bartlett <njbartl...@gmail.com> wrote:
>
> The implementation of the resolver will be different depending on the OSGi
> Framework implementation, so you're really getting into the weeds if you
> start relying on those internals.
>
> If one of your bundle's imports is optional, then by definition your bundle
> has to work when that import is not wired. The Framework is not required to
> give you a wiring for the import even if a compatible export appears to be
> available.
>
> I agree with Justin that services are the answer, but I disagree a little
> with the structure of his solution, there is no need for a shim. Here is
> what I would do:
>
> * Bundle A (for "API") exports both packages org.foo and org.bar. Both of
> these are pure APIs without implementation, so there is no cost to
> exporting both packages.
> * Either bundle A or another bundle (A') provides a service implementing
> the org.foo API, e.g. org.foo.Service.
> * Bundle B (for "Bonus"?) imports package org.bar and provides a service
> implementing the org.bar API, e.g. org.bar.BonusService.
> * Bundle C ("Consumer") imports both packages org.foo and org.bar. Neither
> of these are optional imports so they are always wired. C attempts to find
> a service instance implementing the BonusService, but if it doesn't find
> that then it can fall back to the inferioer org.foo.Service instance.
>
> This can be easily modelled as a Declarative Services component with one
> mandatory reference to org.foo.Service, and an optional+greedy reference to
> the org.bar.BonusService.
>
> Neil
>
>
>
>
>
> On Fri, 15 Oct 2021 at 08:40, Dirk Rudolph <d...@apache.org> wrote:
>
> > Thanks for the suggestion Justin.
> >
> > What if I cannot guarantee that the Shim API Bundle exists on all
> > installations, same as Bundle B? That would mean the org.shim import
> > in Bundle C is optional again.
> >
> > In fact I have a Bundle D already implementing both APIs from Bundle A
> > and B and registering the implementation as a service of both.
> >
> > Bundle A
> > interface org.foo.Service {}
> >
> > Bundle B
> > interface org.bar.ServiceExt extends org.foo.Service {}
> >
> > Bundle D
> > @Component(service = {org.foo.Service,org.bar.ServiceExt}) class
> > ServiceImpl implements ServiceExt {}
> >
> > So Bundle B always resolves, at least wired to Bundle A and so the
> > service from Bundle D is used with the org.foo API.
> >
> > If I understand the StatefulResolver correctly, it uses a ThreadPool
> > as executor for the ResolverImpl, meaning it may happen that bundles
> > do not alway get resolved in the same order. If so I would assume the
> > implementation should repeat the resolution once a bundle fulfilling
> > an optional requirement gets resolved (greedy behaviour). Is that the
> > case? I haven't found anything about that in the specs.
> >
> > Regards,
> > Dirk
> >
> >
> >
> >
> >
> >
> > On Fri, 15 Oct 2021 at 00:09, Justin Edelson <jus...@justinedelson.com>
> > wrote:
> > >
> > > Hi Dirk,
> > > This is a possibly impractical suggestion in your context, but have you
> > > thought about modeling this as services? Something like:
> > >
> > > Bundle A (ID: 200)
> > > - Export-Package: org.foo;version=1.0.0
> > >
> > > Bundle B (ID: 210)
> > > - Import-Package: org.foo;version="[1.0,2)"
> > > - Export-Package: org.bar;version=1.0.0
> > >
> > > Shim API Bundle:
> > > - Export-Package: org.shim;version=1.0.0
> > >
> > > Shim for Bundle A Bundle
> > > - Import-Package: org.shim;version="[1.0.0,2)",org.foo;version="[1.0,2)"
> > >
> > > Shim for Bundle B Bundle
> > > - Import-Package: org.shim;version="[1.0.0,2)",org.bar;version="[1.0,2)"
> > >
> > > Bundle C
> > > - Import-Package: org.shim;version="[1.0.0,2)"
> > >
> > > The Shim API bundle exports a service interface that is implemented in
> > both
> > > "Shim for Bundle A Bundle" and "Shim for Bundle B Bundle" (backed by the
> > > corresponding org.foo or org.bar API). The service in "Shim for Bundle B
> > > Bundle" has a higher service ranking. The service reference in Bundle C
> > > would (assuming it was properly set up) get one or the other.
> > >
> > > Regards,
> > > Justin
> > >
> > > On Thu, Oct 14, 2021 at 1:40 PM Dirk Rudolph <d...@apache.org> wrote:
> > >
> > > > Hi,
> > > >
> > > > tldr; is the order in which bundles get resolved predictable?
> > > >
> > > > We are facing issues with the usage of optional imports. Sometimes an
> > > > optionally imported package gets wired and sometimes it doesn't.
> > > > Refreshing the consuming bundle's package imports after startup always
> > > > works to get the wiring done right.
> > > >
> > > > Consider the following bundles:
> > > >
> > > > Bundle A (ID: 200)
> > > > - Export-Package: org.foo;version=1.0.0
> > > >
> > > > Bundle B (ID: 210)
> > > > - Import-Package: org.foo;version="[1.0,2)"
> > > > - Export-Package: org.bar;version=1.0.0
> > > >
> > > > Bundle C (ID: 500)
> > > > - Import-Package:
> > > >
> > org.foo;version="[1.0,2)",org.bar;version="[1.0,2)";resolution:=optional
> > > >
> > > > All bundles have the same startlevel (20), in case it matters (?).
> > > >
> > > > Our use-case is that Bundle C used to use an API provided by Bundle A,
> > > > which got improved and extended into a new API provided by Bundle B.
> > > > Not all installations provide Bundle B, but all provide Bundle A.
> > > > Bundle C now prefers the optionally available API of Bundle B but
> > > > falls back to the API provided by Bundle A if Bundle B is not
> > > > available.
> > > >
> > > > I think the usage of optional imports is reasonable here, or are there
> > > > alternatives besides using dynamic imports?
> > > >
> > > > Thanks,
> > > >
> > > > - Dirk
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > > > For additional commands, e-mail: users-h...@felix.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > For additional commands, e-mail: users-h...@felix.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
