I suspect that Ben was talking about storing as "on disk" whereas you
were talking about "stashing it in a field".
Jeff
*Pascal Rapicault/Ottawa/IBM@IBMCA*
Sent by: equinox-dev-admin@xxxxxxxxxxx
07/09/2003 08:41 AM
To: equinox-dev@xxxxxxxxxxx
cc:
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
