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 0
Mobile: +49 175 701 2201 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
<njbartl...@gmail.com> Datum: 23.09.20 16:01 (GMT+01:00) An: Mark Hoffmann
<m.hoffm...@data-in-motion.biz> Cc: OSGi Developer Mail List
<osgi-dev@mail.osgi.org> Betreff: Re: [osgi-dev] SCR: ServiceInjection into
Fields that are Optional<Service> 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<S> { void ifPresent(Consumer<? super S>); //
from Optional Stream<S> stream(); // from Optional Promise<S>
whenResolved(); Promise<Void> whenUnresolved(); }SCR could inject an
instance of this interface into a component (component authors would not be
able to instantiate their own instance).It's an interesting idea, but I believe
it would be better to keep it as a separate requirement from the "support
Optional-typed field injection" requirement.Neil On Wed, 23 Sep 2020 at
14:24, Mark Hoffmann <m.hoffm...@data-in-motion.biz> wrote:
Hi Neil,thus is why I said something like a Promise. I think in my first post
this morning I mentioned e.g. the missing unresolve or reresolve.On the other
side, if we had such an special Object, we could also bring the feature of
callbacks back to field injection.Just to get you right, I am not against the
idea, I just wanted to get a step further !? 🙂Mark Hoffmann M.A.
Dipl.-Betriebswirt (FH) CEO/CTO Phone: +49 3641 384 910 0 Mobile: +49 175
701 2201 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 <njbartl...@gmail.com> Datum: 23.09.20 13:14 (GMT+01:00) An:
Mark Hoffmann <m.hoffm...@data-in-motion.biz> Cc: OSGi Developer Mail List
<osgi-dev@mail.osgi.org> Betreff: Re: [osgi-dev] SCR: ServiceInjection into
Fields that are Optional<Service> Can you clarify how you would expect a
Promise to work?It sounds a bit like forcing dynamic behaviour into a static
reference, i.e. you get a static field of type Promise which may later resolve
to the bound service. But this disconnects the lifecycle of the component from
the availability of the service. The problem is that the service can change
state many times between available and unavailable, whereas a Promise only ever
has a single state change (from unresolved to resolved). That is, a Promise
cannot revert from resolved to unresolved.It seems to me that we already have a
mechanism for tracking the dynamic state of a service with callbacks, and that
is method injection. The bind and unbind methods can be called as many times as
necessary. I don't see how Promises make this any cleaner.The idea of
explicitly supporting Optional fields does not have any lifecycle implications
for the component. We simply change the representation of "unbound" from null
to Optional.empty() and eliminate a whole class of potential NPE-throwing code
patterns.NeilOn Wed, 23 Sep 2020 at 12:01, Mark Hoffmann
<m.hoffm...@data-in-motion.biz> wrote:
Hi,Neill I see the point. As already mentioned I would rather see something
like Promise instead fd an Optional, where I could stay with one instance.In
addition to that I would get onResolve out-of-the-box.Regards,Mark Hoffmann
M.A. Dipl.-Betriebswirt (FH) CEO/CTO Phone: +49 3641 384 910 0 Mobile: +49
175 701 2201 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 <njbartl...@gmail.com> Datum: 23.09.20 11:50 (GMT+01:00) An:
Mark Hoffmann <m.hoffm...@data-in-motion.biz>, OSGi Developer Mail List
<osgi-dev@mail.osgi.org> Betreff: Re: [osgi-dev] SCR: ServiceInjection into
Fields that are Optional<Service> 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<Foo> are safe however: optFoo.ifPresent(Foo::doSomething)or:
Stream<String> 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 0
Mobile: +49 175 701 2201 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 <osgi-dev@mail.osgi.org> 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<Service>
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<Foo> 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<Foo> 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
