Hi Konstantine I think if you could provide some kind of simple dependency statement, it would be clearer. I can’t work out if you’re saying you have:
a depends on b b depends on c or a depends on b b depends on c or a depends on b c depends on a and b ? Thanks Bruce On 14/08/14 15:55, "Konstantine Kougios" <[email protected]> wrote: >Hi, > >"If they depend on a service that are not started yet they should just >wait until it becomes available² > >Problem is that the service is on bundle C and started during container >startup. Bundle C is not restarted when I deploy my bundles. A has >annotations on some classes that declare that they have to be registered >on C. B uses those annotated classes and the services of C. But B is >started before A which means C is not aware of the annotated classes of A. >(I hope it makes sense) > >Cheers > > >On 14/08/2014 12:23, "Tommy Svensson" <[email protected]> wrote: > >>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] >> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [email protected] >For additional commands, e-mail: [email protected] > *** DISCLAIMER *** This message, including attachments, is intended solely for the addressee indicated in this message and is strictly confidential or otherwise privileged. If you are not the intended recipient (or responsible for delivery of the message to such person) : - (1) please immediately (i) notify the sender by reply email and (ii) delete this message and attachments, - (2) any use, copy or dissemination of this transmission is strictly prohibited. If you or your employer does not consent to Internet email messages of this kind, please advise Myriad Group AG by reply e-mail immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by Myriad Group AG unless otherwise indicated by an authorized representative independent of this message.
