RE: [equinox-dev] OSGi new startup policies

["John Wells" <jwells@xxxxxxx>]

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@bea.comNOSPAM


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