It's not always about services. For example many Eclipse bundles assume that the SWT Display has already been created, and furthermore they are being activated on the UI thread. Again, that's a bunch of bad assumptions on behalf of the bundle author, but they *do* work if the activation policy is used.
I guess I agree with you that eager activation should always be possible, but following the bundle's policy makes most sense to me as a default. Neil On Wednesday, 11 January 2012 at 17:45, Richard S. Hall wrote: > On 1/11/12 12:34 , Neil Bartlett wrote: > > Unfortunately I have seen many errors with bundles that assume they are > > lazily activated and actually fail if eagerly activated. While that is > > clearly an error, I tend to regard the Bundle-ActivationPolicy header as an > > expression of intended usage from the bundle author. > > > > What kind of errors? > > The only error I can think of is that the bundle wasn't actually > activated before client bundles, but that is a general problem with > these sorts of bundles because they always need to be started (lazily or > not) before client bundles otherwise they'll fail. > > That's why they're not so good, because they create bundle activation > ordering requirements. > > -> richard > > > > > I do agree with you that in general, lazy activation is a hack... it > > complicates the bundle lifecycle and is too easily abused. I am much more a > > fan of the style of laziness supported by DS and iPOJO. > > > > Neil > > > > > > On Wednesday, 11 January 2012 at 17:20, Richard S. Hall wrote: > > > > > On 1/11/12 12:04 , Neil Bartlett wrote: > > > > Guillaume, > > > > > > > > In this case the bundle will be fully started, i.e. "forced" to start > > > > without regard for its policy. Because of this I recommend that you > > > > *always* start bundles with the START_ACTIVATION_POLICY flag. > > > > > > > > I believe that it was discussed that the default behaviour of the > > > > zero-arg start() method should be changed to be equivalent to > > > > start(START_ACTIVATION_POLICY). However the old behaviour was kept for > > > > backwards compatibility reasons. > > > Not sure I agree with this. It is never wrong to start a bundle eagerly, > > > but it can lead to unexpected results if a bundle that provides a > > > service is started lazily...of course, you could argue that this bundle > > > shouldn't have a lazy policy, but that is a separate issue. My first > > > point remains, it is never incorrect to start a bundle eagerly. > > > > > > In general, laziness is actually not that great since it hides > > > dependencies in class loads, rather than basing them on services. > > > > > > -> richard > > > > > > > Regards, > > > > Neil > > > > > > > > > > > > On Wednesday, 11 January 2012 at 16:55, Guillaume Sauthier (OW2) wrote: > > > > > > > > > Another question related to the activation policy. > > > > > What happen if the Bundle's manifest has the Bundle-ActivationPolicy > > > > > header but the Bundle.start() methods is called without arguments (no > > > > > options so no START_TRANSIENT and no START_LAZY_ACTIVATION) ? > > > > > > > > > > --G > > > > > > > > > > 2012/1/11 Guillaume Sauthier (OW2)<[email protected] > > > > > (mailto:[email protected])> > > > > > > With Felix, we experienced that the Bundle triggering the class > > > > > > load can use the class loaded from the lazy Bundle, but the lazy > > > > > > Bundle was not activated after the class was loaded... > > > > > > > > > > > > --G > > > > > > > > > > > > 2012/1/11 Guillaume Sauthier (OW2)<[email protected] > > > > > > (mailto:[email protected])> > > > > > > > > > > > > > Hi all > > > > > > > > > > > > > > What happen when a Bundle with Bundle-ActivationPolicy: lazy in > > > > > > > its Manifest is being used while in the RESOLVED state ? > > > > > > > In other words, the Bundle has not yet been started with > > > > > > > Bundle.start(START_LAZY_ACTIVATION), but another Bundle is being > > > > > > > activated and is using a class from the lazy Bundle. > > > > > > > > > > > > > > The examples I found on the OSGi web site are only explaining > > > > > > > behaviors when the lazy bundle is activated because of a > > > > > > > Bundle.loadClass() while in STARTING state. > > > > > > > > > > > > > > Thanks > > > > > > > --G > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > OSGi Developer Mail List > > > > > [email protected] (mailto:[email protected]) > > > > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > OSGi Developer Mail List > > > > [email protected] (mailto:[email protected]) > > > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > > > > > > > > _______________________________________________ > > > OSGi Developer Mail List > > > [email protected] (mailto:[email protected]) > > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > > > > > > _______________________________________________ > > OSGi Developer Mail List > > [email protected] (mailto:[email protected]) > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] (mailto:[email protected]) > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
