Re: [equinox-dev] Regarding Lazy Activation

[Neil Bartlett <njbartlett@xxxxxxxxx>]

A lot of Eclipse bundles use "Bundle-ActivationPolicy: lazy". That's
because they want to have Bundle-Activators *AND* have those bundles
be free to start (also known as "having their cake and eating it"!)

But frankly it's just for legacy reasons. If you're creating a new
bundle using DS, you don't need a Bundle-Activator. Eclipse bundles
often have activators for two reasons:

1. Legacy. Many of these bundles have been around for over ten years
and are too hard to change without breaking existing users.

2. Tooling. Eclipse PDE by default creates new plug-ins with
activators. I've already stated elsewhere that I think this is a dumb
idea!

Incidentally, though the bundles are listed as having state
"<<lazy>>", there is really no such state. They are actually suspended
in the STARTING state.

Regards
Neil


On Fri, Feb 18, 2011 at 10:10 AM, ajinkya prabhune
<ajinkya.prabhune@xxxxxxxxx> wrote:
> Hi,
> Thanks a lot... for such a fast reply.
> Ok I get the concpet.
> You are correct I was trying to avoid the large overhead and the  time
> required of starting all
> the bundle during the launch of the Framewrok..
> So I guess now they all need to be started...
> A small doubt what does the <<lazy>> atrribute means in the osgi eclipse
> console... its making me quiet confusing.
>
> Thanks and regards
> Ajinkya
> On Thu, Feb 17, 2011 at 11:54 PM, Neil Bartlett <njbartlett@xxxxxxxxx>
> wrote:
>>
>> Nope it won't work like that. DS will never look at a stopped
>> bundle... even with the "lazy activation" policy, it only looks at
>> bundles in the ACTIVE or STARTING states.
>>
>> Instead, turn the problem around: why is A stopped? Why not just start
>> all bundles?
>>
>> You are probably worried about startup time of your application;
>> that's a completely valid concern. But rather than trying to avoiding
>> starting bundles and then asking DS to look at unstarted bundles,
>> instead we make it (essentially) free to start bundles.
>>
>> How do we get bundles that are "free" to start? Just don't declare a
>> Bundle-Activator.
>>
>> Regards,
>> Neil
>>
>> On Thu, Feb 17, 2011 at 10:01 PM, ajinkya prabhune
>> <ajinkya.prabhune@xxxxxxxxx> wrote:
>> > Hi Neil,
>> >
>> > I agree but what I mean is...
>> > Bundle A has the service which Bundle B refers...
>> > (Bundle A is stopped)
>> > what I intend to do is when I start Bundle B it should look up and
>> > recognize
>> > that
>> > it refers to Bundle A for a service... but Bundle A is stopped so is
>> > there a
>> > possibility to start the Bundle A at that moment.
>> >
>> > If I am wrong somewhere wrt to DeclarativeServices ... please let me
>> > know...
>> >
>> > Thanks and Regards
>> > Ajinkya
>> >
>> >
>> >
>> > On Wed, Feb 16, 2011 at 3:48 PM, Neil Bartlett <njbartlett@xxxxxxxxx>
>> > wrote:
>> >>
>> >> Answer inline below...
>> >>
>> >> On Wed, Feb 16, 2011 at 2:36 PM, ajinkya prabhune
>> >> <ajinkya.prabhune@xxxxxxxxx> wrote:
>> >> > Hello,
>> >> >
>> >> > Super help from both of u. I am now gng through the articles and
>> >> > seeing
>> >> > how
>> >> > it works...
>> >> >
>> >> > Yes I am trying to use a Service declared in A bundle --- to use in B
>> >> > bundle...
>> >> >
>> >> > Can I make the A Bundle As Lazy so that when B bundle ask for service
>> >> > in
>> >> > A
>> >> > ... the A bundles gets Active and Registers the Service
>> >> > will this work ?
>> >>
>> >> No, this is not what "lazy activation" in OSGi is for. It has nothing
>> >> to do with services.
>> >>
>> >> Declarative Services provides the right kind of laziness. If you
>> >> define a component in B that has a mandatory reference (i.e.
>> >> cardinality 1..1 or 1..n) to the service published from A, then it
>> >> will only create the component when the service becomes available,
>> >> which would be after A is activated.
>> >>
>> >> In most cases the "lazy activation policy" is not required and is IMHO
>> >> an annoying distraction. All you really need is the following:
>> >>
>> >> 1) Create a DS component and declare it with a component.xml file
>> >> 2) Do NOT create a BundleActivator... you don't need it when using DS.
>> >> 3) Start both bundles A and B, in any order.
>> >>
>> >> Cheers,
>> >> Neil
>> >>
>> >> >
>> >> > Thanks for ur quick reply...
>> >> >
>> >> > On Wed, Feb 16, 2011 at 3:32 PM, Neil Bartlett <njbartlett@xxxxxxxxx>
>> >> > wrote:
>> >> >>
>> >> >> Ajinka,
>> >> >>
>> >> >> Do not do this. It is a common newbie mistake: there should be no
>> >> >> start-ordering dependency between bundles.
>> >> >>
>> >> >> You do not state *why* you want B to start after A has started. I
>> >> >> assume that you want to publish a service from A and consume it from
>> >> >> B? The correct way to do this is have B *listen* for the
>> >> >> availability
>> >> >> of the service it needs to use, then A and B can be started in any
>> >> >> order.
>> >> >>
>> >> >> As Petar points out, using Declarative Services (DS) is a much
>> >> >> easier
>> >> >> way to implement services, since it takes care of all the aspects of
>> >> >> listening for availability etc. I strongly recommend that you use DS
>> >> >> instead of coding against the low-level OSGi services APIs.
>> >> >>
>> >> >> Regards,
>> >> >> Neil
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Wed, Feb 16, 2011 at 1:36 PM, ajinkya prabhune
>> >> >> <ajinkya.prabhune@xxxxxxxxx> wrote:
>> >> >> > Hello,
>> >> >> >
>> >> >> > I am quite new to the concept of OSGi and bundles.
>> >> >> > I have this issue.
>> >> >> > For eg - I have 2 bundles
>> >> >> > Bundle A and Bundle B,  Bundle A depends on Bundle B
>> >> >> > But I want to start Bundle B only when Bundle A is started...
>> >> >> > what are the ways to do it ? I manually found out the Bundle B
>> >> >> > using
>> >> >> > the
>> >> >> > Bundle object and started the Bundle B with bundle.start() but I
>> >> >> > would like to do it without the Java Code. can the Framework Help
>> >> >> > me.
>> >> >> >
>> >> >> >
>> >> >> > I am not sure but how does Bundle ActivationPolicy lazy works ?
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Thank u and regards
>> >> >> >
>> >> >> > --
>> >> >> > Thank you and Regards
>> >> >> > Ajinkya Prabhune
>> >> >> >
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > equinox-dev mailing list
>> >> >> > equinox-dev@xxxxxxxxxxx
>> >> >> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
>> >> >> >
>> >> >> >
>> >> >> _______________________________________________
>> >> >> equinox-dev mailing list
>> >> >> equinox-dev@xxxxxxxxxxx
>> >> >> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Thank you and Regards
>> >> > Ajinkya Prabhune
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > equinox-dev mailing list
>> >> > equinox-dev@xxxxxxxxxxx
>> >> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
>> >> >
>> >> >
>> >> _______________________________________________
>> >> equinox-dev mailing list
>> >> equinox-dev@xxxxxxxxxxx
>> >> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>> >
>> >
>> >
>> > --
>> > Thank you and Regards
>> > Ajinkya Prabhune
>> >
>> >
>> > _______________________________________________
>> > equinox-dev mailing list
>> > equinox-dev@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
>> >
>> >
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
>
> --
> Thank you and Regards
> Ajinkya Prabhune
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>