A lot of Eclipse bundles use "Bundle-ActivationPolicy: lazy". That's because they want to have Bundle-Activators *AND* have those bundles be free to start (also known as "having their cake and eating it"!)
But frankly it's just for legacy reasons. If you're creating a new bundle using DS, you don't need a Bundle-Activator. Eclipse bundles often have activators for two reasons: 1. Legacy. Many of these bundles have been around for over ten years and are too hard to change without breaking existing users. 2. Tooling. Eclipse PDE by default creates new plug-ins with activators. I've already stated elsewhere that I think this is a dumb idea! Incidentally, though the bundles are listed as having state "<<lazy>>", there is really no such state. They are actually suspended in the STARTING state. Regards Neil On Fri, Feb 18, 2011 at 10:10 AM, ajinkya prabhune <[email protected]> wrote: > Hi, > Thanks a lot... for such a fast reply. > Ok I get the concpet. > You are correct I was trying to avoid the large overhead and the time > required of starting all > the bundle during the launch of the Framewrok.. > So I guess now they all need to be started... > A small doubt what does the <<lazy>> atrribute means in the osgi eclipse > console... its making me quiet confusing. > > Thanks and regards > Ajinkya > On Thu, Feb 17, 2011 at 11:54 PM, Neil Bartlett <[email protected]> > wrote: >> >> Nope it won't work like that. DS will never look at a stopped >> bundle... even with the "lazy activation" policy, it only looks at >> bundles in the ACTIVE or STARTING states. >> >> Instead, turn the problem around: why is A stopped? Why not just start >> all bundles? >> >> You are probably worried about startup time of your application; >> that's a completely valid concern. But rather than trying to avoiding >> starting bundles and then asking DS to look at unstarted bundles, >> instead we make it (essentially) free to start bundles. >> >> How do we get bundles that are "free" to start? Just don't declare a >> Bundle-Activator. >> >> Regards, >> Neil >> >> On Thu, Feb 17, 2011 at 10:01 PM, ajinkya prabhune >> <[email protected]> wrote: >> > Hi Neil, >> > >> > I agree but what I mean is... >> > Bundle A has the service which Bundle B refers... >> > (Bundle A is stopped) >> > what I intend to do is when I start Bundle B it should look up and >> > recognize >> > that >> > it refers to Bundle A for a service... but Bundle A is stopped so is >> > there a >> > possibility to start the Bundle A at that moment. >> > >> > If I am wrong somewhere wrt to DeclarativeServices ... please let me >> > know... >> > >> > Thanks and Regards >> > Ajinkya >> > >> > >> > >> > On Wed, Feb 16, 2011 at 3:48 PM, Neil Bartlett <[email protected]> >> > wrote: >> >> >> >> Answer inline below... >> >> >> >> On Wed, Feb 16, 2011 at 2:36 PM, ajinkya prabhune >> >> <[email protected]> wrote: >> >> > Hello, >> >> > >> >> > Super help from both of u. I am now gng through the articles and >> >> > seeing >> >> > how >> >> > it works... >> >> > >> >> > Yes I am trying to use a Service declared in A bundle --- to use in B >> >> > bundle... >> >> > >> >> > Can I make the A Bundle As Lazy so that when B bundle ask for service >> >> > in >> >> > A >> >> > ... the A bundles gets Active and Registers the Service >> >> > will this work ? >> >> >> >> No, this is not what "lazy activation" in OSGi is for. It has nothing >> >> to do with services. >> >> >> >> Declarative Services provides the right kind of laziness. If you >> >> define a component in B that has a mandatory reference (i.e. >> >> cardinality 1..1 or 1..n) to the service published from A, then it >> >> will only create the component when the service becomes available, >> >> which would be after A is activated. >> >> >> >> In most cases the "lazy activation policy" is not required and is IMHO >> >> an annoying distraction. All you really need is the following: >> >> >> >> 1) Create a DS component and declare it with a component.xml file >> >> 2) Do NOT create a BundleActivator... you don't need it when using DS. >> >> 3) Start both bundles A and B, in any order. >> >> >> >> Cheers, >> >> Neil >> >> >> >> > >> >> > Thanks for ur quick reply... >> >> > >> >> > On Wed, Feb 16, 2011 at 3:32 PM, Neil Bartlett <[email protected]> >> >> > wrote: >> >> >> >> >> >> Ajinka, >> >> >> >> >> >> Do not do this. It is a common newbie mistake: there should be no >> >> >> start-ordering dependency between bundles. >> >> >> >> >> >> You do not state *why* you want B to start after A has started. I >> >> >> assume that you want to publish a service from A and consume it from >> >> >> B? The correct way to do this is have B *listen* for the >> >> >> availability >> >> >> of the service it needs to use, then A and B can be started in any >> >> >> order. >> >> >> >> >> >> As Petar points out, using Declarative Services (DS) is a much >> >> >> easier >> >> >> way to implement services, since it takes care of all the aspects of >> >> >> listening for availability etc. I strongly recommend that you use DS >> >> >> instead of coding against the low-level OSGi services APIs. >> >> >> >> >> >> Regards, >> >> >> Neil >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Feb 16, 2011 at 1:36 PM, ajinkya prabhune >> >> >> <[email protected]> wrote: >> >> >> > Hello, >> >> >> > >> >> >> > I am quite new to the concept of OSGi and bundles. >> >> >> > I have this issue. >> >> >> > For eg - I have 2 bundles >> >> >> > Bundle A and Bundle B, Bundle A depends on Bundle B >> >> >> > But I want to start Bundle B only when Bundle A is started... >> >> >> > what are the ways to do it ? I manually found out the Bundle B >> >> >> > using >> >> >> > the >> >> >> > Bundle object and started the Bundle B with bundle.start() but I >> >> >> > would like to do it without the Java Code. can the Framework Help >> >> >> > me. >> >> >> > >> >> >> > >> >> >> > I am not sure but how does Bundle ActivationPolicy lazy works ? >> >> >> > >> >> >> > >> >> >> > >> >> >> > Thank u and regards >> >> >> > >> >> >> > -- >> >> >> > Thank you and Regards >> >> >> > Ajinkya Prabhune >> >> >> > >> >> >> > >> >> >> > _______________________________________________ >> >> >> > equinox-dev mailing list >> >> >> > [email protected] >> >> >> > https://dev.eclipse.org/mailman/listinfo/equinox-dev >> >> >> > >> >> >> > >> >> >> _______________________________________________ >> >> >> equinox-dev mailing list >> >> >> [email protected] >> >> >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> >> > >> >> > >> >> > >> >> > -- >> >> > Thank you and Regards >> >> > Ajinkya Prabhune >> >> > >> >> > >> >> > _______________________________________________ >> >> > equinox-dev mailing list >> >> > [email protected] >> >> > https://dev.eclipse.org/mailman/listinfo/equinox-dev >> >> > >> >> > >> >> _______________________________________________ >> >> equinox-dev mailing list >> >> [email protected] >> >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> > >> > >> > >> > -- >> > Thank you and Regards >> > Ajinkya Prabhune >> > >> > >> > _______________________________________________ >> > equinox-dev mailing list >> > [email protected] >> > https://dev.eclipse.org/mailman/listinfo/equinox-dev >> > >> > >> _______________________________________________ >> equinox-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > > -- > Thank you and Regards > Ajinkya Prabhune > > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
