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 <[email protected]>
> 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
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
