On 1/12/12 04:06 , Guillaume Sauthier (OW2) wrote:
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 ?
Not sure, you should ask on the users@felix list...it would likely be
good policy for File Install to do this, since lazy bundles are
generally indicated that they need to be started to be functional...of
course, if there are dependencies among lazy bundles, then you're really
out of luck! :-o
--G
2012/1/11 Richard S. Hall <[email protected]
<mailto:[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]
<mailto:[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]
<mailto:[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]
<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] <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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
