Hi,Dirk, I agree with you. I also don't like the Optionals especially in that context.They would just add the functionality for a dynamic 0..1 service in case it appears.As mentioned before, removing or modifications of services cannot be applied using this style without needing a new Optional instance. On the other hand I understand and share the need for a fluent handling of the dynamics in DS Components beside the callback methods.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: "Fauth Dirk (CAP-SST/ESM1) via osgi-dev" <osgi-dev@mail.osgi.org> Datum: 23.09.20 09:06 (GMT+01:00) An: OSGi Developer Mail List <osgi-dev@mail.osgi.org> Betreff: Re: [osgi-dev] SCR: ServiceInjection into Fields that are Optional<Service>
Hm, Maybe it is just me who doesn’t like the Optional concept in Java the way it is. 😊 In collections it is fine from my point of view, for fields it is totally unnecessary as it doesn’t provide additional functionality nor does it provide better readable code or lesser bloat. But ok, that is only my personal opinion and I’m sorry for interrupting. Mit freundlichen Grüßen / Best regards Dirk Fauth Cross Automotive Platforms - Systems, Software and Tools, (CAP-SST/ESM1) Robert Bosch GmbH | Postfach 30 02 40 | 70442 Stuttgart | 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. Michael Bolle, Dr. Christian Fischer, Dr. Stefan Hartung, Dr. Markus Heyn, Harald Kröger, Christoph Kübel, Rolf Najork, Uwe Raschke, Peter Tyroller Von: osgi-dev-boun...@mail.osgi.org <osgi-dev-boun...@mail.osgi.org> Im Auftrag von Jürgen Albert via osgi-dev Gesendet: Mittwoch, 23. September 2020 08:56 An: osgi-dev@mail.osgi.org Betreff: Re: [osgi-dev] SCR: ServiceInjection into Fields that are Optional<Service> Hi, The Idea of Stefan is not that far off, as CDI already has something similar. This would not really a complete new feature, but a more convenient way of declaring a reference as a field or constructor injection. If I'm not mistaken @Reference private Optional<FooService> foo; should be equivilant to @Reference(cardinality = ReferenceCardinality.OPTIONAL) private FooService factory; In CDI this is described here: https://docs.osgi.org/specification/osgi.enterprise/7.0.0/service.cdi.html#service.cdi-reference.optional BTW: Marks idea is intriguing as well and would be a comfortable solution as well. Regards, Jürgen. Am 23/09/2020 um 07:31 schrieb Fauth Dirk (CAP-SST/ESM1) via osgi-dev: Hi, I think the usage of a Java Optional is not correct here. I don’t understand why it should be better to have an Optional that needs to be checked for the empty state compared to a good old null check. IMHO Optionals in Java are good and necessary when thinking of collection processing, but for a field that references a single service I don’t see the benefit. And I am not aware of such support in OSGi DS. Even your example with the bind method will not work, because the bind method is never invoked if no such service is available and therefore set. So if no service is set your Optional will be null and you are in the same situation as without the Optional. And in the dynamic case of unbinding an existing service, the unbind method is missing to recreate the empty Optional. Mit freundlichen Grüßen / Best regards Dirk Fauth Cross Automotive Platforms - Systems, Software and Tools, (CAP-SST/ESM1) Robert Bosch GmbH | Postfach 30 02 40 | 70442 Stuttgart | 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. Michael Bolle, Dr. Christian Fischer, Dr. Stefan Hartung, Dr. Markus Heyn, Harald Kröger, Christoph Kübel, Rolf Najork, Uwe Raschke, Peter Tyroller Von: osgi-dev-boun...@mail.osgi.org <osgi-dev-boun...@mail.osgi.org> Im Auftrag von Mark Hoffmann via osgi-dev Gesendet: Mittwoch, 23. September 2020 06:35 An: Stefan Bischof <stbisc...@bipolis.org>; OSGi Developer Mail List <osgi-dev@mail.osgi.org> Betreff: Re: [osgi-dev] SCR: ServiceInjection into Fields that are Optional<Service> 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. In addition to that you don't have callbacks where to get notified about adding, modifying or removing a service. 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? 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 -- Jürgen Albert Geschäftsführer Data In Motion Consulting GmbH Kahlaische Str. 4 07745 Jena Mobil: 0157-72521634 E-Mail: j.alb...@datainmotion.de Web: www.datainmotion.de XING: https://www.xing.com/profile/Juergen_Albert5 Rechtliches Jena HBR 513025
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
