But then you loose the DS dependency management on Foo … Since your
FooServiceFactory no longer promises to provide a Foo service :-(
Kind regards,
Peter Kriens
> On 20 Apr 2017, at 12:35, Timothy Ward <tim.w...@paremus.com> wrote:
>
> DS isn’t intended to solve every single use case, rather to make common use
> cases simple to write and understand. In this case what you want is more
> advanced, and unlikely to make it into DS as a natively supported pattern.
> Given that you’re already tied to the core OSGi API (ServiceFactory) then
> registering the service programatically would still let DS help you with
> config and service injection.
>
>
> @Component(
> // Do not let DS provide the service
> service = {},
> configurationPolicy = ConfigurationPolicy.REQUIRE
> )
> public class FooServiceFactory implements ServiceFactory<Foo> {
>
> @Reference // provides FooBuilder instances that are pre-configured via OSGi
> private FooBuilderFactory fooBuilderFactory;
>
> private ServiceRegistration<?> reg;
>
> @Activate
> void start(BundleContext ctx, Map<String, Object> props, Config config) {
> reg = ctx.registerService(Foo.class.getName(), this, props);
> }
>
> @Deactivate
> void stop() {
> reg.unregister();
> }
>
> @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
>
> }
>
>
> Regards,
>
> Tim
>
>
>> On 20 Apr 2017, at 11:11, Julian Sedding <jsedd...@gmail.com> wrote:
>>
>> Hi Timothy
>>
>> Thanks for your reply. Using delegation works, I currently use it to
>> solve my use-case.
>>
>> However, compared to implementing a ServiceFactory, delegation adds
>> some overhead:
>>
>> - delegation needs to be implemented, which is trivial, but noisy if
>> there are lots of methods that need delegating
>> - by delegating, my implementation becomes a "provider" of Foo, rather
>> than a "consumer", making my bundle more susceptible to changes in
>> Foo's API
>> - also: delegation is not possible if Foo is a final class
>>
>> I brought up this topic in order to (a) confirm that my desired
>> approach is indeed not possible at the moment and (b) to see if adding
>> support for registering custom ServiceFactory implementations via DS
>> could be a desirable enhancement for the spec.
>>
>> Regards
>> Julian
>>
>>
>> On Thu, Apr 20, 2017 at 11:22 AM, Timothy Ward <tim.w...@paremus.com> wrote:
>>> 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
>> _______________________________________________
>> 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
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
