I agree with the following statement:
Your bundles should never make any assumptions on the order in which
they are started.
I would stick to this statement. Your bundles should be able to handle
themselves correctly no matter in which order things are started. If they
depend on a service that are not started yet they should just wait until it
becomes available. When all bundles are upp and running and all services are
available all should be good. You should consider a timeout waiting for
something however. If your code just accept that something will be available in
due time, the order bundles are started in are completely irrelevant. I would
also say that the application/service/whatever will be more stable then, since
if it can handle that, it can also handle services temporarily being gone later
due to bundle redeployment by simply waiting for them to become available
again. This allows redeployments with minimal impact on running code.
Cheers,
Tommy
14 aug 2014 kl. 12:54 skrev Jan Willem Janssen <[email protected]>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 14/08/14 12:47, Konstantine Kougios wrote:
>> This creates problems for me as some services on A do register
>> classes on a separate bundle C. So A services, when activated,
>> expect to find those registrations on C but can’t.
>>
>> Is this a common issue? Is there a solution?
>
> Your bundles should never make any assumptions on the order in which
> they are started. OSGi is intended to be a dynamic environment in
> which services can come and go at any time.
>
> Basically, you want to use a higher-level API, such as Felix
> Dependency Manager or Declarative Services to describe the service
> dependencies. This way, your services can get callbacks or get
> notified when their dependencies are met or are no longer met.
>
> - --
> Met vriendelijke groeten | Kind regards
>
> Jan Willem Janssen | Software Architect
> +31 631 765 814
>
> /My world is revolving around INAETICS and Amdatu/
>
> Luminis Technologies B.V.
> Churchillplein 1
> 7314 BZ Apeldoorn
> +31 88 586 46 00
>
> http://www.luminis-technologies.com
> http://www.luminis.eu
>
> KvK (CoC) 09 16 28 93
> BTW (VAT) NL8169.78.566.B.01
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBAgAGBQJT7JVWAAoJEKF/mP2eHDc4tyQP/2nBps6b0s5JAm6NFceq0w8Z
> W/jM6CTP2+3T3kZBsUIauU74thMAo3fYDapprtS1dSIc5CvQYJIGN6Ls4fw+NVt7
> jh+iQpddtWEsR+j3K38TP+5LhRL4glQcaKu5As1kWeLpccMIxG8X/b+PjelMbuXD
> DBu3JPp3n7SH20JKfcCAtvo5a7fVXmFg8C5i3xEyfX9nd0IjccaAgC6MJTbyFyTX
> pw0p5cwdRP1/izo+ErIHcOu0zTKvSnfovPYgl7HOwwwafCj5ZJpZjNTHezIiNDWq
> 1UvTJN6owX0a7sG/O/dOl1KZ1r7HG3w0pRX88XJ952FIBZXiwGROyuciizt7S8hj
> vaikwUXkX1L8VG3O5/wVEbBVXzaStTCtjUUL2obh7hMt8gHFweV4wAte3Z49cr4G
> 11V5PoaS0lCyqA7JiSi42Ob23JiZZ9vg3ja2+n98LT6F9bhjV3Tm5J+pPvKxnkcB
> +0Z2WTCsQ0URwKE8zY4aXARuVVm1ypq3c5DPz7bP+tEOG3b00kpgMCZkc3R8hut+
> 0NXfyzS99f9HAMX4Gyy65d6CcWGewOKc+qflkJLehdNs8taM/cRn8Cg3gF1gvXEU
> 29W7+3xLKf3jSRONPKsyXAZ3K/ykhvpRhJvrNzWDdZLUlANMHPq7+vI3lN5eycyp
> 3SR528SyP9q0xpGNpbay
> =3/N6
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
