|
Hi
>> "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.
throw IllegalStateException).
So storing it is reasonable as long as the bundle is in one of
the listed states.
Example:
1. start the bundle
state is STARTING for some time bundle context is
valid
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
objects]"
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
framework.
Best regards
Vasil
----- Original Message -----
Sent: Wednesday, July 09, 2003 3:41
PM
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
available
to other part of your
bundle, if you do not store it?
Does the spec specify something about the life time of the
object?
PaScaL
|
| Benjamin
Reed/Almaden/IBM@IBMUS
07/08/2003 07:30 PM
|
To:
Pascal Rapicault/Ottawa/IBM@IBMCA
cc:
equinox-dev@xxxxxxxxxxx
Subject:
Re: [equinox-dev] [OSGi] practices with the bundle context
|
> What
are the regular practice with the bundleContext?
> Do you
store it?
No, it is a transient object, so storing it will do no
good.
> Do you make it accessible to other classes in
the bundle?
Yes, usually you do. It is important though not to let a
BundleContext
leak out to other bundles. The BundleContext is a bundle's
interface to
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
> activator
somewhere?
I wouldn't surface the API in the activator, but certainly
you may
surface some of the functionality in other objects. Often though
you
just end up passing around the BundleContext.
> Basically it
offers a lot of functions that are interesting to install
> bundles,
and get information about the platform.
> So how am I supposed to
proceed for other classes of my bundle to use
> those
facility?
Except for instances where the BundleContext may leak to
other bundles,
I wouldn't feel bad about passing around the
BundleContext.
ben
| 