[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] policies wrt use of Bundle-ActivationPolicy
- From: Scott Lewis <slewis@xxxxxxxxxxxxx>
- Date: Tue, 13 Mar 2012 12:15:32 -0700
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
On 3/13/2012 11:58 AM, Richard S. Hall wrote:
However, I can talk about general OSGi policy: If your bundle is
expected to provide functionality to client bundles and client bundles
can reasonably expect to obtain (or witness or whatever) your provided
functionality without being required to explicitly class load from
your bundle, then you should not use lazy policy. Does that make sense?
Yes. The functionality at issue here is remote services/RSA...where
the service hosts expect to be able to call
and have some topology manager be previously started...and with service
hook export the service for remote access as part of the registerService
On the service consumer side it's trickier, because in at least some
cases people expect to have the remote service be discovered (via some
network discovery provider) as soon as things start. This is also the
case in , for example.
The simplest example is a bundle that provides a service and imports
its service package. If this bundle is lazy, then its service will
never be provided because an explicit class load will never be
triggered on it. This is not limited to providing services, though.
For extenders, if they are lazily started but extendees do not
explicitly load classes from the extender, then extensions may never
yes...this is exactly the case with remote services I would say.
You just need to think of how your bundles are or can be used to know
if lazy policy is right for them.
Right...I agree...thanks. I hope that's what we're doing with . The
tricky bit (as usual) is knowing how/can people are using our stuff.