Just to close this loop…
I just finished an iteration, following the advice presented in this thread. I
think that I have been able to successfully deal with all my concurrency
troubles.
Thanks for the tips!
Cheers,
=David
> On Jul 23, 2018, at 16:36, Tim Ward wrote:
>
> An alternative
An alternative way to look at this is simply that your DS component needs to be
sufficiently thread-safe to deal with the consequences of its own internal
threading model. In this case:
> What would be a good (and simple) strategy to handle this type of
> long-running configuration, where the c
Ok … on the top of my head …
public interface Bar {
void m1();
void m2();
}
@Component
public class BarImpl implements Bar {
Deferred delegate = new Deferred<>();
@Reference
void
Hi Peter,
Thanks for the tip.
I’m not quite getting it. Would you be able to direct me to an example?
Thanks!
=David
> On Jul 22, 2018, at 21:49, Peter Kriens wrote:
>
> In some cases (when the extra complexity was warranted) I let the component
> class act as a proxy to a delegate. I the
In some cases (when the extra complexity was warranted) I let the component
class act as a proxy to a delegate. I then get the delegate from a Promise. So
you just forward every method in your service interface to the delegate. There
is a function in Eclipse that will create the delegation meth
Hi,
This may be more of a basic Java question, but I’ll ask it anyway because it
relates to “bouncing” and the handling of dynamic behavior.
In my @Activate method, I configure my component. Since the configuration may
be long-running (data is retrieved remotely), I use a Promise. But, the
co
