[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] policies wrt use of Bundle-ActivationPolicy

On 3/13/12 14:45 , Scott Lewis wrote:
Hi Richard,

On 3/13/2012 9:40 AM, Richard S. Hall wrote:
<stuff deleted>

To be clear, this has nothing to do with running on other framework impls, it is an artifact of using a lazy activation policy. If you have a bundle that is lazy and other bundles are waiting for it to do something in order to proceed and they do not trigger a class load on the lazy bundle, then they will wait forever. This is true on any OSGi framework since R4.1.

Thanks Richard...that's understood (by me). The use case described in [1] is where the bundles are being started via


which, if the bundle has BAP: lazy set (as many of our bundles currently do), then the bundle is not actually started by this call (on whatever framework). This is the behavior that the bug author wants changed (via removal of BAP: lazy)...for some of our remote service impl bundles.

So my main question is: what are Equinox's (Eclipse's) policies/guidelines/requirements WRT BAP: lazy usage?

Right. And I can't answer that aspect.

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?

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 be processed.

You just need to think of how your bundles are or can be used to know if lazy policy is right for them.

-> richard



_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/equinox-dev