Hi, Regarding Sling Models specifically (vs. the larger OSGi question), when you have a Sling Model annotated class and the appropriate bundle header, Sling Models will automatically register an AdapterFactory OSGi service. So if you had a downstream component which needed to do something *only* when a particular adaptation was available, you could use this AdapterFactory service's presence or absense. There is no need for additional services to be exposed by the bundle containing your model classes (Bundle A IIUC).
Regards, Justin On Fri, Aug 15, 2014 at 11:29 AM, Konstantine Kougios <[email protected]> wrote: > > > From: Neil Bartlett <[email protected]<mailto:[email protected]>> > Date: Friday, 15 August 2014 13:36 > To: "[email protected]<mailto:[email protected]>" > <[email protected]<mailto:[email protected]>>, Konstantine Kougios > <[email protected]<mailto:[email protected]>> > Subject: Re: bundle starting order > > On 15 August 2014 at 13:13:23, Konstantine Kougios > ([email protected]<mailto:[email protected]>) wrote: > Sling bundle (bundle C) is searching for annotated classes. Bundle B has the > issue. So my module B doesn’t search for the annotated classes. It just uses > them but calls C’s methods which fail because A (annotated model) is not > loaded > > > How does it call C’s methods? Hopefully C is publishing a service, in which > case that services should only be published when the dependency (A) is > available. You can use a BundleTracker inside C for this. > > I don’t have control of C, it is apache’s Sling api. It provides a class > Resource and a method Resource.adaptTo(Model class) which in turn use my A > bundle to convert data to domain model instances. > > So from B I don’t use a service of C. Just Resource.adaptTo(my model class > which is on A). > > > So what I could do with BundleTracker on B is track when A is loaded and then > do the logic on B. Though it will probably work, it is weird and I will have > to do it in all services which need to do things using A’s classes. > > All in all it seems this is not properly supported by sling/osgi. Probably > the way sling registers the annotations is not supported by osgi reg. bundle > lifecycle. > > I’d rather manually start A in the Activator rather than have my services > BundleTrack A because if I use BundleTracker I will have to do that on each > service of B. > > > So no way in osgi to say “look bundle B will not work without bundle A > started” declaratively? It sounds a pretty common scenario to me. > > > Yep… services! > > Ok I see. > > Thanks > > > > > Neil > > > > > > From: Neil Bartlett <[email protected]<mailto:[email protected]>> > Date: Friday, 15 August 2014 13:06 > To: "[email protected]<mailto:[email protected]>" > <[email protected]<mailto:[email protected]>>, Konstantine Kougios > <[email protected]<mailto:[email protected]>> > Subject: Re: bundle starting order > > Well you said you’re searching for annotated classes in A; this can be done > with a BundleTracker, as I indicated about 3 or 4 messages back in the thread. > > Regards, > Neil > > > > On 15 August 2014 at 12:58:50, Konstantine Kougios > ([email protected]<mailto:[email protected]>) wrote: > > Ok, any hints? > > From: Neil Bartlett <[email protected]<mailto:[email protected]>> > Date: Friday, 15 August 2014 13:02 > To: "[email protected]<mailto:[email protected]>" > <[email protected]<mailto:[email protected]>>, Konstantine Kougios > <[email protected]<mailto:[email protected]>> > Subject: Re: bundle starting order > > 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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]> >>>>>>> For additional commands, e-mail: >>>>>>> [email protected]<mailto:[email protected]> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>--------------------------------------------------------------------- >>>>>>To unsubscribe, e-mail: >>>>>>[email protected]<mailto:[email protected]> >>>>>>For additional commands, e-mail: >>>>>>[email protected]<mailto:[email protected]> >>>>>> >>>>> >>>>> >>>>>--------------------------------------------------------------------- >>>>>To unsubscribe, e-mail: >>>>>[email protected]<mailto:[email protected]> >>>>>For additional commands, e-mail: >>>>>[email protected]<mailto:[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]<mailto:[email protected]> > For additional commands, e-mail: > [email protected]<mailto:[email protected]> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
