Re: [osgi-dev] SCR: ServiceInjection into Fields that are Optional

Thanks BJ, this is great to hear. With reference to copying the volatile field into a local variable, this is unnecessary if the programmer makes proper use of the Optional type. For example: foo.ifPresent(Foo::doSomething); or: List bars = foo.stream() .flatMap(f ->

Re: [osgi-dev] SCR: ServiceInjection into Fields that are Optional

I like Stefan's suggestion and I disagree with some specific points made by Mark... responses line below. On Wed, 23 Sep 2020 at 05:35, Mark Hoffmann via osgi-dev < osgi-dev@mail.osgi.org> wrote: > Hi Stefan, > > I believe Optionals are not optimal for that. > > If a service is removed, you

Re: [osgi-dev] Library development

Along the lines of Bernd's answer, here is what I do: 1. Use declarative services. 2. For injection of service references, prefer constructor injection. 3. The component implementation should be in a private package. However, non-OSGi consumers don't know anything about exported versus private

Re: [osgi-dev] Parent Class Loader Bootdelegation

It looks like you have answered this yourself: "framework" delegates to the classloader that loaded the system bundle, i.e. the OSGi Framework. Bear in mind that that classloader would normally perform parent delegation up the chain, unless you have implemented alternative custom behaviour in any

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

I'm also extremely confused by your setup! But if you can get things working using Tycho and the org.eclipse.osgi then I guess that will have to do. My understanding was that Tycho didn't even look at the Maven dependencies specified in the POM using a section, and also it does not distinguish

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

On Fri, 3 Jan 2020 at 13:08, Martin Petzold via osgi-dev < osgi-dev@mail.osgi.org> wrote: > Okay, thanks. This is clear now. > > However, Ray told me to set the dependency for "org.eclipse.osgi" to > "runtime" scope. But how can my implementation then depend on > "org.osgi.framework" package

Re: [osgi-dev] Micro version ignored when resolving, rationale?

> So having default settings in the tool that cause a behavior that does not comply with the specification should not be considered a bug? Which specification?? There is NO specification in OSGi for how a packaging tool such as bnd should generate bundles from Java classes and descriptors. The

Re: [osgi-dev] Micro version ignored when resolving, rationale?

"the specification, which states that the micro part of the version should be ignored when resolving bundles" The OSGi specification absolutely does NOT state this. Mainly for the reasons you have laid out yourself. Regards, Neil. On Mon, 17 Jun 2019 at 23:14, Michael Lipp via osgi-dev <

Re: [osgi-dev] Migrating from OSGI to Microservices

Well the good news is that OSGi is already a microservice architecture, so you have already finished. Congratulations! If that answer doesn't quite satisfy you, maybe you'd like to describe in more detail what you are attempting to achieve and why? Regards, Neil On Thu, 2 May 2019 at 11:06,

Re: [osgi-dev] Obtain a bundle's "state change" lock

On Fri, 1 Mar 2019 at 14:28, Michael Lipp wrote: > > Have you tried using a BundleTracker? > > It doesn't give you internal access to the Framework's locks... nothing > does I believe (and hope!). > > In a way, it does. BundleTracker.Tracked implements > SynchronousBundleListener. An instance of

Re: [osgi-dev] Obtain a bundle's "state change" lock

Have you tried using a BundleTracker? It doesn't give you internal access to the Framework's locks... nothing does I believe (and hope!). It does however handle the complexity of getting current state and listening at the same time. When you open the tracker, the addingBundle() method (which you

Re: [osgi-dev] Clarification on reference behavior regarding field injection

On Mon, Feb 18, 2019 at 9:39 AM Thomas Driessen via osgi-dev < osgi-dev@mail.osgi.org> wrote: > Hi Tim, > > as always thanks for your super detailed answer! > > Just two more questions on this topic: > > 1) Out of curiosity: do you know why the decision was made to make the > default for

Re: [osgi-dev] bundle symbolic name

Remember that "groupId" and "artifactId" are Maven concepts. Not all software is built with Maven and therefore not every OSGi bundle has a groupId and artifactId. Nevertheless, OSGi requires all bundles to have some kind of identity. This is what Bundle-SymbolicName give us. Neil On Wed, Nov

Re: [osgi-dev] Service component resolution time

Two quick points: 1. The Felix ResolverImpl is responsible for resolving bundle constaints (imports and requires). It has absolutely nothing to do with SCR, so it doesn't matter how many components you have. 2. Are you building an Eclipse RCP application? If so, check whether the

Re: [osgi-dev] Double config

On Sun, Aug 26, 2018 at 1:35 AM David Leangen via osgi-dev < osgi-dev@mail.osgi.org> wrote: > > Hi, > > Thank you again for all the great tips in this thread. I have taken the > time to review concurrency, reread all the blogs, articles, and email > messages in detail, and I have done a fairly

Re: [osgi-dev] Double config

With regard to "testing bouncing", there are two sides to this question: the component being bounced, and the other components that may be exposed to it bouncing. The component itself should never actually know that it is being, or has been, bounced. SCR always creates a new instance for each

Re: [osgi-dev] Extending Services

Are these DS components? I'm not entirely sure what would happen if a component both provides a service and binds to the same service type. In theory it might be able to bind to itself, especially if it is a lazy (delayed) service component, because then the service registration exists before the

Re: [osgi-dev] Service Composition

There is nothing actually wrong with your code, but let me make a couple of comments: 1) Using service.ranking to give preference to a particular service implementation is very weak. As you have found (in another thread), there is no "pressure" on a consumer to make it consume the highest ranked

Re: [osgi-dev] Service ranking usage

Right. If you used static+greedy then you would see the deactivate and activate methods called. This is because static would force DS to create a new component instance. Neil On Tue, 10 Jul 2018 at 22:31, Alain Picard wrote: > Neil, > > As you saw I was on the right track but what I failed to

Re: [osgi-dev] Service ranking usage

Your reference to service ICoreUtils in Example is mandatory, static and reluctant. This means that whichever service it first binds to, it will hold for as long as possible. Since the lower ranked service is published by a bundle with a lower ID, it is probably published first. So that’s the one

Re: [osgi-dev] OSGi Specification Question

The spec is correct, and either Tim misspoke or you misheard him. The service should look like a big arrow pointing from the consumer to the provider. Neil On Thu, Jun 28, 2018 at 2:57 PM, Fauth Dirk (AA-AS/EIS2-EU) via osgi-dev < osgi-dev@mail.osgi.org> wrote: > Hi, > > > > maybe a stupid

Re: [osgi-dev] How best to refer to New enRoute and Classic enRoute

On Wed, Jun 20, 2018 at 7:44 AM, Paul F Fraser via osgi-dev < osgi-dev@mail.osgi.org> wrote: > Any opinions on how we should refer to the two versions? > > Perhaps "enRoute" for the new and "Classic enRoute" for the original. > This is my preference. A lot of "Classic" enRoute informed the OSGi

Re: [osgi-dev] Regarding service injection

On Thu, Apr 26, 2018 at 5:08 PM, Tim Ward via osgi-dev < osgi-dev@mail.osgi.org> wrote: > Hi Scott, > > The answer is really that it depends. The OSGi service registry supports > the registration of service instances and service factories. This means > that when you see a service registered in

Re: [osgi-dev] String[] in ds component config

There is some conversion happening inside DS, i.e. DS will be able to translate a single String object into a String[], but it will do so simply by creating a single-element array. It will not do any parsing of the content of that string. The client of ConfigAdmin (Karaf) really needs to set the

Re: [osgi-dev] Competing module systems

On Fri, Apr 13, 2018 at 2:24 PM, Mark Raynsford wrote: > On 2018-04-13T12:11:41 +0100 > Neil Bartlett wrote: > > > > To be clear, I'm not convinced OSGi would ever want to do this. If we > did, > > we would likely invert the default from "closed" to

Re: [osgi-dev] Competing module systems

On Fri, Apr 13, 2018 at 11:45 AM, Mark Raynsford wrote: > On 2018-04-13T09:32:30 +0100 > Neil Bartlett wrote: > > > > Interop already works just fine in one direction: OSGi bundles depending > on > > JPMS modules... > > Please indulge me in a bit of

Re: [osgi-dev] Competing module systems

On Thu, Apr 12, 2018 at 10:12 PM, Mark Raynsford via osgi-dev < osgi-dev@mail.osgi.org> wrote: > On 2018-04-12T20:32:13 +0200 > Peter Kriens wrote: > > > Caught between a rock and a hard place with only one way forward … > > I should make the point that I don't hate the

Re: [osgi-dev] How to use LoggerFactory with DS?

Yes, the new LogService version 1.4 and the new DS 1.4 support with explicit support for LogService 1.4 are both being introduced together in OSGi Release 7. You can use LogService 1.4 with an earlier DS but you will of course be constrained by the features of the version you choose. As far as I

Re: [osgi-dev] How to use LoggerFactory with DS?

Hi Dirk, have you read the section on Logger support in R7 Declarative Services? See https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-logger.support (or section 112.3.12 in the PDF). This section shows the recommended approach to obtaining a Logger instance

Re: [osgi-dev] JPMS modularization for various OSGi artifacts

> > On 22 Mar 2018, at 15:18, Mark Raynsford via osgi-dev > wrote: > > On 2018-03-22T13:18:18 + > "BJ Hargrave" wrote: > >> The R7 final API jars are already built and ready for release to Maven >> Central once the OSGi members approve the

Re: [osgi-dev] Bundle starts although no OSGi headers in its Manifest

Your manifest does not contain the declaration "Bundle-ManifestVersion: 2". That means it is interpreted as "Bundle-ManifestVersion: 1"... in other words an OSGi Release 3 (or older) compatible bundle. Before Release 4, OSGi had no mandatory manifest headers, even Bundle-SymbolicName. Therefore

Re: [osgi-dev] Question re. confguration-policy optional

If your activate method does not take the properties parameter, how do you read your initial configuration? Calling modified with null properties does not sound to me like the correct way for SCR to signal that the configuration record has been deleted. On Tue, Jan 23, 2018 at 12:50 PM, Erwin

Re: [osgi-dev] Question re. confguration-policy optional

The the component is *using* a configuration record (i.e. is has been activated with that record) and if it does not have a Modified method, then it must be deactivated when the configuration record is deleted. This part is, so far, the same for both optional and required configuration. After the

Re: [osgi-dev] Stumped - Unexpected duplicate component instantiation.

The scr:list output shows they are published by two separate bundle IDs, 112 and 137. Check whether you have accidentally built the component class into both bundles. Neil On 18 Jan 2018 11:45 pm, "Erwin Hogeweg via osgi-dev" < osgi-dev@mail.osgi.org> wrote: Hi, I have a very simple component,

Re: [osgi-dev] Apache Felix Web Console Components view

Since version 4 of WebConsole, the Declarative Services support has been moved to a separate bundle, “org.apache.felix.webconsole.plugins.ds”. Make you you have that bundle installed and active, in addition to the base Web Console bundle (“org.apache.felix.webconsole”). Neil > On 16 Nov