Have you not considered the following:
@Component(configurationPolicy = ConfigurationPolicy.REQUIRE, scope = ServiceScope.BUNDLE) public class FooImpl implements Foo { public @interface Config { // Config definition in here } @Reference private FooBuilderFactory fooBuilderFactory; private Foo delegate; @Activate void start(Config config) { FooBuilder fooBuilder = fooBuilderFactory.builder(); applyConfiguration(fooBuilder, config); delegate = fooBuilder.build(); } // Deactivation and Foo delegation methods go here … } Regards, Tim > On 20 Apr 2017, at 09:30, Julian Sedding <jsedd...@gmail.com> wrote: > > Hi there > > I have been trying to implement a use-case, but I seem to be running > into walls ;) (Disclaimer: I can see multiple ways to implement this, > but would like to re-use the dependency injection and lazy > instantiation of DS). > > My aim is to create configured service objects in the way that is > normally achieved by using a DS factory component with > configuration-policy require. > > The catch is that the implementation of the objects I want to > configure and register as a service is not under my control and is > instanciated via a builder obtained from a factory that is registered > as an OSGi-service. Sounds a bit complicated, maybe it's clearer in > code. > > @Component( > service = Foo.class, > configurationPolicy = ConfigurationPolicy.REQUIRE > ) > public class FooServiceFactory implements ServiceFactory<Foo> { > > @Reference // provides FooBuilder instances that are pre-configured via > OSGi > private FooBuilderFactory fooBuilderFactory; > > @Override > public Foo getService() { > FooBuilder fooBuilder = fooBuilderFactory.builder(); > applyConfiguration(fooBuilder); > return fooBuilder.build(); > } > > private void applyConfiguration(FooBuilder fooBuilder) { > // apply OSGi configuration to FooBuilder object > } > > ... // ungetService omitted for brevity > > } > > As far as I understand, this is not currently possible. The bnd tool > shouts at the mismatch between the "service" attribute (Foo.class) and > the ServiceFactory interface and refuses to generate the SCR XML. With > a manually crafted XML, Apache Felix SCR ends up throwing exceptions. > And most likely both implementations are correct, as I could not find > anything supporting my use-case in the spec. > > Can anyone on this list please confirm that this is not (currently) possible? > > I think this use-case is relatively generic. It has two preconditions: > > - the implementation of the service object (e.g. Foo) is out of my > control and can therefore not be enhanced with OSGi-specifics > - in order to be able to create the service object, dependencies on > other services are required > > Does this sound like a possible addition to the Declarative Services > specification? > > Regards > Julian > > PS: For those curious on how this could be implemented today. One way > to implement this is to register the ServiceFactory (lazily) by hand. > Provided Foo is not a final class, another way is to create a wrapper > for Foo that delegates all calls to a "real" Foo instance. The > FooWrapper implementation is then under my control and can be enhanced > with DS annotations etc. > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev