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]
