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 <[email protected]> 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
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
