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 <peter.kri...@aqute.biz> wrote:
>
> 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 methods.
>
> In general you want to afford this complexity and for example use a simple
> init() method that blocks until init is done. However, the delegate has some
> nice qualities if you switch more often than just at init.
>
> Kind regards,
>
> Peter Kriens
>
>> On 22 Jul 2018, at 10:35, David Leangen via osgi-dev
>> <osgi-dev@mail.osgi.org> wrote:
>>
>>
>> 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
>> component is available before it is actually “ready”. So far, this has not
>> been a problem.
>>
>> It looks something like this:
>>
>> @Reference private Store dataStore;
>>
>> @Activate
>> void activate() {
>> configure(dataStore);
>> }
>>
>> void configure(Store withDataStore) {
>> // Configuration is set up via a Promise, using a data store to retrieve the
>> data
>> }
>>
>> However, because there is some bouncing occurring, I think what is happening
>> is that configure() starts running in a different thread, but in the
>> meantime the reference to the dataStore is changed. The error log shows that
>> the data store is in an impossible state. After following a hunch, I could
>> confirm that the configureData process is running on a data store service
>> that was deactivated during bouncing.
>>
>> What would be a good (and simple) strategy to handle this type of
>> long-running configuration, where the configuration is in a different thread
>> and depends on services that may come and go?
>>
>>
>> Note: in the end, the component gets configured and the application runs,
>> but I would still like to be able to handle this situation properly.
>>
>>
>> Thanks!
>> =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
