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

Reply via email to