Thanks for the explanation Rick. So I have an ordering issue when running in Felix
This is now more a FileInstall question, but is there a way to ensure that lazy bundles are started first, and then only start non lazy bundles ? --G 2012/1/11 Richard S. Hall <[email protected]> > On 1/11/12 12:47 , Guillaume Sauthier (OW2) wrote: > > Our use case involves FileInstall for starting Bundles in a directory. > > When runned within Felix, we end up with a RESOLVED lazy bundle > triggered to load a class but not activating the lazy Bundle. > > When runned within Equinox (with the same FileInstall and same directory > of Bundles), all our lazy Bundles are happily started. > > So I assume that RESOLVED lazy bundles in Equinox are being started > automatically. > (I assumed that the same FileInstall with the same directory content would > produce the same set of install/start actions). > > > Well, there are different ways to handle the lazy activation trigger: > > 1. A one-time trigger, where the bundle is only activated once per > first class per class loader. > 2. Per start trigger, where the bundle is put into STARTING each time > it is stopped and restarted, regardless of whether or not classes have > already been loaded from it. > > Felix implements (1) and Equinox implements (2), I believe. > > So, you could also see differences here, but not sure if this is impacting > you. > > -> richard > > > --G > > 2012/1/11 Richard S. Hall <[email protected]> > >> >> >> On 1/11/12 12:31 , Guillaume Sauthier (OW2) wrote: >> >> Is there any reason to not move your RESOLVED lazy Bundle into STARTING >> state automatically when a class loading request happen ? >> >> Or starting a Bundle is ALWAYS a "manual" operation ? I mean do we want >> someone to take the decision to start a Bundle ? >> >> >> The framework doesn't arbitrarily make start/stop decisions. That is the >> job of the management agent. >> >> -> richard >> >> >> >> --G >> >> 2012/1/11 Richard S. Hall <[email protected]> >> >>> On 1/11/12 11:24 , Guillaume Sauthier (OW2) wrote: >>> >>> 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... >>> >>> >>> A bundle will only ever be activated if it has already been started. >>> This is true for lazy and non-lazy bundles. The only difference is that >>> lazy bundle activation is deferred until the first class load, while >>> non-lazy is immediate. >>> >>> In other words, if you haven't started your lazy bundles, don't expect >>> them to get lazily activated. >>> >>> -> richard >>> >>> >>> --G >>> >>> 2012/1/11 Guillaume Sauthier (OW2) <[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 >>> [email protected]https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >> >> >> >> _______________________________________________ >> OSGi Developer Mail >> [email protected]https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > > > > _______________________________________________ > OSGi Developer Mail > [email protected]https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
