Oh I’m pretty sure it is possible in your case. Regards, Neil
On 15 August 2014 at 11:07:00, Konstantine Kougios ([email protected]) wrote: Hi Bruce, This is not possible in my case. This is because A doesn’t expose any service. A is just a models bundle for apache sling, so there are model classes annotated with @Model. Then C (sling) registers those models in it’s adaptTo registry. There is no service exported by A. B is my service layer and it requires the models of A, and there are services that need to adaptTo() during activation. Cheers On 15/08/2014 10:59, "Bruce Jackson" <[email protected]> wrote: >Konstantine > >As others have said, you should assume anything about bundle start order, >and neither should you have to make one bundle start another. >If B depends on A, then it should have a dependency on a service interface >exported by A. There are several ways you can implement this, as Neil >says, either by DS or by a ServiceTracker in B. > >Thanks > >Bruce > >On 14/08/14 17:18, "Konstantine Kougios" <[email protected]> >wrote: > >>Hi Bruce, >> >>C is a service that keeps a class registry based on annotations >>A uses those annotations. When A is started, the annotated classes are >>registered with C >>B depends on A but via C. >> >>So B doesn’t depend on a service of A (A contains domain model classes >>that are annotated). But it needs the annotated classes to be registered >>on C. C is a 3rd party bundle (sling) which is always in started state. >> >>What I did so far, on B I added a BundleActivator that forces A to start: >> >>public class Activator implements BundleActivator { >> @Override >> public void start(final BundleContext bundleContext) throws >>Exception { >> Bundle[] bundles = bundleContext.getBundles(); >> for (Bundle bundle : bundles) { >> String name = bundle.getSymbolicName(); >> if (“my_A_bundle_symbolic_name".equals(name)) { >> bundle.start(); >> } >>…. >>} >> >>This works and solves my issue but it means I need to manage any other >>such dependencies in that class. I don’t know if there is a better way. >> >>Cheers >> >> >> >> >> >>On 14/08/2014 17:12, "Bruce Jackson" <[email protected]> >>wrote: >> >>>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. >>>?B?KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKC >>>B >>>* >>>??[???昧?X?K??K[XZ[???\???[???昧?X?P??[?^??\?X?K???‘???Y??]?[?[??栢 >>>[X[????K[XZ[???\????[????[?^??\?X?K??? >> > >*** 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
