[osgi-dev] Allow registering a (Prototype)ServiceFactory via DS?

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 no

Re: [osgi-dev] Allow registering a (Prototype)ServiceFactory via DS?

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 fooBuilder

Re: [osgi-dev] Allow registering a (Prototype)ServiceFactory via DS?

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 delegatin

Re: [osgi-dev] Allow registering a (Prototype)ServiceFactory via DS?

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) the

Re: [osgi-dev] Log Service Specification Version 1.4 doubt

If you read the proposed spec, they won't tie to SLF4J. OSGi will have an own set of classes (as already they have) with methods and factories *based* on the style existent in SLF4J and will not use slf4j-api. The https://github.com/osgi/slf4j-osgi is aimed

Re: [osgi-dev] Allow registering a (Prototype)ServiceFactory via DS?

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 case, rather to make common

Re: [osgi-dev] Allow registering a (Prototype)ServiceFactory via DS?

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 wrote: >

Re: [osgi-dev] Log Service Specification Version 1.4 doubt

So to fight the multiple logging frameworks problem we add another one I understand, that the logging initialization with a static factory is a bad pattern in OSGi ... but as we have so much code out there that already uses this I think we could as well just leave the situation like it is

Re: [osgi-dev] Allow registering a (Prototype)ServiceFactory via DS?

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 > on the component type to

Re: [osgi-dev] Log Service Specification Version 1.4 doubt

Logging in java always reminds me of this comic strip: https://xkcd.com/927/ Christian On 20.04.2017 14:03, Christian Schneider wrote: So to fight the multiple logging frameworks problem we add another one I understand, that the logging initialization with a static factory is a bad patt

Re: [osgi-dev] Allow registering a (Prototype)ServiceFactory via DS?

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,

Re: [osgi-dev] Allow registering a (Prototype)ServiceFactory via DS?

When DS registers your component as a service, it already registers its own object implementing ServiceFactory. This is necessary to register the service while still allowing delayed activation of your component. So DS's ServiceFactory object is called by the framework when someone gets the service

Re: [osgi-dev] Log Service Specification Version 1.4 doubt

Based on way too much trench work in the initialization of log4j, I'd say the easiest way to ensure custom initialization is to set up before you do any logging. In complicated scenarios, you can always reconfigure after the fact. Spring Boot, for example, sets up a filter to ignore all log message

[osgi-dev] Capability Annotation questions/issues (was Re: Allow registering...

On Apr 20, 2017 8:04 AM, "Peter Kriens" wrote: > 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 on the component type to add the Provide-Capability to