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
