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

2020-09-28 Thread Mark Hoffmann via osgi-dev 

Hi, I mentioned an object type like a Promise that wouldi be capable to 
"unresolve" or "modifications". Some object that doesn't needs to be replaced, 
when there are dynamic changes. Something that can make our add, rem, mod 
callbacks available for field injectionLike getting the ServiceTracker 
injected, but with a nice, fluent, Promis-style API RegardsMark 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: BJ Hargrave via osgi-dev 
 Datum: 28.09.20  17:41  (GMT+01:00) An: 
osgi-dev@mail.osgi.org Betreff: Re: [osgi-dev] SCR: ServiceInjection into 
Fields that are   Optional 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 HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi 
Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 
3788hargr...@us.ibm.com
 
 
- Original message -From: Mark Hoffmann via osgi-dev 
Sent by: osgi-dev-boun...@mail.osgi.orgTo: Neil 
Bartlett Cc: OSGi Developer Mail List 
Subject: [EXTERNAL] Re: [osgi-dev] SCR: 
ServiceInjection into Fields that are OptionalDate: 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 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 
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 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

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

2020-09-23 Thread Mark Hoffmann via osgi-dev 

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 
 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 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  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  Datum: 23.09.20  13:14  (GMT+01:00) An: 
Mark Hoffmann  Cc: OSGi Developer Mail List 
 Betreff: Re: [osgi-dev] SCR: ServiceInjection into 
Fields that are Optional 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 
 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  Datum: 23.09.20  11:50  (GMT+01:00) An: 
Mark Hoffmann , OSGi Developer Mail List 
 Betreff: Re: [osgi-dev] SCR: ServiceInjection into 
Fields that are Optional I like Stefan's suggestion and I disagree 
with some specific points made by Mark... responses line below.On Wed, 23 Sep 
2020 at 05:35, Mark Hoffmann via osgi-dev  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 
de

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

2020-09-23 Thread Mark Hoffmann via osgi-dev 

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 
 Datum: 23.09.20  13:14  (GMT+01:00) An: Mark Hoffmann 
 Cc: OSGi Developer Mail List 
 Betreff: Re: [osgi-dev] SCR: ServiceInjection into 
Fields that are Optional 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 
 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  Datum: 23.09.20  11:50  (GMT+01:00) An: 
Mark Hoffmann , OSGi Developer Mail List 
 Betreff: Re: [osgi-dev] SCR: ServiceInjection into 
Fields that are Optional I like Stefan's suggestion and I disagree 
with some specific points made by Mark... responses line below.On Wed, 23 Sep 
2020 at 05:35, Mark Hoffmann via osgi-dev  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

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

2020-09-23 Thread Mark Hoffmann via osgi-dev 

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 
 Datum: 23.09.20  11:50  (GMT+01:00) An: Mark Hoffmann 
, OSGi Developer Mail List 
 Betreff: Re: [osgi-dev] SCR: ServiceInjection into 
Fields that are Optional I like Stefan's suggestion and I disagree 
with some specific points made by Mark... responses line below.On Wed, 23 Sep 
2020 at 05:35, Mark Hoffmann via osgi-dev  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 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  Datum: 
22.09.20  15:48  (GMT+01:00) An: osgi-dev@mail.osgi.org Betreff: [osgi-dev] 
SCR: ServiceInjection into Fields that areOptional 
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://you

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

2020-09-23 Thread Mark Hoffmann via osgi-dev 

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"  Datum: 23.09.20  09:06  (GMT+01:00) An: OSGi 
Developer Mail List  Betreff: Re: [osgi-dev] SCR: 
ServiceInjection into Fields that are Optional 

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


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

Im Auftrag von Mark Hoffmann via osgi-dev
Gesendet: Mittwoch, 23. September 2020 06:35
An: Stefan Bischof ; OSGi Developer Mail List

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


 

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

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

2020-09-22 Thread Mark Hoffmann via osgi-dev 

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 
 Datum: 22.09.20  15:48  (GMT+01:00) An: 
osgi-dev@mail.osgi.org Betreff: [osgi-dev] SCR: ServiceInjection into Fields 
that areOptional 
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

Re: [osgi-dev] Intermittent failure to getService

2020-03-11 Thread Mark Hoffmann via osgi-dev 

Hi Alain,

Am 11.03.20 um 15:29 schrieb Alain Picard:

Mark,

Thanks for the info. Just as a side note we are using EMF with CDO 
here and I'll double check but I believe we have this correctly 
managed, but I'm aware of some CME issues that can sometimes happen, 
even in a normal RCP application when dealing with itemProviders for 
example.


Exact, that comes, when certain operations, like adding items are not 
done in the UIThread in the RCP. If loading of instance is done in a 
different thread, you have to use the pattern Display#syncExec for those 
operations.


The same applies to OSGi. CDO is also not thread safe, it just ships 
around such problems using transactional commands.


The general problem with the CME aare that especiall in DS it may be 
possible that you dont expect them in e.g. activate callbacks.


Mark



Cheers,
Alain


On Wed, Mar 11, 2020 at 10:18 AM Mark Hoffmann via osgi-dev 
mailto:osgi-dev@mail.osgi.org>> wrote:


Hi Alain,

a little bit late but maybe some side notes to EMF and OSGi. EMF
is not thread-safe. May it be possible that you share one
ResourceSet/Resource over many Prototype instances?

This is in general not a good idea. In case you use EMF with
Equinox, you should give each prototype instance an own
ResourceSet instance. Otherwise you will sooner or later run into
ConcurrentModificationException when adding/removing Resources
to/from a ResourceSet. In any case sharing a ResourceSet over
Prototype instance will also lead to memory leaking over the time,
if you do not remove/cleanup the Resources after using them.

Using EObjects in a detached state can be helpful, but is not
useful for some use-cases e.g. Validation / Compare, because you
have to attach the objects before doing something.

You can also take look at our GeckoEMF. We have ResourceSets as a
service, also as PROTOTYPE scoped. So you can get an own
ResourceSet instance injected. We also have a ResourceSetFactory,
that can create ResourceSets. This solves many problems using EMF
in pure OSGi. There is also a Thread-safe ResourceSet
implementation regarding the usage of Resources

https://gitlab.com/gecko.io/geckoEMF

Mark

Am 11.03.20 um 13:26 schrieb Alain Picard via osgi-dev:

Peter and Tim,

Thanks for the pointers. The error was caused by some invalid use
of a disposed object. This was using factory components and I
switched all of it to use prototype components instead which IMHO
are easier to manage.

And Peter to your question about using prototype scope, those
objects contain state and it is my understanding that prototype
scope is required in those cases.

Thanks
Alain


On Mon, Mar 2, 2020 at 9:39 AM Peter Kriens
mailto:peter.kri...@aqute.biz>> wrote:

Some remarks:

* Yes, it is thread safe. In OSGi we mark all thread safe
types with the @ThreadSafe annotation.
* The error message is not in the log you listed. Since the
log contains a deactivation message, I hope you're handling
the case corrected that you're being called after
deactivation? Seems too simple, but anyway ... :-)

* And for something completely different, is there any reason
you use the prototype scope? You real code might need it but
for this code it just looks like making it accidentally complex?
* And last but not least, you seem to be using slf4j? Did you
wire up the OSGi log to it? I've seen cases where the
information was in the OSGi log but those messages were
discarded.

Kind regards,

Peter Kriens



On 2 Mar 2020, at 12:03, Alain Picard via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

Question: The method getDiagnosticForEObject can be called
by different threads. Can this be the source of the issue? I
see that ComponentServiceObject is tagged as ThreadSafe, but?

Alain


On Mon, Mar 2, 2020 at 5:47 AM Alain Picard
mailto:pic...@castortech.com>> wrote:

Tim,

I don't think so. BaValidationManagerExt is used in only
1 place and it is instantiated in activate and released
in deactivate:
@Component(
factory = ValidationManager.CONFIG_FACTORY,
service = ValidationManager.class
)
public final class CoreValidationManager extends
CDODefaultTransactionHandler1 implements ValidationManager,
CDOTransactionHandler2 {
...
@Reference(scope=ReferenceScope.PROTOTYPE_REQUIRED)
private ComponentServiceObjects
extenderFactory;
private ValidationManagerExt extender;

@Activate
private void activate() {
log.trace("Activating {}", getClass()); /

Re: [osgi-dev] Intermittent failure to getService

2020-03-11 Thread Mark Hoffmann via osgi-dev 

Hi Alain,

a little bit late but maybe some side notes to EMF and OSGi. EMF is not 
thread-safe. May it be possible that you share one ResourceSet/Resource 
over many Prototype instances?


This is in general not a good idea. In case you use EMF with Equinox, 
you should give each prototype instance an own ResourceSet instance. 
Otherwise you will sooner or later run into 
ConcurrentModificationException when adding/removing Resources to/from a 
ResourceSet. In any case sharing a ResourceSet over Prototype instance 
will also lead to memory leaking over the time, if you do not 
remove/cleanup the Resources after using them.


Using EObjects in a detached state can be helpful, but is not useful for 
some use-cases e.g. Validation / Compare, because you have to attach the 
objects before doing something.


You can also take look at our GeckoEMF. We have ResourceSets as a 
service, also as PROTOTYPE scoped. So you can get an own ResourceSet 
instance injected. We also have a ResourceSetFactory, that can create 
ResourceSets. This solves many problems using EMF in pure OSGi. There is 
also a Thread-safe ResourceSet implementation regarding the usage of 
Resources


https://gitlab.com/gecko.io/geckoEMF

Mark

Am 11.03.20 um 13:26 schrieb Alain Picard via osgi-dev:

Peter and Tim,

Thanks for the pointers. The error was caused by some invalid use of a 
disposed object. This was using factory components and I switched all 
of it to use prototype components instead which IMHO are easier to manage.


And Peter to your question about using prototype scope, those objects 
contain state and it is my understanding that prototype scope is 
required in those cases.


Thanks
Alain


On Mon, Mar 2, 2020 at 9:39 AM Peter Kriens > wrote:


Some remarks:

* Yes, it is thread safe. In OSGi we mark all thread safe types
with the @ThreadSafe annotation.
* The error message is not in the log you listed. Since the log
contains a deactivation message, I hope you're handling the case
corrected that you're being called after deactivation? Seems too
simple, but anyway ... :-)

* And for something completely different, is there any reason you
use the prototype scope? You real code might need it but for this
code it just looks like making it accidentally complex?
* And last but not least, you seem to be using slf4j? Did you wire
up the OSGi log to it? I've seen cases where the information was
in the OSGi log but those messages were discarded.

Kind regards,

Peter Kriens



On 2 Mar 2020, at 12:03, Alain Picard via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

Question: The method getDiagnosticForEObject can be called by
different threads. Can this be the source of the issue? I see
that ComponentServiceObject is tagged as ThreadSafe, but?

Alain


On Mon, Mar 2, 2020 at 5:47 AM Alain Picard
mailto:pic...@castortech.com>> wrote:

Tim,

I don't think so. BaValidationManagerExt is used in only 1
place and it is instantiated in activate and released in
deactivate:
@Component(
factory = ValidationManager.CONFIG_FACTORY,
service = ValidationManager.class
)
public final class CoreValidationManager extends
CDODefaultTransactionHandler1 implements ValidationManager,
CDOTransactionHandler2 {
...
@Reference(scope=ReferenceScope.PROTOTYPE_REQUIRED)
private ComponentServiceObjects
extenderFactory;
private ValidationManagerExt extender;

@Activate
private void activate() {
log.trace("Activating {}", getClass()); //$NON-NLS-1$

extender = extenderFactory.getService();
}

@Deactivate
private void deactivate() {
log.trace("Deactivating {}", getClass()); //$NON-NLS-1$
extenderFactory.ungetService(extender);
}

Cheers,
Alain

Alain Picard
Chief Strategy Officer
Castor Technologies Inc
o:514-360-7208
m:813-787-3424

pic...@castortech.com 
www.castortech.com 


On Mon, Mar 2, 2020 at 3:40 AM Tim Ward mailto:tim.w...@paremus.com>> wrote:

Hi Alain,

Is it possible that someone has a reference to a
BaValidationManagerExt service instance that they aren’t
releasing after ungetting it (or that they’re holding
onto after it has been unregistered)? It might be an SCR
bug, but it’s more likely to be some code holding onto a
component instance that it shouldn’t.

Best Regards,

Tim


On 29 Feb 2020, at 13:29, Alain Picard via osgi-dev
mailto:osgi-dev@mail.osgi.org>>
wrote:

Hi

I am having a very intermittent issue with getService on

Re: [osgi-dev] JAX-RS Whiteboard Spec 1.0: Asynchronous Responses: SSE

2020-01-23 Thread Mark Hoffmann via osgi-dev 

Hi Markus,

at first the SseEventSink is auto-closable. It can also be closed from a 
client side


https://javaee.github.io/javaee-spec/javadocs/javax/ws/rs/sse/SseEventSink.html

So in the examples from chapter 9.3 the usage of the sink is put in an 
try-statement, which auto-closes auto-closables ;-).


https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

From that point the user has to close the connection. You are fine then 
using the catch clause to capture exceptions.



Regarding the "ContainerResponseFilter" thing, I would expect that the 
filter is called for the initial response. But I never tried that out. I 
only found that:


https://nomanabbasi.wordpress.com/2018/07/30/jersey-2-x-server-sent-event-with-angular-6/

Mark

Am 23.01.20 um 13:30 schrieb Markus Rathgeb:


Hi Marc,

thank you foryour response.

I checked the specification I found here:
https://download.oracle.com/otndocs/jcp/jaxrs-2_1-final-eval-spec/index.html

Please allow me to add two further questions here. I agree that it is
not really OSGi related, but I assume you can give me the answer. ;)

The chapter 9.5 "Processing Pipeline" contains:
"For compatibility purposes, implementations MUST initiate processing
of an SSE response when either thefirst message is sent or when the
resource method returns, whichever happens first."

Okay so far.

"The initial SSE response,which may only include the HTTP headers, is
processed using the standard JAX-RS pipeline as described in Appendix
C. Each subsequent SSE event may include a different payload and thus
require the use of aspecific message body writer. Note that since this
use case differs slightly from the normal JAX-RS pipeline,
implementations SHOULD NOT call entity interceptors on each individual
event (1)."

So, the initial(!) response is processed as described in Appendix C...
If my understanding of Appendix C is correct, the
"ContainerResponseFilter" should be called also for the initial
response.
So, my implementation of a "ContainerResponseFilter" that is provided
as an OSGi service and that works for other non-SSE endpoints should
be called to. And if this container response filter adds additional
headers, they should be present on the initial response.
Correct or not?

The chapter 9 (especially 9.3) does not contain any statement if the
SSE event sink is closed automatically if an exception is thrown.
So, to be on the safe side, the implementor is always responsible to
close the event think on all (also the error) branches.
Correct or not?

Best regards,
Markus


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

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

Re: [osgi-dev] JAX-RS Whiteboard Spec 1.0: Asynchronous Responses: SSE

2020-01-23 Thread Mark Hoffmann via osgi-dev 

Hi Markus,

the JaxRs API uses exactly this pattern of a @GET annotated resource 
with the corresponding @Produces annotation to provide SSE.


But this constellation doesn't follow the ordinary request-response 
behavior. The connection between the sender and receiver stays open. It 
is a typical publish and subscribe behavior. Whereas ordinary GET 
requests return a response or timeout after a certain time, these SSE 
connections stay open. So there is nothing to return. If the connection 
is lost, then there is also a reconnect support in the JaxRs SSE.


Please note, that the OSGi JaxRs Whiteboard specification does not 
change the behavior described in the JaxRs specification. It provides a 
way to deal with JaxRs in an OSGi way, to service-enable applications, 
resources and extensions.


So SSE should behave like described in chapter 9 of the JaxRs 2.1 
specification.


Regards,

Mark


Am 23.01.20 um 11:51 schrieb Markus Rathgeb via osgi-dev:

Hi,

I have a question about the Server Sent Events mechanism.
I migrated a few projects from Jersey to the Aries JAX-RS Whiteboard
implementation and there is now a question about the specification at
all.

There is an example in the specification that demonstrates the use of
Server Sent Events in the specification.
https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#d0e133342

Instead of a Response object this example returns "void".

There is a REST endpoint that is marked to  produce SSE.
First it checks some stuff.
On failure a response "not found" (or another one e.g. "bad request")
is returned.
On success the "SseEventSink" is used to write events.
If writing of an event throws an exception the event sink is closed.

To return "not found" I currently use an argument "@Context
HttpServletResponse response".
response.setStatus(Status.NOT_FOUND.getStatusCode());
After setting this status the method returns.
Is this okay or do I need to write a not found web application exception?
If I set the status and return, do I also need to close the event sink?
If I throw a web application excpetion, to I need to close the event
think explicit?
If some of mine code throws a runtime exception (e.g. NPE), must I
ensure the event sink is closed or should this be handled by the
whiteboard implementation?

On success, I want to inject additional headers. For example
"X-Accel-Buffering: no" and "Content-Encoding: identity".
Currently I am using "reponse.addHeader(..., ...)", too.
Can I also change the method signatur and return a Response object?
Should this be considered by the whiteboard implementation?
That way I could return e.g.
"Response.status(Status.NOT_FOUND).build()" or
"Response.ok().header(..., ...).header(..., ...).build()".

I am using an implementation of a "ContainerResponseFilter". It is
marked with "JaxrsExtension" annotations etc. and works for all my
REST endpoints.
Except for the SSE one...
Currently the implementations checks if the component is configured to
allow CORS and if allowed it adds headers to the response context.
Should such a container response filter be considered for endpoints
producing SSE or not?

Best regards,
Markus
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev


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

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

Re: [osgi-dev] Using Gradle or Maven on a new OSGi project

2019-06-25 Thread Mark Hoffmann via osgi-dev 

Hi Stephen,

1. Maven is very popular. So using maven makes it easy for a large 
audience to adopt OSGi. When there is an integration for the right build 
tool, people tend to rather try things out, then if they have to "learn" 
a new build tool.


2. You can also use gradle. We use only gradle together with bnd for the 
OSGi development in all our projects. Just try the Eclipse bndtools out. 
It creates a workspace utilizing gradle.


Mark

Am 24.06.19 um 22:28 schrieb Stephen Schaub via osgi-dev:
I'm new to OSGi and am starting a project. I found the enRoute 
material and noticed that the enRoute tutorials apparently at one time 
utilized Gradle as the build tool, but are now using Maven.


I'm more familiar with Gradle and have worked out how to use Gradle to 
do what I need for the project, but I was wondering 1) why the switch 
from Gradle to Maven for enRoute and 2) is Maven the preferred build 
tool for OSGi going forward? Is there a reason I should consider 
switching to Maven?


I've poked through the mailing list archives trying to find answers to 
these questions but can't seem to find a record of any discussions 
about this, so am hoping someone can shed some light for me.


--
Stephen Schaub

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


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

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

Re: [osgi-dev] Pushstream Example not compileable

2018-10-26 Thread Mark Hoffmann via osgi-dev 

May you try this:

public class PromiseExample {

    PushStreamProvider psp = null;
    SimplePushEventSource ses = null;

    public static void main(String[] args) {
        new PromiseExample().start();

    }

    private void start() {
        // Begin delivery when someone is listening
        ses.connectPromise().then(this::onConnect);

        // Create a listener which prints out even numbers
        psp.createStream(ses).
            filter(l -> l % 2L == 0).
            limit(100L).
            forEach(f -> System.out.println("Consumed event: " + f)).
            thenAccept((v)->ses.close());
    }

    private PromiseExample() {
        psp = new PushStreamProvider();
        ses = psp.createSimpleEventSource(Long.class);
    }

    private Promise onConnect(Promise promise) {
        new Thread(() -> {
            long counter = 0;
            // Keep going as long as someone is listening
            while (ses.isConnected()) {
                ses.publish(++counter);
                try {
                    Thread.sleep(100);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println("Published: " + counter);
            }
            // Restart delivery when a new listener connects
            ses.connectPromise().then(this::onConnect);
        }).start();
        return null;
    }

}


Am 26.10.18 um 16:52 schrieb stbischof via osgi-dev:

Hello,


I tried to compile  the Pushstream Example in the Spec: 706.5.1 
Optimizing Event Creation.


I got a compile exception "Local variable may not have been 
initialized." in line



ses.connectPromise().then(onConnect);


could somebody tell me more about how to get run this snipped

 


PushStreamProvider psp = new PushStreamProvider();

SimplePushEventSource ses = 
psp.createSimpleEventSource(Long.class))


Success onConnect = p -> {
    new Thread(() -> {
    long counter = 0;
    // Keep going as long as someone is listening
    while (ses.isConnected()) {
  ses.publish(++counter);
  Thread.sleep(100);
  System.out.println("Published: " + counter);
    }
    // Restart delivery when a new listener connects
    ses.connectPromise().then(onConnect);
  }).start();
    return null;
  };

// Begin delivery when someone is listening
ses.connectPromise().then(onConnect);

// Create a listener which prints out even numbers
psp.createStream(ses).
  filter(l -> l % 2L == 0).
  limit(5000L).

  forEach(f -> System.out.println("Consumed event: " + f));

 



regards

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


--
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 Straße 4
07745 Jena
Germany

Geschäftsführer
Mark Hoffmann
Jürgen Albert

Jena HRB 513025
Steuernummer 162/107/05779
USt-Id DE310002614

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

Re: [osgi-dev] osgi integration with Lucene or ElasticSearch

2018-10-03 Thread Mark Hoffmann via osgi-dev 
Hi, it depends on what you want to do.We use pure Lucene a search backend, that 
is heavily customized to the customers needs. This especially belongs to the 
data model he uses. For that we OSGi fied the Lucene stuff, because it is not 
OSGi ready. This can be easily done, except some split packages in lucene core 
and analyzers or codecs (I have to look for an exact answer). We created a rich 
set of services for searching and indexing. Using stuff like OSGi ds, 
configadmin, pushstreams making it very easy to create a small straight forward 
engine.
For more details you are welcome to contact us.
Elasticsearch on the other hand provides a full featured system, that can run 
as own service and scales very well. If you have an easy structured data model 
your best using Elasicsearch or even SOLr
Regards,Mark
Von meinem Samsung Galaxy Smartphone gesendet.
 Ursprüngliche Nachricht Von: Ali Parmaksız via osgi-dev 
 Datum: 03.10.18  07:45  (GMT+01:00) An: 
osgi-dev@mail.osgi.org Betreff: [osgi-dev] osgi integration with Lucene or 
ElasticSearch 
Hi,
Which one do you prefer to use? And why? And please give me concrete examples 
how to integrate them in an osgi project.

-- 
Ali Parmaksız

TEL:5052555693
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Best practices for providing configs in cloud setups?

2018-09-13 Thread Mark Hoffmann via osgi-dev 
We use the Zookeeper together with the ConfigAdmin, to share 
configurations. With the configuration plugin of the config admin, you 
can substitute the configuration or extend it with information from an 
alternative source.


In Zookeeper you can have global, configurations or create 
configuration-nodes just for your OSGi-node.


Mark


Am 13.09.2018 um 14:30 schrieb Christian Schneider via osgi-dev:
I am looking into good ways to provide configuration to OSGi bundles 
for cloud setups.


So my prototypical application would be a self running jar created by 
bndtools. This is then packaged into a docker image that simply runs 
the jar. The docker image is then deployed using kubernetes. I got an 
example of such an application from my adaptto talk about felix 
systemready. See https://github.com/cschneider/osgi-example-systemready


This is all well as long as all your config is inside the application 
already or can be read using existing means like the hostnames 
provided by kubernetes. For many cases this is not enough though.


I can imagine to use env variables to override key/values of configs 
like provided by the old configurer by Peter. I just created an issue 
to look into this: https://issues.apache.org/jira/browse/FELIX-5924


There are other possible ways though. For example kubernetes allows to 
map configMaps to files which then could be fed into config admin. Did 
anyone try this and ideally maybe has an example?


Some interesting possible requirements:
- The config should be applied in a way that avoids oscillation of 
services. So ideally config should be applied in one step

- Secrets should be protected in some way
- Kubernetes seems to be able to reflect updates to configMaps in a 
live system. So this might be a case where we want to update config 
inside a running app even in the cloud.


So what are your ideas and approaches with applying configs to OSGi 
cloud applications?


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


--
Mark Hoffmann
M.A. Dipl.-Betriebswirt (FH)
Geschäftsführer

Tel:+49 3641 384 910 0
Mobil:  +49 175 701 2201
E-Mail: m.hoffm...@data-in-motion.biz
Web: www.datainmotion.de

Data In Motion Consulting GmbH
Kahlaische Straße 4
07745 Jena

Geschäftsführer
Mark Hoffmann
Jürgen Albert

Jena HRB 513025
Steuernummer 162/107/05779
USt-Id DE310002614


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

Re: [osgi-dev] osgi-dev Digest, Vol 143, Issue 6

2018-09-10 Thread Mark Hoffmann via osgi-dev 

Hi Reza,

for OSGi is in our opinion the best approach for any software, thats 
needs to extensible or customizable. We use OSGi in desktop fat clients 
(Eclipse RCP) as well as in the backend and even on embedded devices.


The main success factor for us are all the specifications, that cover 
all the important topics of an enterprise application. Since OSGi our 
applications are more straight forward, cleaner compared with JEE for 
instance.


Regards,

Mark


Am 10.09.2018 um 22:39 schrieb Richard Nicholson via osgi-dev:

Reza,

OSGi is an excellent foundation for sophisticated adaptive distributed 
Enterprise systems: in my opinion far more so than the current REST/Docker 
Microservices approach.

My company has worked with a number of Financial Service organisations over the 
years - front, middle and back-office. I’d be happy to discuss our experiences 
further off list.

If interested - ping me an e-mail.

Regards

Richard



On 10 Sep 2018, at 17:00, osgi-dev-requ...@mail.osgi.org wrote:

Send osgi-dev mailing list submissions to
osgi-dev@mail.osgi.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mail.osgi.org/mailman/listinfo/osgi-dev
or, via email, send a message with subject or body 'help' to
osgi-dev-requ...@mail.osgi.org

You can reach the person managing the list at
osgi-dev-ow...@mail.osgi.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of osgi-dev digest..."


Today's Topics:

   1. Re: OSGi in corebanking (reza davari)


--

Message: 1
Date: Mon, 10 Sep 2018 09:50:21 +0430
From: reza davari 
To: osgi-dev@mail.osgi.org
Subject: Re: [osgi-dev] OSGi in corebanking
Message-ID:

Content-Type: text/plain; charset="utf-8"

On 9 Sep 2018 11:02 pm, "reza davari"  wrote:


Hello
We are investigating OSGi Usages in enterprise and larg scale applications
such as core banking, ERP, insurance industry and so on. but we didn't find
any resorces about that. can you introduce some resources and success
stories about applying  OSGi in such projects. Do you recommend the OSGi
for backend development such as Loan or Deposit in corbanking or accounting
or financial systems in insurance industry?if the answer is positive please
explain your conditions about commertial version and your support?

Best regards.


-- next part --
An HTML attachment was scrubbed...
URL: 


--

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

End of osgi-dev Digest, Vol 143, Issue 6


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


--
Mark Hoffmann
M.A. Dipl.-Betriebswirt (FH)
Geschäftsführer

Tel:+49 3641 384 910 0
Mobil:  +49 175 701 2201
E-Mail: m.hoffm...@data-in-motion.biz
Web: www.datainmotion.de

Data In Motion Consulting GmbH
Kahlaische Straße 4
07745 Jena

Geschäftsführer
Mark Hoffmann
Jürgen Albert

Jena HRB 513025
Steuernummer 162/107/05779
USt-Id DE310002614


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

Re: [osgi-dev] Docker configuration via environment variables

2018-08-20 Thread Mark Hoffmann via osgi-dev 

Hi all,

Carsten Ziegeler pointed us to the Configuration Plugin Services, that 
are part of the ConfigurationAdmin specification. Together with the 
Configurator specification, it could be possible to do that substitution 
in such an plugin.


Regards,

Mark


Am 20.08.2018 um 17:56 schrieb Christian Schneider via osgi-dev:
I think this would be a good extension to the configurator to also 
allow env variable replacement.

Actually I hoped it would already do this...
WDYT?

Christian

Am Mo., 20. Aug. 2018 um 17:05 Uhr schrieb Peter Kriens via osgi-dev 
mailto:osgi-dev@mail.osgi.org>>:


Are you using v2Archive enRoute or the new one?

The v2Archive OSGi enRoute has the simple Configurer (the
predecessor of the OSGi R7 Configurator but with, according to
some, a better name :-). It runs things through the macro
processor you could therefore use environment variables to make
the difference.

E.g. ${env;XUZ} in the json files. Since it also supports ${if}
you can eat your heart out! You can set environment variables in
docker with -e in the command line when you start the container.
You can also use @{ instead of ${ to not run afoul of the bnd
processing that can happen at build time. I.e. the Configurer
replaces all @{…} with ${…}.

If you are using the new R7 Configurator then you are on your own ...

Kind regards,

        Peter Kriens




> On 18 Aug 2018, at 18:51, Randy Leonard via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:
>
> To all:
>
> We are at the point where we are deploying our OSGI enRoute
applications via Docker.
>
> - A key sticking point is the syntax for embedding environment
variables within our configuration.json files.
> - For example, a developer would set a hostName to ‘localhost’
for development, but this same environment variable would be
different for QA, UAT, and Production environments
> - I presume this is the best way of allowing the same container
to be deployed in different environments without modification?
> - Suggestions and/or examples are appreciated.
>
>
>
> Thanks,
> Randy Leonard
>
> ___
> 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



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


--
Mark Hoffmann
M.A. Dipl.-Betriebswirt (FH)
Geschäftsführer

Tel:+49 3641 384 910 0
Mobil:  +49 175 701 2201
E-Mail: m.hoffm...@data-in-motion.biz
Web: www.datainmotion.de

Data In Motion Consulting GmbH
Kahlaische Straße 4
07745 Jena

Geschäftsführer
Mark Hoffmann
Jürgen Albert

Jena HRB 513025
Steuernummer 162/107/05779
USt-Id DE310002614


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

Re: [osgi-dev] Fwd: Eclipse Extension-points and EMF in OSGI

2018-08-09 Thread Mark Hoffmann via osgi-dev 

Alain,

no, we don't use CDO and didn't tried it. The only thing, that can make 
it not work are the Require-Bundle declarations in the CDO stuff.


We experienced some problems, because of this, with QVT and EMF Compare. 
We created a workaround bundle with the symbolic name 
'org.eclipse.core.runtime', because the Equinox supplement bundle was 
sadly not enough.


But it would be interesting for us to support CDO too. I think we meet 
Eike Stepper, the CDO lead, in October at the ECE2018 and discuss this 
topic with him.


Mark


Am 09.08.2018 um 17:02 schrieb Alain Picard via osgi-dev:

Jurgen,

This looks fantastic. Just out of curiosity, have you used it with CDO ?

Alain


On Thu, Aug 9, 2018 at 10:11 AM Jürgen Albert via osgi-dev 
mailto:osgi-dev@mail.osgi.org>> wrote:


It appears that we are too stupid to configure the project
properly. You can get started with this:
https://gitlab.com/gecko.io/geckoEMF/wikis/Get-started


Am 09/08/2018 um 14:54 schrieb Alain Picard:


On Thu, Aug 9, 2018 at 8:45 AM Jürgen Albert via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

Hi Alain,

EMF does work without extension points, but in its current
state needs manual registration of you EPackages.

Ok that is the interesting part.

The OSGi Compatibility option in the genmodel only defines
the org.eclipse.core.runtime as optional, which dues does not
really solve anything.

Agreed, not much.


We have an extension for EMF that solves this issue. You can
have EMF with any framework you like and without extension
points. Have a look here: https://gitlab.com/gecko.io/geckoEMF

Gitlab is reporting an error " An error occurred while loading
commit signature" and not getting that error with the other
gecko.io  project.



If you have any questions, feel free to ask.

Jürgen.

Am 09/08/2018 um 11:12 schrieb Tim Ward:




Begin forwarded message:

*From: *Tim Ward mailto:tim.w...@paremus.com>>
*Subject: **Re: [osgi-dev] Eclipse Extension-points and EMF
in OSGI*
*Date: *9 August 2018 at 10:02:50 BST
*To: *Alain Picard mailto:pic...@castortech.com>>, OSGi Developer Mail List
mailto:osgi-dev@mail.osgi.org>>
*Cc: *Scott Lewis mailto:sle...@composent.com>>

I would expect that Mark Hoffman or Jürgen Albert might
have some useful pointers, I’m pretty sure that they’re
heavy users of EMF.

Best Regards,

Tim


On 9 Aug 2018, at 09:20, Alain Picard via osgi-dev
mailto:osgi-dev@mail.osgi.org>>
wrote:

Scott,

I noticed the split of the o.e.core.runtime and am already
using the o.e.equinox.common + supplement and running some
stuff like that with Felix. But that part doesn't include
of the support for extension points that is in the other
"half", hence my question.

Alain


On Thu, Aug 9, 2018 at 12:18 AM Scott Lewis via osgi-dev
mailto:osgi-dev@mail.osgi.org>>
wrote:

IOn 8/8/2018 7:43 AM, Alain Picard via osgi-dev wrote:
> Working through our move from RCP to a generic OSGI
solution, and I am
> stuck with a couple of questions.
>
> There was an issue a while ago for EMF that resulted
in a generation
> setting to support generic OSGI frameworks and not only
> Eclipse/Equinox. But the resulting bundles still
have plugin.xml and
> expose extension points. My understanding is that
this part of Eclipse
> is not covered in the portable part of
o.e.core.runtime. We also have
> a number of our own extension-points, some that we
have already
> converted and others that are still around.
>
> So anyone has successfully used EMF and/or Extension
points outside of
> a full Eclipse environment?

Yes wrt extension registry/extension points.

o.e.core.runtime is a split package, split between
bundles
o.e.equinox.common and o.e.equinox.registry

I'm not sure of the justification for split packages,
but I think it was
done to maintain backward compatibility in eclipse
plugins.

The version I used was a few years ago, but at that
time these two
bundles...along with equinox...would run the extension
registry (i.e.
process extension points/extensions on startup). 
AFAIK that's still the
case.

If you want to use a framework other than equinox, I
know for certain
that o.e.equinox.common works just fine on Felix...as

Re: [osgi-dev] Fwd: Eclipse Extension-points and EMF in OSGI

2018-08-09 Thread Mark Hoffmann via osgi-dev 

Hi Alain,


Am 09.08.2018 um 14:54 schrieb Alain Picard via osgi-dev:


On Thu, Aug 9, 2018 at 8:45 AM Jürgen Albert via osgi-dev 
mailto:osgi-dev@mail.osgi.org>> wrote:


Hi Alain,

EMF does work without extension points, but in its current state
needs manual registration of you EPackages.

Ok that is the interesting part.

The OSGi Compatibility option in the genmodel only defines the
org.eclipse.core.runtime as optional, which dues does not really
solve anything.

Agreed, not much.
You can run EMF e.g. in an non-OSGi/non-Eclipse environment as well. No 
matter where, you only need org.eclipse.emf.common, 
org.eclipse.emf.ecore and org.eclipse.emf.ecore.xmi as dependencies.


As Jürgen told, the required bundles declaration in the manifest defines 
the org.eclipse.core.runtime dependency as optional.



We have an extension for EMF that solves this issue. You can have
EMF with any framework you like and without extension points. Have
a look here: https://gitlab.com/gecko.io/geckoEMF

Gitlab is reporting an error " An error occurred while loading commit 
signature" and not getting that error with the other gecko.io 
 project.

Thats a little bit strange, I will check this.
You can also try the artifacts from the links in the project description 
readme.md




If you have any questions, feel free to ask.

Jürgen.

Am 09/08/2018 um 11:12 schrieb Tim Ward:




Begin forwarded message:

*From: *Tim Ward mailto:tim.w...@paremus.com>>
*Subject: **Re: [osgi-dev] Eclipse Extension-points and EMF in OSGI*
*Date: *9 August 2018 at 10:02:50 BST
*To: *Alain Picard mailto:pic...@castortech.com>>, OSGi Developer Mail List
mailto:osgi-dev@mail.osgi.org>>
*Cc: *Scott Lewis mailto:sle...@composent.com>>

I would expect that Mark Hoffman or Jürgen Albert might have
some useful pointers, I’m pretty sure that they’re heavy users
of EMF.

Best Regards,

Tim


On 9 Aug 2018, at 09:20, Alain Picard via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

Scott,

I noticed the split of the o.e.core.runtime and am already
using the o.e.equinox.common + supplement and running some
stuff like that with Felix. But that part doesn't include of
the support for extension points that is in the other "half",
hence my question.

Alain


On Thu, Aug 9, 2018 at 12:18 AM Scott Lewis via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

IOn 8/8/2018 7:43 AM, Alain Picard via osgi-dev wrote:
> Working through our move from RCP to a generic OSGI
solution, and I am
> stuck with a couple of questions.
>
> There was an issue a while ago for EMF that resulted in a
generation
> setting to support generic OSGI frameworks and not only
> Eclipse/Equinox. But the resulting bundles still have
plugin.xml and
> expose extension points. My understanding is that this
part of Eclipse
> is not covered in the portable part of o.e.core.runtime.
We also have
> a number of our own extension-points, some that we have
already
> converted and others that are still around.
>
> So anyone has successfully used EMF and/or Extension
points outside of
> a full Eclipse environment?

Yes wrt extension registry/extension points.

o.e.core.runtime is a split package, split between bundles
o.e.equinox.common and o.e.equinox.registry

I'm not sure of the justification for split packages, but I
think it was
done to maintain backward compatibility in eclipse plugins.

The version I used was a few years ago, but at that time
these two
bundles...along with equinox...would run the extension
registry (i.e.
process extension points/extensions on startup).  AFAIK
that's still the
case.

If you want to use a framework other than equinox, I know
for certain
that o.e.equinox.common works just fine on Felix...as long
as one also
includes this bundle [1].

I don't think EMF requires anything in addition to
o.e.equinox.common
and o.e.equinox.registry but I'm not completely sure about
that.

Scott

[1] org.eclipse.equinox.supplement  - available via equinox
or maven central


___
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






-- 
Jürgen Albert

Geschäftsführer

Data In Motion Consulting GmbH (haftungsbeschränkt)