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

[Neil Bartlett via osgi-dev]

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 -> f.getBars("*"))
.collect(Collectors.toList());

We can operate directly on the volatile field rather than on a copy,
because it is only accessed once in each example. In my opinion this is the
main advantage of explicitly supporting Optional in DS.

(NB the second example is only valid on Java 9+ because it uses the
Optional.stream method added in Java 9).

Neil

On Mon, 28 Sep 2020 at 16:41, BJ Hargrave via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> I kind of like the idea of Optional for field injection. As Neil says,
> it is short hand for cardinality=ReferenceCardinality.OPTIONAL.
>
> Since R8 supports, Java 8 as the base language level, we can now add
> support for Optional as a field (and constructor) injection type. Bnd can
> infer the actual service type from the generic T.
>
> So
>
> @Reference
> Optional foo;
>
> would be a static optional reference to a Foo service, The foo field would
> be injected with either an empty Optional if there is no target Foo
> service, or a non-empty Optional with the bound Foo service. Like all
> static references, the foo field would not be changed by SCR during the
> life cycle of the component instance. This can also be used in constructor
> injection with a Optional constructor parameter.
>
> @Reference
> volatile Optional foo;
>
> would be a dynamic optional reference to a Foo service. The foo field
> would be injected with either an empty Optional if there is no target Foo
> service, or a non-empty Optional with the bound Foo service. Like all
> dynamic references, the value of the foo field can be changed by SCR at any
> time during the life cycle of the component instance. So when the component
> wishes to use the field, it should copy the field's value into a local
> variable before inspection and use.
>
> Optional localFoo = foo;
> if (localFoo.isPresent()) { do something with localFoo; }
>
> I do not think Promise is a proper type to use here. Promise is about a
> future result and is a one-time latch on resolving the value. At the time
> SCR will inject the field, the state of the target service must be known.
> For dynamic references, SCR must replace the field as the bound service
> changes. So there is no real utility in using Promise here as you still
> would have know way to know there was a new Promise object to which you
> might want to attach a callback.
>
> I will open an issue to add Optional support for field and constructor
> injection to DS 1.5 for R8.
>
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM // 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: Mark Hoffmann via osgi-dev 
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: Neil Bartlett 
> Cc: OSGi Developer Mail List 
> Subject: [EXTERNAL] Re: [osgi-dev] SCR: ServiceInjection into Fields that
> are Optional
> Date: Wed, Sep 23, 2020 10:14
>
> Hi Neil,
>
> exactly I thought of a fluent API for a ServiceTracker.
>
> Regards,
>
> Mark Hoffmann
> M.A. Dipl.-Betriebswirt (FH)
> CEO/CTO
>
> Phone: +49 3641 384 910 <+49%203641%20384%20910> 0
> Mobile: +49 175 701 2201 <+49%20175%20701%202201>
> E-Mail: m.hoffm...@data-in-motion.biz
>
> Web: www.datainmotion.de
> 
>
>
> Data In Motion Consulting GmbH
> Kahlaische Strasse 4
> 07745 Jena
> Germany
>
> Geschäftsführer/CEO
> Mark Hoffmann
> Jürgen Albert
>
> Jena HRB 513025
> Steuernummer 162/107/05779
> USt-Id DE310002614
>
>
>  Ursprüngliche Nachricht 
> Von: Neil Bartlett 
> Datum: 23.09.20 16:01 (GMT+01:00)
> An: Mark Hoffmann 
> Cc: OSGi Developer Mail List 
> Betreff: Re: [osgi-dev] SCR: ServiceInjection into Fields that are
> Optional
>
> Ah okay thank you. So you're not talking about the existing Promise class,
> rather a class that would keep track of the changing state of the service.
>
> As I think you said, that's basically a ServiceTracker. However the
> existing ServiceTracker class has a lot of complexity and still uses
> ancient APIs like Dictionary. So the requirement could be to define a new
> interface ("ServiceHandle"?) that has methods like:
>
> interface ServiceHandle {
> void ifPresent(Consumer); // from Optional
> Stream stream(); // from Optional
> Promise whenResolved();
> Promise whenUnresolved();
> }
>
> SCR could inject an instance of this interface into a component (component
> authors would not be able to instantiate 

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

[Neil Bartlett via osgi-dev]

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 would need a new empty optional instance.
> Optionals doesn't support to hold a state.
>

The state is in the component, not the Optional instance. References are
static by default, so under Stefan's example the component would be
destroyed if the field was bound to a service and that service instance
became unregistered. The proposed change to the spec is that SCR in this
case must reinitialize the field with Optional.empty() rather than with
null. For a dynamic reference, the field would need to be volatile just as
it is in R7. The only difference is that the field value would be replaced
by Optional.empty() rather than null in the case where the reference is
unbound.

There are two advantages that I can see. The first is brevity. When bnd
sees a field of type Optional, it can infer a cardinality of 0..1, so we do
not have to annotate with `cardinality=ReferenceCardinality.OPTIONAL`,
which is more verbose. The second is a thread-safety issue for dynamic
references. For example, suppose we have a dynamic optional reference in
R7, i.e.:

@Reference(cardinality=ReferenceCardinality.OPTIONAL,
policy=ReferencePolicy.DYNAMIC)
Foo foo;

When we want to use the field value we have to null check first, but the
following code -- although very clear and intuitive -- is unsafe:

if (foo != null) {
foo.doSomething();
}

It's unsafe because the value of the field can change between the null
check and the invocation of the method. The following code patterns with a
field of type Optional are safe however:

optFoo.ifPresent(Foo::doSomething)

or:

Stream barNames = optFoo.stream()
  .flatMap(foo -> foo.searchBars("*"))
  .map(Bar::toString);

They are safe because the value of the volatile field is only accessed once.


>
> In addition to that you don't have callbacks where to get notified about
> adding, modifying or removing a service.
>

We don't have callbacks today with field injection in R7. If you want
callbacks you need to use method injection.


>
>
> I could imagine, to get an object similar to the promise injected, that
> supports the lifecycle callbacks, as well as resolving, unresolving or
> re-resolving as well as handling cardinality.
>
> A fluent API around the OSGi's ServiveTracker could be a solution.
> Injecting Optional for just a subset of the supported cases in DS would,
> from my perspective "pollute" the spec.
>
> Maybe you can realize a custom solution using ServiceHooks?
>

I don't think that works because SCR and bnd would both have to explicitly
understand and support fields of type Optional.


>
> Regards,
>
> Mark Hoffmann
> M.A. Dipl.-Betriebswirt (FH)
> CEO/CTO
>
> Phone: +49 3641 384 910 <+49%203641%20384%20910> 0
> Mobile: +49 175 701 2201 <+49%20175%20701%202201>
> E-Mail: m.hoffm...@data-in-motion.biz
>
> Web: www.datainmotion.de
>
> Data In Motion Consulting GmbH
> Kahlaische Strasse 4
> 07745 Jena
> Germany
>
> Geschäftsführer/CEO
> Mark Hoffmann
> Jürgen Albert
>
> Jena HRB 513025
> Steuernummer 162/107/05779
> USt-Id DE310002614
>
>
>  Ursprüngliche Nachricht 
> Von: Stefan Bischof via osgi-dev 
> Datum: 22.09.20 15:48 (GMT+01:00)
> An: osgi-dev@mail.osgi.org
> Betreff: [osgi-dev] SCR: ServiceInjection into Fields that are
> Optional
>
> Hi,
>
> I like it to use Optionals if it is possible that a field could be null.
>
>
> In context of OSGi Services with SCR that means I have to handle it like
> this:
>
> ```
>
> @Component
> public class MyComponent
> {
>
> Optional oFoo = Optional.empty();
>
> @Reference(cardinality = ReferenceCardinality.OPTIONAL)
> void bindFoo(Foo foo)
> {
> oFoo = Optional.of(foo);
> }
> }
>
> ```
>
> What I really want to do is this:
>
> ```
>
> @Component
> public class MyComponent
> {
>
> @Reference
> Optional oFoo;
>
> }
>
> ```
>
>
> We have something like this in OSGi - CDI Integration Specification
> https://youtu.be/7-UUJ4WkMsg?t=839
>
> It would be nice to have this feature with the new version of the R8 DS
> Spec.
>
>
> Regards
>
> Stefan
> ___
> 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

Re: [osgi-dev] Library development

[Neil Bartlett via osgi-dev]

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
packages, so they just directly instantiate the DS component instance.
Because we used constructor injection, it's clear what dependencies
they need to provide to the component.
5. If there is a need to interact with OSGi's APIs (e.g. BundleContext),
keep that code in a separate factory component. Put this code in a separate
class from the "business logic". Don't necessarily worry about using a
separate package for this... because Java ClassLoading is extremely lazy,
non-OSGi consumers will only be exposed to the OSGi-specific code if they
go out of their way to load it.

On Thu, 21 May 2020 at 01:50, Bernd Eckenfels via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hello,
>
> We typically use declarative services (DS) with the Maven bundle plugin
> and Annotations. This leaves no (optional) OSGi framework dependency and
> still allows a compliant container to manage the lifecycle of the component.
>
> In some (rare) cases when you have to deal with service references or OSGi
> context and you need the core API it does also not hurt to make it
> optional, as long as the class which uses it (and would not resolve) is not
> used by the stand alone code. This is typically the case for OSGi first
> components which are made compatible with stand alone unit tests.
>
> You can even have the factory receive the service, and therefore be
> useable inside the runtime.
>
> An alternative is, to just have the bundle headers and no service, this is
> still useful to OSGi code in many instances where you don't have a service
> lifecycle.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> --
> *Von:* osgi-dev-boun...@mail.osgi.org  im
> Auftrag von David Leangen via osgi-dev 
> *Gesendet:* Thursday, May 21, 2020 12:44:04 AM
> *An:* osgi-dev@mail.osgi.org 
> *Betreff:* [osgi-dev] Library development
>
> Hi!
>
> What is the best way to prepare a library to OSGi-compatible, but not
> force the use of OSGi (including forcing transitive dependencies)?
>
> The library should be split into api / implementation and offered as a
> service, but it should be possible for those who do not use OSGi to obtain
> the implementation class from a factory. There should be no runtime
> dependency on the OSGi framework.
>
> Are there any good examples out there that I could try to emulate?
>
> If not, can anybody provide me with some advice?
>
> My thought is to have:
>
>  1. A public api package (for all cases)
>  2. A private “factory” package (which for OSGi users would just be
> private and ignored, and for non-OSGi users would be the part of the
> library they would use to obtain the service class), and
>  3. An “internal” package that includes an Activator (in an OSGi
> environment this would provide the service implementation, for non-OSGi
> users it would be ignored).
>
>
> Thanks so much!!
>
> Cheers,
> =David
>
>
> ___
> 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

Re: [osgi-dev] Parent Class Loader Bootdelegation

[Neil Bartlett via osgi-dev]

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 of those classloaders.

Neil

On Thu, 19 Mar 2020 at 09:42, Eran Twili via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi,
>
>
>
> We're embedding OSGi inside an outer application.
>
> Our hosting application (platform) creates several class loaders beneath
> the jvm system class loader, and from one of them the OSGi FW is created.
>
> Class loader hierarchy something like:
>
> jvm boot -> jvm ext -> jvm system -> custom1 -> custom2 -> custom3 -> OSGi
> FW (aka system bundle)
>
>
>
> We now experience problems with our platform Profiler.
>
> *How can I make the bootdelegation to delegate to the class loader that
> loaded the OSGi FW?*
>
> org.osgi.framework.bundle.parent = ???
>
> to my understanding,
>
> setting "app" will delegate to the jvm system class loader.
>
> setting "framework" will delegate to the system bundle.
>
>
>
> Thanks,
>
> Eran
>
>
>
>
> Confidentiality: This communication and any attachments are intended for
> the above-named persons only and may be confidential and/or legally
> privileged. Any opinions expressed in this communication are not
> necessarily those of NICE Actimize. If this communication has come to you
> in error you must take no action based on it, nor must you copy or show it
> to anyone; please delete/destroy and inform the sender by e-mail
> immediately.
> Monitoring: NICE Actimize may monitor incoming and outgoing e-mails.
> Viruses: Although we have taken steps toward ensuring that this e-mail and
> attachments are free from any virus, we advise that in keeping with good
> computing practice the recipient should ensure they are actually virus free.
> ___
> 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

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

[Neil Bartlett via osgi-dev]

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 between compile, test, runtime and provided scopes.

For those using plain Maven, the proper practice is to use the dependency
osgi.core with provided scope, and then an OSGi implementation JAR such as
Equinox (org.eclipse.osgi) or Felix (org.apache.felix.framework) with
runtime scope.

Neil

On Fri, 3 Jan 2020 at 14:29, Dirk Fauth via osgi-dev 
wrote:

> Well afaik Tycho has its own reactor for resolving dependencies. That's
> why I am a bit confused about your message. If you build via Tycho you need
> to have a working target definition or repositories configuration. POM
> dependencies are not considered by default. If you update to R7 you need to
> update to a current Eclipse update site and ensure that all related bundles
> and/or features are included.
>
> But of course I am not sure if I understand your issue completely. If you
> are not building using Tycho but plain Maven probably some dependencies are
> not resolvable. But the previous answers already covered most topics. I
> just stepped in because of mentioning Tycho and pom dependencies.
>
> Greez,
> Dirk
>
> Martin Petzold  schrieb am Fr., 3. Jan. 2020, 15:16:
>
>> Because I want to manage my package dependencies in the MANIFEST.MF and I
>> want to be able to run my application in an PDE environment with a separate
>> target platform within Eclipse. However, this post is only related to my
>> build and not to my development environment.
>> Am 03.01.20 um 15:11 schrieb Dirk Fauth:
>>
>> And why are you using Tycho when there is no PDE involved?
>>
>> Martin Petzold  schrieb am Fr., 3. Jan. 2020, 15:05:
>>
>>> Only Maven repositories. No PDE. Plain OSGi application with my own
>>> launcher at runtime. At runtime there is no problem. This application is
>>> running for years and I have worked with OSGi for years now. I just have
>>> this trouble migrating to OSGi 7.0.0 and at compile / build time with
>>> Maven+Tycho.
>>> Am 03.01.20 um 15:02 schrieb Dirk Fauth:
>>>
>>> And do you get the error at build time or when running your result?
>>>
>>> With Tycho you typically use PDE mechanisms to resolve dependencies, not
>>> maven dependencies.
>>>
>>> And what is your result? A plain OSGi application or a RCP application?
>>>
>>> Greez,
>>> Dirk
>>>
>>> Dirk Fauth  schrieb am Fr., 3. Jan. 2020, 14:37:
>>>
 Hi,

 If you are using Tycho, which repository are you using for dependency
 resolution? Or do you build using a target definition? If so, which eclipse
 software site have you configured?

 Greez,
 Dirk

 Martin Petzold via osgi-dev  schrieb am Fr.,
 3. Jan. 2020, 14:20:

> Dear Neil,
>
> thanks, but now we start again at the beginning at my first message
> (endless loop): I cannot set a dependency to "org.osgi:osgi.core" in Maven
> (with Tycho) because it requires 'osgi.unresolvable;
> (&(!(must.not.resolve=*))(must.not.resolve=*))'.
>
> Kind regards,
>
> Martin
> Am 03.01.20 um 14:12 schrieb Neil Bartlett:
>
>
>
> 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 during compile time? Either there is a
>> separate API bundle from OSGi Alliance containing "org.osgi.framework"
>> (which one is it?)
>>
>
> Yes, this is the org.osgi:osgi.core dependency. That contains the pure
> api and no implementation, whereas org.eclipse.osgi is an implementation.
>
> Or you could just use org.eclipse.osgi at both compile time and
> runtime, but then you should be careful to avoid using equinox internal
> packages.
>
> or I should set the scope to compile instead of runtime?
>>
>> I am using the BundleContext and need access to this package.
>>
>> Thanks and kind regards,
>>
>> Martin
>> Am 03.01.20 um 10:51 schrieb Mark Hoffmann via osgi-dev:
>>
>> Hi Martin,
>>
>> see comments inline.
>>
>> Regards,
>>
>> Mark
>> Am 02.01.20 um 19:19 schrieb Martin Petzold via osgi-dev:
>>
>> Thanks, Raymond! Does this also relate to "org.osgi:osgi.cmpn"?
>> Should I remove this dependency too? Should I add
>> "org.eclipse.osgi.services" or the individual "org.osgi.service.*" to my
>> (parent) POM? Are the individual "org.osgi.service.*" also required at
>> runtime (on classpath or installed to osgi?). Will "org.eclipse.osgi" 
>> start
>> without 

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

[Neil Bartlett via osgi-dev]

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 during compile time? Either there is a
> separate API bundle from OSGi Alliance containing "org.osgi.framework"
> (which one is it?)
>

Yes, this is the org.osgi:osgi.core dependency. That contains the pure api
and no implementation, whereas org.eclipse.osgi is an implementation.

Or you could just use org.eclipse.osgi at both compile time and runtime,
but then you should be careful to avoid using equinox internal packages.

or I should set the scope to compile instead of runtime?
>
> I am using the BundleContext and need access to this package.
>
> Thanks and kind regards,
>
> Martin
> Am 03.01.20 um 10:51 schrieb Mark Hoffmann via osgi-dev:
>
> Hi Martin,
>
> see comments inline.
>
> Regards,
>
> Mark
> Am 02.01.20 um 19:19 schrieb Martin Petzold via osgi-dev:
>
> Thanks, Raymond! Does this also relate to "org.osgi:osgi.cmpn"? Should I
> remove this dependency too? Should I add "org.eclipse.osgi.services" or the
> individual "org.osgi.service.*" to my (parent) POM? Are the individual
> "org.osgi.service.*" also required at runtime (on classpath or installed to
> osgi?). Will "org.eclipse.osgi" start without "org.eclipse.osgi.services"
> on the classpath or installation as bundle?
>
> You have to distinguish between the packages you want to resolve and the
> artifacts/bundles that contain the the packages/implementations.
>
> In your case org.eclipse.osgi.services is the bundle that exports the
> packages org.osgi.service.* packages.
>
> Because Maven just resolves artifacts, you need to provide the bundle
> org.eclipse.osgi.services as dependency.
>
> Yes, org.eclipse.osgi will start without org.eclipse.osgi.services
>
> I have now added "org.eclipse.osgi.services". However, it now cannot
> requires "org.osgi.util.promise". What should I add to my POM in order to
> resolve the core Eclipse OSGi implementation (only OSGi core
> implementation)?
>
> You should find the promises and functions in the bundle
> org.eclipse.osgi.util
>
> btw I have removed the runtime scope for "org.eclipse.osgi".
> Am 02.01.20 um 19:00 schrieb Raymond Auge:
>
> A bit of rational about why companion jars are unresolvable:
>
> The OSGi specs are to a very high degree independent from each other.
> There's no reason for you to be forced to use all R5 specs, or all R6 or
> whatever. Those are simply marketing versions.
>
> What you are really using are the individual specs at a given version.
>
> For example using DS 1.4, Event 1.0, and logging 1.2 is perfectly fine
> combination given you can find providers of each that work together well.
> The APIs themselves won't care.
>
> However some providers actually package OSGi spec APIs which they provide
> implementations for, which means if you include the aggregate companion
> jars also at runtime you may have two API versions to contend with.
>
> You may inadvertently expose yourself to a wrong API version, hence why
> they will no longer resolve.
>
> - Ray
>
> On Thu, Jan 2, 2020 at 12:36 PM Raymond Auge 
> wrote:
>
>> Yes and yes.
>>
>> OSGi started adding the unresolveable requirement at release 6 IIRC. So
>> if you are using a prior releases of the companion jars (including cmpn,
>> enterprise) they won't give you this failure, so you should upgrade.
>>
>> *Replacements:* Replace the compendium APIs with their respective
>> individual api jars available on maven central, like this one [1].
>>
>> [1]
>> https://search.maven.org/artifact/org.osgi/org.osgi.service.component.annotations/1.4.0/jar
>>
>> - Ray
>>
>>
>> On Thu, Jan 2, 2020 at 12:31 PM Martin Petzold  wrote:
>>
>>> Thanks, Raymond! Does this also relate to "org.osgi:osgi.cmpn"? Should I
>>> remove this dependency too?
>>> Am 02.01.20 um 18:23 schrieb Raymond Auge:
>>>
>>>
>>>
>>> On Thu, Jan 2, 2020 at 12:17 PM Martin Petzold via osgi-dev <
>>> osgi-dev@mail.osgi.org> wrote:
>>>
 Dear OSGi gurus,
 I have a dependency on "org.osgi:osgi.core" (7.0.0) in my POM. The
 reason is that I need access to the "org.osgi.framework" package. I am
 using Maven (3.6) and Tycho (1.5.1) for building. The build platform runs
 Debian 10 and Java 11.

 *I get the following error:*

 Missing requirement: osgi.core 7.0.0.201802012106 requires
 'osgi.unresolvable; (&(!(must.not.resolve=*))(must.not.resolve=*))' but it
 could not be found

>>>
>>> The "companion jars" are not meant for runtime and since resolving is a
>>> runtime operation (even when performed during build, i.e. deployment
>>> purposes) should not be included.
>>>
>>>
 *However, if I remove the dependency I get the following error:*
 Missing requirement: my.bundle 0.0.0.qualifier requires 'java.package;
 org.osgi.framework 

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

[Neil Bartlett via osgi-dev]

> 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 default import range is an implementation choice of the bnd developers.

All functionality that is specced by OSGi here -- i.e. the resolving of the
bundles -- is working perfectly according to the relevant OSGi
specification.

As for why bnd makes this implementation choice, bear in mind that import
ranges are applied to packages, which in a pure and ideal world would
contain only interfaces and perhaps DTOs, but no implementation code. What
kind of "bugs" could we be talking about in such a package, other than
documentation? Of course the world is not always pure and ideal which is
why the default can be overridden.

Neil



On Tue, 18 Jun 2019 at 09:54, Michael Lipp via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

>
> Considering this, lowering a lower bound of an Import-Package statement
> when resolving should be acknowledged as a bug.
>
> I beg to differ ...
>
> As said, you can set the consumer/provider policy to your desired strategy.
>
> So having default settings in the tool that cause a behavior that does not
> comply with the specification should not be considered a bug?
>
>  - Michael
>
>
>
> Kind regards,
>
> Peter Kriens
>
> On 18 Jun 2019, at 10:33, Michael Lipp  wrote:
>
>
>
> I expect there are two things at play. First, OSGi specifies things as you
> indicate. An import of [1.2.3.qualifier,2) must not select anything lower
> than 1.2.3.qualifier. Second, bnd does have heuristics that do drop the
> qualifier and micro part in calculating the import ranges from the exports
> on the class path.
>
> Thanks for the clarification, I think this explains things.
>
> [...]
>
> Conclusion, the spec is perfect but the implementations apply heuristics
> and may have bugs.
>
> The specification says (or defines, if you like): "micro - A change that
> does not affect the API, for example, a typo in a comment or a bug fix in
> an implementation." It explicitly invites the developer to indicate a bug
> fix by incrementing the micro part. There's no hint or requirement that he
> should increment the minor part to reflect a bug fix. I do not find your
> statement "The definition of the micro version is that it should not make a
> difference in runtime" to be supported by the spec or the Semantic
> Versioning Whitepaper. Actually, this interpretation would restrict the
> usage of the micro part to documentation changes because every bug fix
> changes the runtime behavior. This is, after all, what it is intended to do.
>
> Considering this, lowering a lower bound of an Import-Package statement
> when resolving should be acknowledged as a bug.
>
>  - Michael
>
>
>
> Kind regards,
>
> Peter Kriens
>
> On 17 Jun 2019, at 12:14, Michael Lipp via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> Hi,
>
> I have in my repository a bundle A-2.0.1 that exports packages with
> version 2.0.1 and a bundle A-2.0.3 that exports these packages with
> version 2.0.3. Version A-2.0.3 fixes a bug.
>
> I have a bundle B that imports the packages from A with import
> statements "... version=[2.0.3,3)" because the bug fix is crucial for
> the proper working of B.
>
> Clicking on "Resolve" in bndtools, I get a resolution with bundle
> A-2.0.1. I understand that this complies with the specification ("It is
> recommended to ignore the micro part of the version because systems tend
> to become very rigid if they require the latest bug fix to be deployed
> all the time.").
>
> What I don't understand is the rationale. I don't see any drawbacks in
> deploying the latest bug fix. Of course, there's always the risk of
> introducing a new bug with a new version, even if it is supposed to only
> fix a bug in the previous version. But if you're afraid of this, you may
> also not allow imports with version ranges such as "[1.0,2)" (for
> consumers).
>
> In my case, I now have to distribute bundle B with a release note to
> configure the resolution in such a way that only A 2.0.3 and up is used.
> Something that you would expect to happen automatically looking at the
> import statement. And if I want to make sure that the release note is
> not overlooked, the only way seems to be to check the version of "A" at
> run-time in the activation of "B". This is downright ugly.
>
>  - Michael
>
>
> ___
> 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

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

[Neil Bartlett via osgi-dev]

"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 <
osgi-dev@mail.osgi.org> wrote:

> Hi Tim,
>
> I may have expressed myself badly. Nothing goes wrong, everything works
> according to the specification, which states that the micro part of the
> version should be ignored when resolving bundles.
>
> My question is whether anybody can explain why the behavior was
> specified in such an "unreasonable" way. I tried to explain why I
> consider the behavior "unreasonable": if I author and deliver a bundle
> ("B" in my Mail) and I know that it only works with a specific
> "bug-fixed" version of another bundle ("A-2.0.3") then there is no way
> to enforce that this version is used by my customer.
>
> "Import-Package" with "version=[2.0.3,3)" does not help, because the
> micro part is specified to be ignored. So effectively, requiring
> "version=[2.0.3,3)" is just like requiring "version=[2.0,3)" which makes
> the buggy versions "A-2.0.0" to "A-2.0.2" candidates for the resolution.
>
> Of course, I can state in the release notes of bundle "B" that a user of
> the bundle must take care to not have a version below 2.0.3 in his
> repository. But honestly, if the user happens to already have e.g.
> version A-2.0.1 in his repository due to a requirement that existed
> before adding my bundle to his application, and he adds my bundle and
> everything seems to work fine, how probable is it that he reads the
> release notes when --maybe days later-- something goes wrong because of
> the bug in A-2.0.1?
>
> If OSGI didn't specify that the micro part should be dropped, then
> everything would be fine. Resolution would only be possible if at least
> version 2.0.3 of "A" was available. So, why do we have this
> "unreasonable" specification?
>
>  - Michael
>
>
> Am 17.06.19 um 15:17 schrieb Tim Ward:
> > Hi Michael,
> >
> > I’m afraid that there’s quite a lot of missing information before I
> could come to a conclusion about what’s going on. What are your input
> requirements? Have you checked that B actually has the version range that
> you think it does? Are there two versions of A being deployed? If it’s
> possible to share the workspace then we might be able to bottom out what’s
> happening.
> >
> > Also, if 2.0.1 of A is known to be broken then why do you have it in the
> repository that you are resolving against? The best defence against “bad”
> resolutions is to have a well curated repository. As with many things
> garbage in == garbage out.
> >
> > All the best,
> >
> > Tim
> >
> >> On 17 Jun 2019, at 11:14, Michael Lipp via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
> >>
> >> Hi,
> >>
> >> I have in my repository a bundle A-2.0.1 that exports packages with
> >> version 2.0.1 and a bundle A-2.0.3 that exports these packages with
> >> version 2.0.3. Version A-2.0.3 fixes a bug.
> >>
> >> I have a bundle B that imports the packages from A with import
> >> statements "... version=[2.0.3,3)" because the bug fix is crucial for
> >> the proper working of B.
> >>
> >> Clicking on "Resolve" in bndtools, I get a resolution with bundle
> >> A-2.0.1. I understand that this complies with the specification ("It is
> >> recommended to ignore the micro part of the version because systems tend
> >> to become very rigid if they require the latest bug fix to be deployed
> >> all the time.").
> >>
> >> What I don't understand is the rationale. I don't see any drawbacks in
> >> deploying the latest bug fix. Of course, there's always the risk of
> >> introducing a new bug with a new version, even if it is supposed to only
> >> fix a bug in the previous version. But if you're afraid of this, you may
> >> also not allow imports with version ranges such as "[1.0,2)" (for
> >> consumers).
> >>
> >> In my case, I now have to distribute bundle B with a release note to
> >> configure the resolution in such a way that only A 2.0.3 and up is used.
> >> Something that you would expect to happen automatically looking at the
> >> import statement. And if I want to make sure that the release note is
> >> not overlooked, the only way seems to be to check the version of "A" at
> >> run-time in the activation of "B". This is downright ugly.
> >>
> >>  - Michael
> >>
> >>
> >> ___
> >> 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

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

[Neil Bartlett via osgi-dev]

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, Mohamed AFIF via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hello everybody,
>
> We 're starting to study the possibility to transform our architcteure in
> order to migrate from OSGI to microservice architecture, and I would like
> to know if there is alreay some people who had thought about this subject
> or already start this migration.
> Because at first sight it would not be an easy task, many problems/issues
> we will be facing to them (blueprint injections, managing ditrubued caches
> instead of one cache in one JVM...)
>
> Many thanks
>
>
>
> --
>
> Cdt
> Mohamed AFIF
> ___
> 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

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

[Neil Bartlett via osgi-dev]

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 Tracked holds a lock on itself
> during the processing of the relevant listener callbacks (most of which
> hold a "state change" lock on the bundle). It thus "forwards" the internal
> "state change" lock to a lock on itself. So all the operations of
> BundleTracker that are synchronized on its associated instance of Tracked
> are effectively synchronized on the framework's internal "state change"
> lock. It's just a rather complicated way to access that "state change" lock.
>

I've never cared that much about the internal implementation of
BundleTracker. It just works...

Neil


> But thanks for the hint, I had forgotten about the bundle tracker---it's
> not required very often. It seems like big tool for my simple problem. I'll
> check if it does what I need.
>
> Michael
>
>
> 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 should override) is invoked with any bundles that are
> *already* in the state that you are looking for. Then addingBundle() is
> invoked for any bundles that later enter the state you are looking for. In
> any case it is only invoked once, unless of course a bundle transitions in
> and out of the required state multiple times. This should solve your
> non-idempotent problem.
>
> Neil
>
> On Fri, 1 Mar 2019 at 12:39, Michael Lipp via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Hi,
>>
>> I just want to make sure: there's no method for obtaining the "state
>> change" lock on a Bundle, right?
>>
>> I'm asking because I want an action to be performed once the bundle has
>> reached a particular state. Without this lock I have to follow the usual
>> procedure for such cases:
>>
>> * Check for target state
>>
>> * Register listener
>>
>> * Check for target state again (because target state may have been
>> reached between previous check and registration of listener, so listener
>> is never invoked).
>>
>> ... which gets a bit more complicated still if the action to be
>> performed when the target state is reached isn't idempotent.
>>
>> A bundle "state change" lock is mentioned in the
>> SynchronousBundleListener API, but I couldn't find a way to access it.
>>
>> Best regards,
>>
>> Michael
>>
>> ___
>> 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

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

[Neil Bartlett via osgi-dev]

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 should override) is invoked with any bundles that are
*already* in the state that you are looking for. Then addingBundle() is
invoked for any bundles that later enter the state you are looking for. In
any case it is only invoked once, unless of course a bundle transitions in
and out of the required state multiple times. This should solve your
non-idempotent problem.

Neil

On Fri, 1 Mar 2019 at 12:39, Michael Lipp via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi,
>
> I just want to make sure: there's no method for obtaining the "state
> change" lock on a Bundle, right?
>
> I'm asking because I want an action to be performed once the bundle has
> reached a particular state. Without this lock I have to follow the usual
> procedure for such cases:
>
> * Check for target state
>
> * Register listener
>
> * Check for target state again (because target state may have been
> reached between previous check and registration of listener, so listener
> is never invoked).
>
> ... which gets a bit more complicated still if the action to be
> performed when the target state is reached isn't idempotent.
>
> A bundle "state change" lock is mentioned in the
> SynchronousBundleListener API, but I couldn't find a way to access it.
>
> Best regards,
>
> Michael
>
> ___
> 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

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

[Neil Bartlett via osgi-dev]

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 @Reference List static, reluctant? For 0/1..1 this makes
> sense to me, but for me an expected default behavior for 0/1..n references
> would have been dynamic, greedy, so that I end up with some services
> isntead of probably none.
>

The default is reluctant because "greedy" did not exist until DS 1.2. If
the default had been made greedy at that time, components coded before DS
1.2 would have seen a substantial change in behaviour that could be
considered non-backwards-compatible.

Static has *always* been the default over dynamic, because dynamic forces
the developer to understand thread safety and to code the component much
more cautiously. Static is simple and safe.


>
> 2) The observed Exception for optional/dynamic/reluctant: Is it intended?
> I tried to switch to bnd 4.2.0 to see if this exxception occurs there too,
> but was unable to do so. When I change the version number of bnd to 4.2.0
> in the standard enRoute setup, then some of the bnd-plugins can not be
> found by maven.
>

Probably not expected, this smells like a bug.


>
> Kind regards,
> Thomas
>
> -- Originalnachricht --
> Von: "Tim Ward" 
> An: "Thomas Driessen" ; "OSGi Developer
> Mail List" 
> Cc: "Raymond Auge" 
> Gesendet: 18.02.2019 10:15:54
> Betreff: Re: [osgi-dev] Clarification on reference behavior regarding
> field injection
>
> Hi Thomas,
>
> Just to clarify, the behaviour that you see with static reluctant services
> will always look “odd” for cardinalities other than mandatory, and what
> you’ve recorded is 100% correct behaviour.
>
>
>- Static references force the component to be re-created if the value
>of the reference changes
>- Reluctant references avoid rebinding the service unless it is
>required
>
>
> Therefore:
>
>
>- An optional reference bound to nothing will never bind to anything
>again (unless the component is re-created for another reason) because
>having zero references is valid and you are reluctant to re-create the
>component instance
>- An optional reference bound to a service will not change until that
>service is unregistered (ignoring all new services), at which point it will
>either:
>   - Pick up the highest ranked of any matching registered services
>   - Bind to nothing if no matching services are available
>- A multiple reference bound to nothing will behave exactly like an
>optional component
>- A multiple reference bound to one or more services will not change
>until any of the bound services are unregistered (ignoring all new
>services), at which point it will either:
>   - Pick up all the available registered services
>   - Bind to nothing if no matching services are available
>- An “at least one" reference bound to one or more services will not
>change until any of the bound services are unregistered (ignoring all new
>services), at which point it will either:
>   - Pick up all the available registered services
>   - Make the component unsatisfied
>
>
>
> The end result of this is that references that can accept zero will tend
> to zero over time, and then tend to stay with zero bound references. At
> least one references will tend to a small number of “stable” services with
> new services ignored.
>
> In general references of these types should be dynamic or greedy (or both).
>
> Best Regards,
>
> Tim
>
> On 18 Feb 2019, at 09:38, Thomas Driessen via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> Oh Sorry :/
>
> Those combinations with cardinalities optional/mandatory have been
> assigned to ITest, those with multiple/at_least_one have been assigned to
> List.
>
> I didn't think it makes sense to assign them vice versa, e.g., ITest with
> multiple or List with mandatory? Or am I wrong? If so, in what case
> would you use such a combination?
>
> Kind regards,
> Thomas
>
> -- Originalnachricht --
> Von: "Raymond Auge" 
> An: "Thomas Driessen" ; "OSGi Developer
> Mail List" 
> Gesendet: 16.02.2019 17:42:19
> Betreff: Re: [osgi-dev] Clarification on reference behavior regarding
> field injection
>
> You're chart doesn't appear to list _which_ field (Reference) was
> associated with any given line (collection vs. scalar). It makes a
> difference.
>
> - Ray
>
> On Sat, Feb 16, 2019 at 9:15 AM Thomas Driessen via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Hi,
>>
>> I'm trying to get an overview over the effects of different combinations
>> of cardinality, policy and policyOption within a @Reference annotation for
>> a field.
>>
>> My Example looks like this:
>>
>> @Component
>> public class MyComp{
>>   @Reference(...)
>>   ITest myTest;
>>
>>   @Reference(...)
>>   List myTests;
>> }
>>

Re: [osgi-dev] bundle symbolic name

[Neil Bartlett via osgi-dev]

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 7, 2018 at 10:30 AM Robert Munteanu via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi Ali,
>
> On Wed, 2018-11-07 at 06:53 +0300, Ali Parmaksız via osgi-dev wrote:
> > Hi all,
> > This is a basic question. But i want to ask you why symbolic name is
> > needed?
> > Then i think that it is about bundle installation, bundle:install
> > command
> > is sometihng like that:
> > bundle:install mvn:com.groupID/artifactId/version
> > When i checked manifest.mf, symbolic name is com.groupID.artifactId
> > Now this is my question, what is relation between symbolic name and
> > bundle:insall? If symbolic name is not for this, then for what?
>
> The bundle's symbolic name is used mostly inside an OSGi container to
> perform various operations. The name + version uniquely identify a
> bundle inside the container.
>
> The fact that the bundle's symbolic name is set to groupId + artifactId
> is a convention, and other projects could:
>
> - set the bundle symbolic name to artifactId ( Apache Felix does so )
> - select a completely different artifactId
>
> The command you referenced installs a bundle from maven coordinates,
> but there are other ways to do so, notably:
>
> - installing from a local/remote jar file
> - resolving + installing a bundle using a bundle symbolic name and
> version, based on an OSGi index
>
> So to come back to your question - there relation between the symbolic
> name and the specific install command you referenced is mostly by
> convention.
>
> Hope this helps,
>
> Robert
>
> ___
> 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

Re: [osgi-dev] Service component resolution time

[Neil Bartlett via osgi-dev]

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
org.eclipse.equinox.p2.reconciler.dropins bundle is present. This bundle is
part of Eclipse p2 and it supports the "drop-ins" folder functionality...
it performs a second resolution of the complete set of installed bundles
plus the dropins folder, and it is VERY slow. Most apps don't need this
functionality. By removing it I cut the start time of one application from
nearly 2 minutes (not exaggerating) down to 15 seconds (still not great,
more work to do).

Regards,
Neil

On Mon, Oct 22, 2018 at 6:43 PM Alain Picard via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> We are experiencing some long startup time in our reafactored application
> that is now heavily using SCR.
>
> We have 125 projects with over 1200 Service Components and it takes about
> 2 minutes to get any output in the console. Some quick analysis shows that
> its running the Felix ResolverImpl with something like 5-6 thread (that is
> with Equinox).
>
> I looked in that class but there doesn't seem to be any tracing code, only
> what appears to be some debugging code.
>
> Is this expected? If not what have others used to resolve this issue?
>
> Thanks
> Alain
> ___
> 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

Re: [osgi-dev] Double config

[Neil Bartlett via osgi-dev]

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 thorough review of all my
> code. I have identified a lot of places where there was potential for
> concurrency errors, and I made a lot of simplifications (mostly by
> eliminating any clever use of concurrency or synchronization when it wasn’t
> really providing any tangible benefit, and only introducing risk). I also
> reviewed again the DS lifecycle, as well as Trackers. I am pretty confident
> that my understanding of the concurrent issues, and consequently my system,
> are now in good shape. I think I can handle the dynamics now in a robust
> way (though I still don’t know how to test for it to confirm).
>
> However, I am experiencing one problem on startup still that baffles me.
>
> Take this component:
>
>
> @Component(
> factory = ...,
> configurationPid = ...,
> configurationPolicy = ConfigurationPolicy.REQUIRE)
> public class D
> implements Descriptor
> {
> @Reference( scope = ReferenceScope.PROTOTYPE_REQUIRED )
> private WriterFactory.JsonWriterFactory factory;
>
> @Activate
> void activate( Configuration.Config config )
> {
>   ...
> }
>
> ...
> }
>
>
> There is really nothing more to the component that this. One static
> reference (which is satisfied), and a required config (which is available).
>
> The factory basically looks like this (called from a different component
> that instantiates this tracker):
>
>
> public class ComponentFactoryTracker
> extends ServiceTracker
> {
> public ConfinementAwareComponentFactoryTracker( BundleContext context,
> Filter filter )
> {
> super( context, filter, null );
> }
>
> @Override
> public ComponentInstance addingService(
> ServiceReference reference )
> {
> final ComponentFactory cf = context.getService( reference );
> final Dictionary properties = new Hashtable<>();
> properties.put( ... );
> final ComponentInstance instance = cf.newInstance( properties );
> return instance;
> }
>
> @Override
> public void removedService( ServiceReference
> reference, ComponentInstance instance )
> {
> context.ungetService( reference );
> instance.dispose();
> }
> }
>
> Fairly simple.
>
> The system starts up, and the D component (and others like it) also
> starts. Then bouncing happens. When things finally settle down after one
> bounce, D (and others like it) gets deactivated. This is where I start
> pulling my hair out. **Why** does it get deactivated???
>

I can't explain this either. The only suggestions I can make are:

1) Write a deactivate method, stick a breakpoint on it and look at the
stack. That might give you a clue as to why and how you got there.
2) Create a demonstrator project and raise a bug against the SCR
implementation.


>
>  —> The one and only static reference is available. Check.
>
>  —> The configuration is available. Check.
>
>  —> The  ComponentFactory services are enabled. Check.
>
> However, despite all the prerequisites being available, D (and others) are
> getting deactivated. I even created an immediate service that references D
> (and others) to ensure that somebody was calling it. Nothing. Nada. All
> that I can validate is that as D (and others) get deactivated, they are
> unbound from this test service.
>
> If I restart any bundle that causes D to refresh, then the state of the
> system comes up correctly. It is only upon initial startup that this
> problem occurs.
>
> If I try injecting some service that potentially changes startup order,
> sometimes it works, but I have not yet figured out the pattern. In any
> case, since the prerequisites for the service are available, I don’t see
> why on Earth that should matter, anyway. Unless maybe there is a bug in SCR
> for some edge case (felix version 2.0.2).
>

This is indeed my suspicion based on what you have described. Have you
tried using a later SCR implementation, just in case it's a bug that's
already been fixed?

Neil


>
>
> I am at a loss...
>
>
> Cheers,
> =David
>
>
>
> On Jul 14, 2018, at 4:05, David Leangen via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>
> Hi Tim,
>
> What is a good way to test for robustness against this phenomenon?
>
>
> Again, I wish to go on record as saying that bouncing does not mean that
> anything is wrong, nor is it intrinsically bad.
>
>
> Thanks. Understood. I did not mean to imply anything about “goodness” or
> “badness”, but it is good to have that on record.
>
> So, my question was: knowing that this happens, is there a good way to
> test against it? My understanding is that currently there is not.
>
>
> Cheers,
> =David
>
> ___
> OSGi 

Re: [osgi-dev] Double config

[Neil Bartlett via osgi-dev]

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 activation, so
unless you are storing state in static fields (hopefully you don't need me
to tell you that would be a bad idea!) your component only needs to deal
with a straightforward start/stop lifecycle. For example when it starts, it
may as well be the only time it has ever started. If you have specified
optional configuration or any optional service references then you need to
deal with the possibility that config/services may be null, and you should
write unit tests for all combinations of config/services being unbound and
unbound. Obviously you don't want too many optional references because the
number of required test cases rises exponentially.

The harder question is about components that deliberately expose themselves
to the bouncing of other components – in other words, they have dynamic
service references – and/or expose themselves to dynamic configuration
changes by having a modified method. Tim talked about components that
require heavyweight initialisation... to implement such a component you
might write a modify method to accept dynamic config changes and then
internally implement some kind of damping mechanism. This gets you into
some slightly hairy multithreading code. I don't have a good answer myself
yet for testing this kind of code, it seems like even the best available
practices are still quite primitive and probabilistic, e.g. running the
same code thousands of times and hoping to find an error. I would love to
find something better.

Hope this helps,
Neil



On Fri, Jul 13, 2018 at 8:05 PM David Leangen via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

>
> Hi Tim,
>
> >> What is a good way to test for robustness against this phenomenon?
> >
> > Again, I wish to go on record as saying that bouncing does not mean that
> anything is wrong, nor is it intrinsically bad.
>
> Thanks. Understood. I did not mean to imply anything about “goodness” or
> “badness”, but it is good to have that on record.
>
> So, my question was: knowing that this happens, is there a good way to
> test against it? My understanding is that currently there is not.
>
>
> Cheers,
> =David
>
> ___
> 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

Re: [osgi-dev] Extending Services

[Neil Bartlett via osgi-dev]

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 component is
activated. But possibly SCR prevents this scenario, I'm not sure.

A safe way to protect against this regardless is to use properties and
filters. For example the AppSessionServiceImpl can provide the
SessionService with a property such as app=true. Then it would bind to
SessionService with a target filter of (!(app=*)).

Neil

On Fri, Aug 3, 2018 at 1:17 PM, Alain Picard via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Facing an issue and looking for the right pattern to apply where I have a
> service interface that is extended and at run time I want to always run the
> most appropriate one. Each extension provides additional method to the API.
>
> As an example (posted here: https://github.com/castortech/
> osgi-test-session), there's a CoreSessionService ifc (no direct
> implementation) that will be used by core part of the code. There is an
> extension to it (SessionService ifc) that adds some new methods and can be
> used by common level modules and then we have the AppSessionService that is
> app specific and can exist for some apps and not for other, which would
> then rely on the SessionServiceImpl.
>
> My issue is that for example the AppSessionServiceImpl needs a reference
> to the SessionService and this either creates a circular dependency (tried
> to use the Top/Bottom approach in the seminal Concurrency paper from
> enRoute) but that is not working so far.
>
> Any hints on how to proceed here.
>
> Thanks
> Alain
>
> ___
> 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

Re: [osgi-dev] Service Composition

[Neil Bartlett via osgi-dev]

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
instance of a service type. In fact you have to make a special effort in
each consumer to do this.

2) In general as a Java programmer (i.e. not just when using OSGi), prefer
composition over inheritance. DS clearly prefers this as well: it is very
easy to create a component that consumes others components as services, and
then combines and augments their functionality, whereas it is hard to
create a component that extends another component with inheritance, because
the the componenty nature is not inherited by default.

3) Notwithstanding point (2), you can actually make the @Reference
annotation inherited by adding the bnd instruction "-dsannotations-options:
inherit". You have to be cautious with this because, depending on how your
build path is setup, bnd might not always see the full type hierarchy of
your component. It's safe enough if you only inherit components within a
single bundle. You should never inherit types (other than interfaces and
100% abstract classes) across bundles anyway. If you do use this
inheritance then I recommend using method injection rather than field
injection, because then the subclass can choose to override the bind or
unbind methods.

Neil



On Wed, Jul 11, 2018 at 12:26 PM, Alain Picard via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

>
> Converting existing code to DS in an EMF environment where we have models
> starting with core and being extended at different levels by different
> applications, and those providing various type of "features". Trying to
> determine the best approach that allows for specialization, inheritance of
> injected service, including specialization, etc.
>
> I now have a small test bed that works as expected, but looking to apply
> best practices.
>
> Let's say I start with this service:
> @Component(service=ICoreUtils.class)
> public class CoreUtils implements ICoreUtils {
>   protected ISay another;
>
>   @Reference(
> policy=ReferencePolicy.STATIC,
> policyOption=ReferencePolicyOption.GREEDY
>   )
>   protected void setAnother(ISay another) {
> this.another = another;
>   }
>
> And now I can have an extension like so:
> @Component(
>   property="service.ranking:Integer=10",
>   service= { IExtUtils.class, ICoreUtils.class }
> )
> public class ExtUtils extends CoreUtils implements IExtUtils {
>   @Reference(
> policy=ReferencePolicy.STATIC,
> policyOption=ReferencePolicyOption.GREEDY
>   )
>   protected void setAnother(ISayMore another) {
> this.another = another;
>   }
>
> Since @Reference are not inherited, so far I have found that using a field
> reference at each level with a protected field holding the value seems to
> be the way to go. Also the extended service registers all interfaces it
> implements. The referenced service as shown here can also be provided in
> the same way, either providing an extended interface or just a different
> implementation that is more specific.
>
> Thanks
> Alain
>
> ___
> 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

Re: [osgi-dev] Service ranking usage

[Neil Bartlett via osgi-dev]

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 realize is that
> this doesn't trigger a new call to the @Activate method. I changed the
> reference to use a bind/unbind method pair and a sysout in there shows
> exactly the pattern that you described.
>
> Thanks
> Alain
>
>
> On Tue, Jul 10, 2018 at 5:13 PM Neil Bartlett 
> wrote:
>
>> 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 you will get.
>>
>> If you uncomment the dynamic+greedy setting in Example I expect you will
>> see the component briefly bind to the lower ranked service and then re-bind
>> to the higher ranked service. This is part of the definition of greedy.
>>
>> Neil
>>
>> On Tue, 10 Jul 2018 at 22:05, Alain Picard via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> As part of DS enabling a lot of our code, I am testing how to compose
>>> services after finding out that reference annotations are not inherited.
>>> But I am facing a much more basic issue dealing with service ranking.
>>>
>>> Made a trivial example of an interface with one  method and 2
>>> implementation and with one having a higher service ranking. I always get
>>> the same one to execute and not the one I expect (only get the other if I
>>> comment the @Component reference on CoreUtils and then it refreshes with
>>> ExtUtils.
>>>
>>> What is wrong with my approach.
>>> [image: image.png]
>>>
>>> ___
>>> 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

Re: [osgi-dev] Service ranking usage

[Neil Bartlett via osgi-dev]

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 you will get.

If you uncomment the dynamic+greedy setting in Example I expect you will
see the component briefly bind to the lower ranked service and then re-bind
to the higher ranked service. This is part of the definition of greedy.

Neil

On Tue, 10 Jul 2018 at 22:05, Alain Picard via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> As part of DS enabling a lot of our code, I am testing how to compose
> services after finding out that reference annotations are not inherited.
> But I am facing a much more basic issue dealing with service ranking.
>
> Made a trivial example of an interface with one  method and 2
> implementation and with one having a higher service ranking. I always get
> the same one to execute and not the one I expect (only get the other if I
> comment the @Component reference on CoreUtils and then it refreshes with
> ExtUtils.
>
> What is wrong with my approach.
> [image: image.png]
>
> ___
> 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

Re: [osgi-dev] OSGi Specification Question

[Neil Bartlett via osgi-dev]

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 question, but I am preparing my slides for the Java Forum
> Stuttgart about Remote Services, and remembered that Tim told me that my
> diagrams are incorrect, as the triangle is directing into the wrong
> direction.
>
>
>
> The big end should be on the producer side, while the cone end points to
> the consumer bundle.
>
> https://enrouteclassic.github.io/doc/215-sos.html
>
> https://jaxenter.de/osgi-enroute-1-0-hintergruende-
> architektur-best-practices-39709
>
>
>
> The architecture picture in the Remote Services chapter show the triangles
> differently.
>
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html
>
>
>
> Where is my misunderstanding? Is the picture incorrect, or does the
> picture show something different?
>
>
>
> Mit freundlichen Grüßen / Best regards
>
>
> *Dirk Fauth *
> Automotive Service Solutions, ESI application (AA-AS/EIS2-EU)
> Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY |
> www.bosch.com
> Tel. +49 7153 666-1155 | dirk.fa...@de.bosch.com
>
> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar
> Denner,
> Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung,
> Dr. Markus Heyn, Dr. Dirk Hoheisel,
> Christoph Kübel, Uwe Raschke, Peter Tyroller
>
>
>
> ___
> 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

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

[Neil Bartlett via osgi-dev]

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 R7 spec
and was adopted into the spec, making it possible to substantially slim
down enRoute itself. However R7 is not fully released yet (some bits of
Enterprise are still in progress) so we are in an awkward transition phase.


>
> Or enroute1 and enRoute2?
>

This would be confusing since "Classic enRoute" had a version 2 :-)


>
> Or is there a formal naming?
>

The name of the project is formally just enRoute.


>
> Paul Fraser
>
> ___
> 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

Re: [osgi-dev] Regarding service injection

[Neil Bartlett via osgi-dev]

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 the service registry the instance
> may already exist, or it may only exist as a result of you getting the
> service. You can also have services registered with prototype scope,
> meaning that new instances are created each time you request one.
>
> If you’re using Declarative Services then the most likely scenario is that
> the service is registered before it is injected and activated. This is
> because DS components are lazy by default.
>
> Regards,
>
> Tim
>
> On 26 Apr 2018, at 16:23, Leschke, Scott via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> Question.  When a service is created and activated, at what point is it
> available for lookup via the service registry, before or after the service
> is injected into services depending on it? I could see arguments for either?
>
> To clarify, if a service is created programmatically, and the new service
> is then retrieved from the registry, has any injection of the service
> already occurred at that point or the more likely scenario I think, you
> don’t really know?
>
> Regards,
>
> Scott
> ___
> 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
>

Actually unless I have misinterpreted the question, I think the answer is
"always before".

The exact question was: "at what point is it [a service] available for
lookup via the service registry, before or after the service is injected
into services depending on it?". The service HAS to be available for lookup
before it can be injected into anything. Before the service is published to
the service registry, no other bundle knows that the service exists so they
have nothing that they can possibly inject.

Tim: I believe you have answered a slightly different question about
injections of dependencies into a DS component that is going to be
published. You have answered it correctly of course.

Scott: it would help if you clarified your question in more precise
language. Bear in mind that a service is not "created and activated", it is
only ever registered or unregistered. A Service is really only an entry in
the Service Registry, and it doesn't have to have a real object behind it,
which is the key to the lazy instantiation of some components in DS.

Regards,
Neil
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

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

[Neil Bartlett via osgi-dev]

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 value of the
field (in the Dictionary it passes to Configuration.update) to either a
String[] or a Collection. If it can't or won't do that, then I
think you have no choice but to change your component implementation to
accept a single string and parse it yourself.

Neil

On Wed, Apr 18, 2018 at 3:54 PM, Christian Schneider via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> We have a component that requires an array of strings. See the code below
> for the config declaration.
>
>
> public @interface Config {
>
>
> @AttributeDefinition(name = "Services list")
>
> String[] services_list();
>
>
> }
>
> This works if we set the config attribute to be an array. It does not seem
> to work though
> when I configure the config using a .cfg file in karaf.
>
> As far as I know there I can only use plain strings. So our list can be
> represented as Service1,Service2 but this is not automatically converted to
> an array.
>
> What is the best practice to work with this?
>
> I have seen a StringPlus class in aries rsa that takes care of this but it
> would be a manual processing. Is there some way that DS or config admin can
> do this for us transparently?
>
> Christian
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>
>
> ___
> 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

Re: [osgi-dev] Competing module systems

[Neil Bartlett via osgi-dev]

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 "open". Closing off a
> > bundle to ALL access, even reflectively, seems like an extreme measure
> that
> > would only be necessary in fairly unusual circumstances, so I believe
> that
> > JPMS has the default the wrong way around. It's useful to compare with
> Java
> > classes, which can be made final but are not final by default.
>
> I'm not sure if we're talking about the same thing. It also seems a
> little strange to hear that: For me one of the main attractions about
> OSGi is that I get to state what's visible to the outside world and
> what isn't. This gives me the freedom to change things without breaking
> consumers. For the sake of the discussion, we could assume that bundles
> in the new magic OSGi container are all open for reflective access (but
> that the non-exported parts are still inaccessible, as with JPMS
> modules).
>

It's definitely possible that we're talking about different things, but let
me explain myself a little more.

In OSGi today, private packages are not ordinarily visible to other
bundles. That means I cannot just write plain code that depends on a
private type and have OSGi load that type for me. However I can load
classes, including classes that exist in private packages, from any bundle
using Bundle.loadClass(). Actually if Java security is enabled then we can
restrict the permissions around that, which gets very close to the
isolation that JPMS offers, but apparently nobody ever uses Java security
so here we are...

This is the equivalent of an "open module" in JPMS parlance, and I argue
that it is the better default. It makes bundles accessible to frameworks
such as dependency injectors, marshallers, ORM mappers, etc. I still have
the freedom to change my internals though: by not exporting a package I
have given a clear indication to other developers that the package is
private. If they go ahead and use reflection to work around the visibility
protections, then they cannot call foul when I change my internals and
break them. Therefore I believe that the strong isolation offered by
"closed" modules in JPMS is only needed for security-critical code.


>
> Mainly what I'm referring to is that I'd want the VM to believe that
> any assumptions that it can make about a JPMS module, for optimization
> purposes, it could also make those same assumptions about a bundle in
> our container. The same goes for assumptions that javac can make (but
> this is less interesting because it's easy to make something that's
> both an OSGi bundle and a JPMS module at compile time).
>

Yes I agree that's an additional benefit, but I'm not clear on what those
optimizations might be.



>
> There was a recent thread on the amber-experts list, for example, that
> talked about modifying the exhaustiveness check for switches over enum
> values based on whether the enum type is the same module as the switch
> or not. I got the feeling that this idea was rejected, but the
> point is that there's this looming possibility that language features
> will depend on module boundaries sooner or later, and so we should
> probably want to allow OSGi bundles to be treated as equals to JPMS
> modules, and for the VM and JIT to see them as the same thing.
>

That's an interesting use case, but surely it would only be useful where an
enum is private to a module? If it's exported then you cannot check switch
statements in modules that haven't been written yet. And if it's private to
the module/bundle then we can check all switch statements using existing
tools.

Java language features already do depend on the concept of accessibility:
e.g. the compiler can optimize access to a private field because it knows
all the places where the field is used, and potentially remove a redundant
volatile modifier or synchronization block. JPMS creates a new level of
accessibility applied to public types. I believe that any techniques the
compiler applies based on module membership could also be used when the
compiler can call my proposed checkAccess method... SO LONG AS the same
checkAccess is used at both compile and runtime. Admittedly this
complicates matters, and might require putting information into the module
metadata about the compile time checks that were used.

However I think that compile-time optimizations that depend on module
boundaries are a long way in the future, if they ever come. As long as the
module system is optional, you will be able to take a module and put it on
the classpath, invalidating all the assumptions the compiler made about
accessibility.


>
> > >
> > > Let's assume that, for the perspective of someone using this magic new
> > > OSGi container, the goal is to have it behave pretty much like an OSGi

Re: [osgi-dev] Competing module systems

[Neil Bartlett via osgi-dev]

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 brain storming...
>
> Let's assume hypothetically that the goal now is to produce an OSGi
> container that can use (possibly nonexistent) APIs in the JPMS to get
> the same degree of VM-enforced separation between OSGi bundles as JPMS
> modules get between each other (I'm aware that OSGi bundles get cleaner
> separation today than JPMS modules in some regards). Let's assume that
> we want to do this simply because we don't want to be left out in the
> cold when it comes to future language and VM features that might be
> module-dependent.
>

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 "open". Closing off a
bundle to ALL access, even reflectively, seems like an extreme measure that
would only be necessary in fairly unusual circumstances, so I believe that
JPMS has the default the wrong way around. It's useful to compare with Java
classes, which can be made final but are not final by default.


>
> Let's assume that, for the perspective of someone using this magic new
> OSGi container, the goal is to have it behave pretty much like an OSGi
> container already behaves (modulo the R7 java.* changes): An OSGi
> bundle can only depend on OSGi bundles,


Note quite true. OSGi bundles depend on capabilities, the most important of
which are Java packages. The Framework arranges to wire my Import-Package
to a suitable provider and creates a ClassLoader that delegates across the
wire, but my bundle shouldn't care what kind of thing it is wired to. It
would be quite simple to represent JPMS modules in OSGi as a kind of
virtual bundle (at least, modules that don't export in the java.*
namespace).



> and if you want to be able to
> talk to external system JPMS modules, you have to do it via the
> system/framework bundle. Let's also assume that we're not interested in
> having JPMS modules outside of the OSGi container be capable of
> depending on OSGi bundles running inside the container. This is similar
> to the situation today; it's not too easy (or desirable) to have things
> on the classpath depend on things running inside the OSGi container.
>
> Let's also assume that the magic new OSGi container needs the same
> capabilities that existing OSGi containers already have: Module
> loading/unloading, multiple bundle versions without conflicts, etc, etc.
>

Yup.


>
> I'm not sure, for the sake of discussion, whether or not the OSGi
> bundles in question happen to contain JPMS metadata already (such that
> if you took the OSGi bundle and put it on the module path, it'd behave
> correctly as a JPMS module).
>
> This magic new OSGi container would be much like the JPMS analogue of
> the existing classpath-based OSGi world: You have the classpath, and
> you have the OSGi container, and dependencies from one to the other
> have to occur through well-defined portals (the system/framework
> bundle).
>
> What additions to the JPMS APIs would be needed to make this a reality
> today?
>

I think the starting point is as simple as a callback interface along these
lines:

 void checkAccess(Class from, Class to) throws IllegalAccessException;

The JVM would call this each time it needs to check whether "from" is
allowed to access "to". It would be able to cache the answer because when
an OSGi bundle is updated we get a new ClassLoader and a new Class
identity. The JVM would also have some built-in checks before invoking this
method, to allow it to lock out the application layer from JVM internals.

The above should work at runtime for both OSGi and JPMS. To implement
compile-time checks you need something else to stand in for the identities
or locations of the two input types.



>
> --
> Mark Raynsford | http://www.io7m.com
>
>
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Competing module systems

[Neil Bartlett via osgi-dev]

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 JPMS. I do think that
> it's just barely the minimum viable product, though.
>
> The JVM really did need a module system, both for the maintenance of
> the JDK itself and the future features that the system enables.
>
> > Oracle’s strategy is a mystery to me.
>
> I think their strategy is fairly explicable, but I think they did make
> some mistakes with some of the specifics (filename-based automodules!).
> There's a pattern that Oracle tend to follow: They solicit opinions from
> everyone vigorously, and then they implement the smallest possible
> subset such that the fewest possible people are pissed off by it. If
> there's a possibility of doing something wrong, nothing is done
> instead.


While I've seen that principle operate at other times (remember how
controversial erasure was in Java 5?), I'm not sure it's worked that way in
the JPMS case. In fact JPMS does far more than it needed to.

The key feature of JPMS that could not be achieved before, even with
ClassLoaders, was strictly enforced isolation via the accessibility
mechanism, as opposed to the visibility mechanism that is employed by OSGi.
That strict isolation was needed primarily to allow Oracle to close off JVM
internals from application code and thereby prevent a whole class of
security vulnerabilities. Remember that Oracle was being absolutely
slaughtered in the press around 2011-12 over the insecurity of Java, and
most corporates uninstalled it from user desktops.

But they could have achieved this with a thin API, comparable to
ProtectionDomain. If they had done that then OSGi (and other module systems
like JBoss) could have chosen to leverage the API to enforce strict
separation between OSGi bundles.

But they didn't do that. Instead they implemented a whole new, incompatible
module system with its own metadata format, including changes to the Java
language spec. Then they restricted the ability to apply strict isolation
to artifacts that are JPMS modules. With the thin API they could have still
built their own module system on top, following their own ideas of how
modules should work, and competed with OSGi on a fairer playing field.



> Being incomplete and "too strict" is considered preferable to
> any kind of maintenance burden or making a mistake that people then
> come to depend upon. Then, after a version of something is released,
> the dust settles and the people that are still complaining after a year
> or so of implementation are asked for comments again. The process
> repeats! You can see this going on with quite a few of their projects.
> A good example of this with the JPMS is that there was a vigorous
> insistence that the module graph be a DAG. Now, some way into the first
> year, it's going to be allowed to be cyclic but only at run-time. I
> think the process does eventually produce results, but it takes a long
> time to get there and demands a lot of patience from the people
> involved. Most VM features seem to start off utterly spartan and then
> grow to support the use-cases that people wish they'd supported right
> from the start.
>
> Java in particular has awful press, and a userbase that seems to become
> incomprehensibly enraged over all good news and all bad news
> indiscriminately, so that doesn't help the perception of the process
> (or the results).
>
> I think the key will be to continue complaining for as long as it takes
> to get better interop between OSGi and the JPMS. :)
>

Interop already works just fine in one direction: OSGi bundles depending on
JPMS modules, with a combination of the changes in R7 to export java.*
packages from the system bundle and some creative use of
Provide/Require-Capability. But bidirectional interop will likely always be
impossible or very hard, because JPMS modules are only allowed to depend on
JPMS modules. This was clearly a deliberate strategy to tilt the table
towards JPMS, but it may be backfiring since -- as you've pointed out --
applications can only migrate to modules when all of their dependencies are
modules, including third party libraries, and the migration of libraries
has been exceedingly slow.

Neil


>
> --
> Mark Raynsford | http://www.io7m.com
>
>
> ___
> 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

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

[Neil Bartlett via osgi-dev]

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 know, Felix SCR is the RI for DS 1.4 so it will need to be
available by the time R7 is released.

Neil

On Mon, Apr 9, 2018 at 12:42 PM, Fauth Dirk (AA-AS/EIS2-EU) <
dirk.fa...@de.bosch.com> wrote:

> Thanks for the pointer Neil. No I haven’t seen that section yet.
>
>
>
> Just for clarification. That is introduced with DS 1.4 right? But as of
> now there is no default implementation for DS 1.4. At least I do not see a
> new Apache Felix SCR version for DS 1.4. And with DS 1.3 that automatic
> mapping from LoggerFactory to Logger or FormattedLogger would not work. At
> least in PDE I get a compile error because field type and service property
> do not match. And at runtime of course a NPE comes up, not sure if this is
> caused by PDE because of an incorrect component XML (although it looks
> correct for me) or if it is because it does not work with DS 1.3.
>
>
>
> Since I looked for a solution for the Eclipse Platform I haven’t tested
> Bndtools yet, but without a DS 1.4 implementation I suppose my tests will
> fail.
>
>
>
> Mit freundlichen Grüßen / Best regards
>
>
> *Dirk Fauth *
> Automotive Service Solutions, ESI application (AA-AS/EIS2-EU)
> Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY |
> www.bosch.com
> Tel. +49 7153 666-1155 | dirk.fa...@de.bosch.com
>
> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar
> Denner,
> Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung,
> Dr. Markus Heyn, Dr. Dirk Hoheisel,
> Christoph Kübel, Uwe Raschke, Peter Tyroller
>
>
> *Von:* Neil Bartlett [mailto:njbartl...@gmail.com]
> *Gesendet:* Montag, 9. April 2018 13:03
> *An:* Fauth Dirk (AA-AS/EIS2-EU) ; OSGi
> Developer Mail List 
> *Betreff:* 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
> in a component.
>
> Regards,
>
> Neil
>
>
>
> On Mon, Apr 9, 2018 at 11:56 AM, Fauth Dirk (AA-AS/EIS2-EU) via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> Hi,
>
>
>
> as with R7 the LogService is deprecated and instead the LoggerFactory
> should be used, I wanted to start integrating the LoggerFactory in the
> Eclipse Platform. But there is not much information about how the usage
> should be.
>
>
>
> From what I understand so far, the idea is similar to SLF4J that a Logger
> instance is created via LoggerFactory. The Logger provides API for logging
> similar to SLF4J, even with placeholder parameters and exception logging (I
> like that pretty much).
>
>
>
> But there is one thing I am not sure if I understand everything correctly.
> With SLF4J the LoggerFactory is static and the best practice is to create
> one Logger instance per class by using the LoggerFactory on a static field.
> This is done to reduce the needed amount of memory for cases where a lot of
> instances are created of a type. With OSGi R7 the LoggerFactory is a
> service and not a static helper class. So for DS I need to specify a
> reference. But actually I don’t want the LoggerFactory, I want a Logger.
> And I don’t want to create a Logger instance per log statement. I therefore
> thought of the following pattern for getting an OSGi Logger in my component:
>
>
>
> @Component
>
> *public* *class* StringInverterImpl *implements* StringInverter {
>
>
>
>*private* Logger logger;
>
>
>
>@Override
>
>*public* String invert(String input) {
>
>  logger.info("received {} to invert", input);
>
>  *return* *new* StringBuilder(input).reverse().toString();
>
>}
>
>
>
>@Reference
>
>*void* setLoggerFactory(LoggerFactory factory) {
>
>  *this*.logger = factory.getLogger(getClass());
>
>}
>
> }
>
>
>
> So I have a mandatory reference to LoggerFactory, and once the reference
> is set, I use it to get the Logger instance. Since the reference is static
> and mandatory I don’t need to take care if the LoggerFactory comes and goes
> at runtime. And as the service instance typically only exists once, there
> is also no memory overhead with this. For multi-instance components created
> by a factory, this could even have the advantage to create a Logger with a
> name that corresponds to the instance. Which would in turn make the log
> outputs more speaking in terms of knowing which component instance 

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

[Neil Bartlett via osgi-dev]

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
in a component.

Regards,
Neil

On Mon, Apr 9, 2018 at 11:56 AM, Fauth Dirk (AA-AS/EIS2-EU) via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi,
>
>
>
> as with R7 the LogService is deprecated and instead the LoggerFactory
> should be used, I wanted to start integrating the LoggerFactory in the
> Eclipse Platform. But there is not much information about how the usage
> should be.
>
>
>
> From what I understand so far, the idea is similar to SLF4J that a Logger
> instance is created via LoggerFactory. The Logger provides API for logging
> similar to SLF4J, even with placeholder parameters and exception logging (I
> like that pretty much).
>
>
>
> But there is one thing I am not sure if I understand everything correctly.
> With SLF4J the LoggerFactory is static and the best practice is to create
> one Logger instance per class by using the LoggerFactory on a static field.
> This is done to reduce the needed amount of memory for cases where a lot of
> instances are created of a type. With OSGi R7 the LoggerFactory is a
> service and not a static helper class. So for DS I need to specify a
> reference. But actually I don’t want the LoggerFactory, I want a Logger.
> And I don’t want to create a Logger instance per log statement. I therefore
> thought of the following pattern for getting an OSGi Logger in my component:
>
>
>
> @Component
>
> *public* *class* StringInverterImpl *implements* StringInverter {
>
>
>
>*private* Logger logger;
>
>
>
>@Override
>
>*public* String invert(String input) {
>
>  logger.info("received {} to invert", input);
>
>  *return* *new* StringBuilder(input).reverse().toString();
>
>}
>
>
>
>@Reference
>
>*void* setLoggerFactory(LoggerFactory factory) {
>
>  *this*.logger = factory.getLogger(getClass());
>
>}
>
> }
>
>
>
> So I have a mandatory reference to LoggerFactory, and once the reference
> is set, I use it to get the Logger instance. Since the reference is static
> and mandatory I don’t need to take care if the LoggerFactory comes and goes
> at runtime. And as the service instance typically only exists once, there
> is also no memory overhead with this. For multi-instance components created
> by a factory, this could even have the advantage to create a Logger with a
> name that corresponds to the instance. Which would in turn make the log
> outputs more speaking in terms of knowing which component instance created
> the log output.
>
>
>
> Would this be the recommended way of using logging in R7? Are my
> observations correct or do I misunderstand something?
>
>
>
> I would be happy to even write a small blog post about that topic if
> nobody else is currently writing something with regards to logging in R7.
>
>
>
> Mit freundlichen Grüßen / Best regards
>
>
> *Dirk Fauth *
> Automotive Service Solutions, ESI application (AA-AS/EIS2-EU)
> Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY |
> www.bosch.com
> Tel. +49 7153 666-1155 | dirk.fa...@de.bosch.com
>
> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar
> Denner,
> Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung,
> Dr. Markus Heyn, Dr. Dirk Hoheisel,
> Christoph Kübel, Uwe Raschke, Peter Tyroller
>
>
>
> ___
> 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

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

[Neil Bartlett via osgi-dev]

> 
> 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 specifications as final (ETA mid 
>> April). These jars do not have Automatic-Module-Name manifest entries in 
>> them. Just adding that is only a partial step. Unless you also test those 
>> jars in module-path mode, you have no idea how/if they will work. See 
>> http://blog.joda.org/2018/03/jpms-negative-benefits.html for some discussion 
>> of this. At this point, I don't see OSGi adding Automatic-Module-Name 
>> manifest entries to any of its artifacts since, of course, OSGi is making 
>> OSGi bundles and not JPMS modules :-)
>> --
> 
> That's a shame. It essentially means that it's not possible to write
> code that both uses/declares declarative services and that will also be
> usable as a JPMS module - unless you're willing to live with tools
> telling you not to publish your artifacts. I'm not: I'd become used to
> ignoring the problem due to OSGi dependencies and then would miss real
> warnings when they happen.

I have to agree with Mark here. Not having Automatic-Module-Name in the JAR 
files effectively makes them unusable to developers in the JPMS world since 
tools will either reject or strongly discourage (and perhaps eventually reject) 
these artifacts.

While it’s true we are in the business of making OSGi bundles and not JPMS 
modules, OSGi has long delivered artifacts that are usable without an OSGi 
Framework. The compile-only annotations for example, or the Promises library. 
We should always try to make it easy for people to ease into OSGi, rather than 
forcing them to adopt it all at once.

I agree that it would be impossible to do anything for R7. I hope we look at 
this for R8. In the meantime I expect that somebody will have to repackage the 
official artifacts to add an Automatic-Module-Name manifest header.

Neil


> 
> -- 
> Mark Raynsford | http://www.io7m.com
> 
> ___
> 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

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

[Neil Bartlett via osgi-dev]

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 ALL valid JAR files were also valid bundles.
However this was not very useful since a bundle that does not have any
imports, exports or activator would not be able to do anything.

Neil


On Mon, Feb 12, 2018 at 9:21 AM, Eran Twili via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi,
>
>
>
> We are implementing OSGi in our product (embedding Equinox
> programmatically).
>
> Designing our Bundles installation error handling, we run some tests.
>
> Surprisingly, we see that when we install a regular jar archive in the FW,
> it’s getting installed, resolved and even active, without any exception
> thrown.
>
> We also see that it has a regular bundle-id and that his 
> *bundle.getSymbolicName()
> *returns null
>
> (Aligns with https://wiki.searchtechnologies.com/
> javadoc/osgi/osgi-javadoc-v41/org/osgi/framework/Bundle.
> html#getSymbolicName() )
>
>
>
> This jar has a Manifest (I think generated by Maven) but it *doesn’t have
> any OSGi header* in it.
>
> This is the Manifest:
>
>
>
> *Manifest-Version: 1.0*
>
> *Built-By: noname*
>
> *Created-By: Apache Maven 3.2.5*
>
> *Build-Jdk: 1.8.0_92*
>
>
>
> *Name: Skeleton Rule*
>
> *Build-Time: 2018-01-31 10:49*
>
> *ArtifactId: skeleton*
>
> *Version: 5.9.2.2-SNAPSHOT*
>
> *GroupId: skel*
>
> We use org.eclipse.osgi version 3.11.2 (which implements R6)
>
> From what I see in the R6 core spec (section 3.12), the FW should throw an
> exception in such case, when installing the jar.
>
>
>
> 3.12 Bundle Validity
>
> ….
>
> The following (non-exhaustive) list of errors causes a bundle to fail to
> install:
>
> • Missing Bundle-SymbolicName.
>
>
>
> Can anyone please clarify what is the expected behavior?
>
>
>
> Regards,
>
> Eran
>
>
>
>
> Confidentiality: This communication and any attachments are intended for
> the above-named persons only and may be confidential and/or legally
> privileged. Any opinions expressed in this communication are not
> necessarily those of NICE Actimize. If this communication has come to you
> in error you must take no action based on it, nor must you copy or show it
> to anyone; please delete/destroy and inform the sender by e-mail
> immediately.
> Monitoring: NICE Actimize may monitor incoming and outgoing e-mails.
> Viruses: Although we have taken steps toward ensuring that this e-mail and
> attachments are free from any virus, we advise that in keeping with good
> computing practice the recipient should ensure they are actually virus free.
>
> ___
> 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

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

[Neil Bartlett via osgi-dev]

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

> Hi Neil,
>
> 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.
>
> That is what I thought. The activate methode doesn’t have the properties
> parameter though...
>
> public void activate() throws Exception {
>
> … and the component does have a modified() method, so I am not sure why
> the component needs to be deactivated. I expected the framework ‘just’ call
> modified() with a null properties map.
>
> Erwin
>
>
> This part is, so far, the same for both optional and required
> configuration.
>
> After the deactivation, a component with optional configuration is now
> allowed to re-activate with no configuration, i.e. using its own internal
> defaults. A required-configuration component would NOT be allowed to
> reactivate until a new configuration record came along.
>
> So yes, this is the behaviour I would expect to see.
>
> Neil
>
>
> On Tue, Jan 23, 2018 at 12:16 PM, Erwin Hogeweg via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Hi,
>>
>> We noticed, in an equinox OSGi framework with felix scr and
>> felix.file-install, that a component’s deactivate() and activate() methods
>> are called when the component’s configuration file is removed.  Actually
>> the config file was updated but it looks like the file-install thread
>> caught it halfway in the replace process.
>>
>> Is it expected that the deactivate() and activate() methods are called
>> when an optional configuration is removed? I am trying to find something
>> about that in the OSGi specs, but so far w/o luck.
>>
>>
>> Regards,
>>
>> Erwin
>> ___
>> 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

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

[Neil Bartlett via osgi-dev]

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 deactivation, a component with optional configuration is now
allowed to re-activate with no configuration, i.e. using its own internal
defaults. A required-configuration component would NOT be allowed to
reactivate until a new configuration record came along.

So yes, this is the behaviour I would expect to see.

Neil


On Tue, Jan 23, 2018 at 12:16 PM, Erwin Hogeweg via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi,
>
> We noticed, in an equinox OSGi framework with felix scr and
> felix.file-install, that a component’s deactivate() and activate() methods
> are called when the component’s configuration file is removed.  Actually
> the config file was updated but it looks like the file-install thread
> caught it halfway in the replace process.
>
> Is it expected that the deactivate() and activate() methods are called
> when an optional configuration is removed? I am trying to find something
> about that in the OSGi specs, but so far w/o luck.
>
>
> Regards,
>
> Erwin
> ___
> 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

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

[Neil Bartlett via osgi-dev]

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, with only one method, which is referenced
in only one other component. For some reason though, the OSGi framework
decides that the component needs to be instantiated and registered twice. I
have put breakpoints in the constructor and in both cases the entire stack
is framework code.

If I add the immediate=true property to the component definition both
components are actually active, if I leave out the immediate=true one
component is active the other satisfied.

This is my simple component def.
@Component(name=“my.component",
configurationPolicy=ConfigurationPolicy.REQUIRE,
service=MyService.class)

src:list shows them both.
 [ 112]   my.component  enabled
[  31] [active  ] my.component
...
 [ 137]   my.component  enabled
[  32] [satisfied   ] my.component


We are using a std equinox/felix OSGi stack.
0 ACTIVE  org.eclipse.osgi_3.10.2.v20150203-1939
Fragments=5
1 ACTIVE  org.apache.felix.gogo.command_0.16.0
2 ACTIVE  org.apache.felix.gogo.runtime_0.16.2
3 ACTIVE  org.apache.felix.gogo.shell_0.12.0
4 ACTIVE  org.eclipse.equinox.console_1.0.100.v20130429-0953
5 RESOLVEDorg.eclipse.osgi.compatibility.state_1.0.100.v20150402-1551
Master=0
6 ACTIVE  org.ops4j.pax.logging.pax-logging-api_1.8.5
7 ACTIVE  org.ops4j.pax.logging.pax-logging-service_1.8.5
8 ACTIVE  org.apache.felix.eventadmin_1.4.6
9 ACTIVE  org.apache.felix.scr_2.0.8
10 ACTIVE  org.apache.felix.configadmin_1.8.14
11 ACTIVE  org.apache.felix.fileinstall_3.5.4
...

I am sure I am overlooking something, but at this moment I am lost. I’ll
keep plugging away, but any suggestions on why this component might be
created twice (and how to resolve) would be greatly appreciated.


Kind Regards,

Erwin

___
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

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

[Neil Bartlett via osgi-dev]

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 2017, at 23:55, Jesse Rao via osgi-dev  
> wrote:
> 
> Simple question about Apache Felix Web Console: Are any special steps 
> required to use it to view / manage DS components?
> 
> My application is using DS components and I can see that the 
> org.apache.felix.scr bundle is active. However, when I hit the URL 
> http://localhost:8080/system/console/components 
>  I get a 404 and am 
> redirected to http://localhost:8080/system/console/bundles 
> .
> 
> The felix web console docs here 
> 
>  say "If your framework uses the Apache Felix Declarative Services 
> implementation, you can use to the Web Console to inspect the declared 
> components available from the various bundles and managed by the Service 
> Component Runtime."
> 
> -- 
> Jesse Rao
> Software Engineer
> Liferay, Inc.
> Visit Us: www.liferay.com   |  Like Us: 
> www.facebook.com/liferay   |  Follow Us: 
> www.twitter.com/liferay  | Share Us: 
> www.instagram.com/liferayinc 
> ___
> 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