It depends on how extensible you want to be … If you want to provide different implementations for the same type in different bundles then a solution is that each implementation bundle registers a service that acts as a factory. You design some service properties for the selection.
However, this sounds like overkill. What would the problem be to just export
the supplier package and let the user create the instance directly like in
classic Java? Why does it have to be a component?
Kind regards,
Peter Kriens
> On 27 aug. 2016, at 14:07, list+org.o...@io7m.com wrote:
>
> Hello.
>
> Years ago, I implemented a package of spatial data structures:
>
> https://io7m.github.io/jspatial/
>
> Recently, I've been bringing it up to modern standards and have
> restructured it to be somewhat more OSGi friendly. Nothing about the
> original package was exactly OSGi-hostile (no classloader tricks, etc),
> but the current version should ideally be better.
>
> Use of the package is very simple:
>
> QuadTreeConfigurationL config = ...
> QuadTreeLType<Integer> tree = QuadTreeL.create(config);
>
> tree.insert(0, area0);
> tree.insert(1, area1);
>
> ...
>
> SortedSet<QuadTreeRaycastResultL<Integer>> results = ...
> tree.raycast(ray, results);
>
> The obvious point where OSGi becomes involved is in the actual fetching
> of a concrete implementation of the QuadTreeLType. In the old package,
> there were four implementations, now there's only one.
>
> So, the approach I've taken is to define a supplier type:
>
>
> https://github.com/io7m/jspatial/blob/develop/io7m-jspatial-api/src/main/java/com/io7m/jspatial/api/quadtrees/QuadTreeSupplierLType.java
>
> Then, the implementation package provides an implementation:
>
>
> https://github.com/io7m/jspatial/blob/develop/io7m-jspatial-implementation/src/main/java/com/io7m/jspatial/implementation/QuadTreeSupplierL.java
>
> When used outside of an OSGi context, the user just instantiates
> and uses the QuadTreeSupplierL implementation directly.
>
> When used in an OSGi context, the intention is that someone will
> use DS to access to a value of this type (the implementation
> package doesn't export anything, but does obviously provide the
> above as a service component) and then use it construct trees on
> demand. The lifetime of trees in realtime simulations is typically
> very short: On every frame, a tree is populated, examined, and
> then discarded.
>
> Thing is... I'm now about to add another implementation of
> QuadTreeLType with different performance characteristics.
>
> If I provide another QuadTreeSupplierLType implementation in the
> same package and/or bundle, which one will "win" when DS attempts to
> instantiate a component as a dependency? Do I need to instead
> add the new implementation in a separate package?
>
> What's the right way to handle this?
>
> M
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
