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

Reply via email to