>> "storing it will do no good"
The BundleContext object of a bundle is valid only when the
bundle is in STARTING, ACTIVE and STOPPING state
In all other states all its methods should cease to work (i.e.
So storing it is reasonable as long as the bundle is in one of
the listed states.
1. start the bundle
state is STARTING for some time bundle context is
bundle state becomes ACTIVE
BundleContext object is valid here
BundleContext object is still valid here
2. stop the bundle - state is STOPPING for some time -
BundleContext is still valid here.
bundle state becomes RESOLVED or INSTALLED - BundleContext
object is NOT valid here
using the BundleContext after this point is not correct and
should not be done (it will do no good too).
If the bundle is started again then a new BundleContext object
will be created and it should be used
>> "you usually [make the context accessible to other
Yes, but to objects inside the bundle to
which the BundleContext belongs. Passing this object outside the
bundle is a bad practice however should not do any harm to the
----- Original Message -----
Sent: Wednesday, July 09, 2003 3:41
Subject: Re: [equinox-dev] [OSGi]
practices with the bundle context
It seems to me that there is something contradictory in
what you said:
"storing it will do no good"
"you usually [make the context accessible
to other objects]"
There is only
two times you can get the context (start / stop), so how do you make it
to other part of your
bundle, if you do not store it?
Does the spec specify something about the life time of the
07/08/2003 07:30 PM
Re: [equinox-dev] [OSGi] practices with the bundle context
are the regular practice with the bundleContext?
> Do you
No, it is a transient object, so storing it will do no
> Do you make it accessible to other classes in
Yes, usually you do. It is important though not to let a
leak out to other bundles. The BundleContext is a bundle's
the framework, so a bundle can masquerade as another bundle
if it has
that bundle's BundleContext.
> Do you
surface some of its API in the activator and store the
I wouldn't surface the API in the activator, but certainly
surface some of the functionality in other objects. Often though
just end up passing around the BundleContext.
> Basically it
offers a lot of functions that are interesting to install
and get information about the platform.
> So how am I supposed to
proceed for other classes of my bundle to use
Except for instances where the BundleContext may leak to
I wouldn't feel bad about passing around the