[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] OSGi new startup policies

You are correct, John. It is indeed incorrect to assume that bundles
without activator are only providing resources (files/classes).

I think that I will quit on this. My proposal should be enhanced to
check for both Bundle-Activator and Bundle-ActivationPolicy and act
accordingly just for the ease of deploying framework startup bundle (if
I can it this way). It is becoming more complicated than necessary, so
unless activating all bundles is considered, I think Thomas' proposal is
the better one.


John Wells wrote:
> Be careful about assuming that bundles with no activator only provide
> resources.  Bundles using DS or Spring or other IoC technologies
> (especially with the new getBundleContext method on the Bundle) *may*
> offer services even if they do not have an activator. 
> John Wells (Aziz)
> jwells@xxxxxxxxxxxxx
> -----Original Message-----
> From: equinox-dev-bounces@xxxxxxxxxxx
> [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Danail Nachev
> Sent: Monday, February 19, 2007 3:44 AM
> To: Equinox development mailing list
> Subject: Re: [equinox-dev] OSGi new startup policies
> I must agree that this is a drastic change. However, I think it won't
> affect most of the bundles and plugins out there, because they already
> have lazy activation policy. The remaining bundles are those that
> provides only resources and doesn't have an activator, so we can
> distinguish them and don't call start() on them. This way I think we
> will keep the backward compatibility.
> Also there are one small group of bundles, which should participate in
> the framework startup. These bundles must be activated persistently. It
> is no problem when you control the platform, but it is a problem when
> you provide your bundles via Update Site, because you have to do magic
> to change the osgi.bundles property and it is ugly solution. Is there
> are a way that this can happen beside the Workbench's IStartup mechanism
> (which is not suitable for all the cases) and osgi.bundles property?
> I realize that this is a rare solution, so I won't argue much about it
> and will look for other solutions.
> Thomas Watson wrote:
>> I opened the following bugs:
>> Platform->Update https://bugs.eclipse.org/bugs/show_bug.cgi?id=174334
>> Equinox->Framework 
>> Equinox->https://bugs.eclipse.org/bugs/show_bug.cgi?id=174335
>> See comments below:
>> equinox-dev-bounces@xxxxxxxxxxx wrote on 02/15/2007 08:45:20 AM:
>> I'm not sure we want to change the behavior of update to eagerly start
>> bundles which do not define the "lazy" activation policy.  I agree 
>> that it may not be a performance issue if the bundles do not have an 
>> activator but this is still a pretty drastic change in behavior from 
>> before where no bundles were started.  I do agree that 
>> update.configurator should at least call 
>> start(START_ACTIVATION_POLICY) on bundles that declare a lazy 
>> activation policy.  These are for bundles that define the following 
>> headers
>> Eclipse-LazyStart: true
>> Eclipse-LazyStart: false; exceptions=<some package list>
>> Bundle-ActivationPolicy: lazy
>> There is also the deprecated Eclipse-AutoStart that is the same as 
>> Eclipse-LazyStart
>> Today this is still working because Equinox has a compatibility 
>> setting that is enabled by default to automatically start all bundles 
>> with the START_ACTIVATION_POLICY if they define a lazy activation
> policy.
>> That is why lazy activated bundles are able to start even though
>> Bundle.start(START_ACTIVATION_POLICY) was not called.
>> We should probably use the same policy as update.configurator here.
>> If 'start' attribute is used the do the normal start(0) otherwise call
>> start(START_ACTIVATION_POLICY) if it is appropriate (i.e. the bundle 
>> has a lazy activation policy).
>> ----------------------------------------------------------------------
>> --
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> --
> -------------------------------------------------
> Danail Nachev . Software Engineer/Development Tools ProSyst Labs EOOD
> 1606 Sofia, Bulgaria . 48 Vladajska Str.
> Phone:  +359 (0)2 952 35 81/102 . Fax +359 (0)2 953 26 17
> http://www.prosyst.com . d_nachev@xxxxxxxxxx
> -------------------------------------------------
> stay in touch with your product.
> -------------------------------------------------
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________________________________
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev