Sahoo wrote:
Hi Angelo,
I am confused. Please help me understand something here. If what you
said were the intention of the spec, why does the spec require
Bundle.loadClass() to cause the corresponding bundle to go to ACTIVE
state when the bundle uses LAZY activation policy [1]? Seems like LAZY
is more eager than EAGER activation policy (the default policy)!
That is a new feature of R4.1 and it is currently not supported by Felix.
Regardless, resolving a bundle and activating a bundle are not related
how you think. A bundle must be resolved for other bundles to be able to
load classes from it and for it to be activated. It is NOT necessary for
a bundle to be activated for other bundles to load classes from it,
though. Think of library bundles, i.e., bundles that only export. They
have no activator and need never be activated.
Lazy activation is another issue altogether. It has to do with
separating starting a bundle from activating a bundle. Since activating
a bundle (i.e., creating an instance of its activator) may be a time
consuming process, sometimes you may want a way to start a bundle, but
defer activation until it is actually need. Thus, lazy activation allows
you to start a lot of bundles, but defer their activation. In order to
actually activate a bundle, you need some trigger. In R4.1, class
loading is currently the only defined trigger that causes deferred
activation. That's all.
-> richard
Thanks for your prompt response,
Sahoo
[1]
http://www2.osgi.org/javadoc/r4/org/osgi/framework/Constants.html#ACTIVATION_LAZY
Angelo van der Sijpt wrote:
Hello Sahoo,
The thing you're seeing is exactly what it should do. The RESOLVED
state means that, on the module layer, all the bundle's imports are
available (the manifest's ImportPackage: statements), and its exports
are done too. Now, any bundle that imports packages which are
exported by your test-bundle, can load classes from those packages.
In short, the RESOLVED state handles the package wiring, only in the
ACTIVE state all services are registered, but that has nothing to do
with the ability to load classes.
Hope that helps,
Angelo
On Jan 11, 2008, at 7:52 , Sahoo wrote:
Hi,
I am observing a strange thing. I see a bundle in RESOLVED state
even after a class has been successfully loaded from that bundle.
How is this possible? I am explicitly starting the bundle from
another bundle and loading a class using Bundle.loadClass. Based on
the following output (with annotations), I have concluded that the
class has indeed been loaded by the bundle in question.
-> Jan 11, 2008 11:32:26 AM BundleListenerImpl bundleChanged
INFO: event source= sahoo.hk2-test2 [29], type= 32 *#RESOLVED state*
Jan 11, 2008 11:32:26 AM ModuleImpl loadClass
INFO: aClass.getClassLoader() = 29.0 *#29 corresponds to my
hk2-test2 bundle which is in RESOLVED state*
-> ps
START LEVEL 1
ID State Level Name
[ 0] [Active ] [ 0] System Bundle (1.1.0.SNAPSHOT)
[ 1] [Active ] [ 1] Apache Felix Shell Service
(1.1.0.SNAPSHOT)
[ 2] [Active ] [ 1] Apache Felix Shell TUI (1.1.0.SNAPSHOT)
[ 3] [Active ] [ 1] Apache Felix Bundle Repository
(1.1.0.SNAPSHOT)
[ 4] [Installed ] [ 1] osgi-test1 (1.0.0.SNAPSHOT)
[ 28] [Active ] [ 1] osgi-hk2 (1.0.0.SNAPSHOT)
[ 29] [Resolved ] [ 1] hk2-test2 (1.0.0.SNAPSHOT) *# RESOLVED
state*
Thanks,
Sahoo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
