argr...@us.ibm.com>
>>
>>
>> ----- Original message -
>> From: Julian Sedding <jsedd...@gmail.com <mailto:jsedd...@gmail.com>>
>> Sent by: osgi-dev-boun...@mail.osgi.org
>> <mailto:osgi-dev-boun...@mail.osgi.org>
>> To: OSGi Develope
81>
> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> <(386)%20848-3788>
> hargr...@us.ibm.com
>
>
>
> - Original message -
> From: Julian Sedding <jsedd...@gmail.com>
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: OSGi Deve
// office: +1 386 848 1781
> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> hargr...@us.ibm.com
>
>
> - Original message -
> From: Julian Sedding <jsedd...@gmail.com>
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: OSGi Deve
...@us.ibm.com
- Original message -From: Julian Sedding <jsedd...@gmail.com>Sent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List <osgi-dev@mail.osgi.org>Cc:Subject: Re: [osgi-dev] Allow registering a (Prototype)ServiceFactory via DS?Date: Thu, Apr 20, 2017
Hi Tim
That's an interesting approach! I hadn't considered using DS but
handling the service registration myself.
To me it would have felt consistent if registering a ServiceFactory as
a service using DS had just worked. Next to controlling the scope
(singleton, bundle, prototype) of a service,
Yes, that would solve this issue.
Kind regards,
Peter Kriens
> On 20 Apr 2017, at 14:02, Tim Ward wrote:
>
> Peter - I assume that you mean that there will be no auto-generated
> osgi.service capability. Couldn't that be fixed with an additional annotation
>
Peter - I assume that you mean that there will be no auto-generated
osgi.service capability. Couldn't that be fixed with an additional annotation
on the component type to add the Provide-Capability to the manifest?
Tim Ward
Sent from my iPhone
> On 20 Apr 2017, at 12:38, Peter Kriens
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 wrote:
>
> DS isn’t intended to solve every single use
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)
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
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
11 matches
Mail list logo