Community
Participate
Working Groups
Because of changes around the activation of bundles in 4.1 spec, the simple configurator needs to be changed to call the appropriate start() method. Similar code is available in update.configurator.ConfigurationActivator
See related bug 174334. (code for ConfigurationActivator is in the patch)
I'll take a look at porting the fix from update.configurator to simple configurator. Without this fix Eclipse will not start if you set the configuration property osgi.compatibility.eagerStart.LazyActivation=false.
Created attachment 122820 [details] patch Here is a patch that ports the fix from update.configurator over to simple configurator. I parsed the headers using private code (instead of ManifestElement) to avoid a dependency on org.eclipse.osgi. With this patch applied the platform can be launched with the option "osgi.compatibility.eagerStart.LazyActivation=false" set. Without this fix none of the lazy activated bundles will get activated on first class load.
Rather than having to parse the manifest, we should leverage the opportunity to have the bundles.info and store this kind of information there.
I agree it would be nice if the bundles.info contained this information. Currently bundles.info just has a boolean indicating if the bundle should be persistently started or not. It would be nice if this could be expanded to starting with some start options. I'm not familiar with the code that manages the bundles.info file. Would this code parse the headers to get the correct thing in the bundles.info or would this need to be tied to IUs. Would this happen automatically or would IU authors need to configure this for each bundle similar to how they do for persistently starting bundles?
Tentatively marking for 3.6.
In Bug 491606 once more the discussion regarding automatic activation of bundles was started. I don't know much about the state of this ticket. From my point of view it should be possible to specify some configuration to automatically start a bundle based on its activation policy. Felix for example can be configured via the following configuration properties in case org.apache.felix.bundlerepository is used: # The following property determines which actions are performed when # processing the auto-deploy directory. It is a comma-delimited list of # the following values: 'install', 'start', 'update', and 'uninstall'. # An undefined or blank value is equivalent to disabling auto-deploy # processing. felix.auto.deploy.action=install,start # Sets the start level of newly installed bundles. felix.startlevel.bundle=1 And additional properties to configure on a bundle level (which is similar to what is available via bundle.info or osgi.bundles in Equinox). Adding such configuration options somehow would leave it up to the developer how the bundle startup scenario should look like (automatically start all or only start necessary like currently). If I understand correctly the simpleconfigurator is part of p2. The Equinox Quick Start suggests the usage of org.eclipse.update.configurator [1] which works fine for my simple plain OSGi showcases. Honestly I don't know much about the differences and the state of p2 in general. But for plain OSGi on Equinox I don't need the p2 stuff as far as I understand. Therefore such a configuration would be useful in both cases. BTW I also noticed that the Felix configuration above does not respect the lazy activation policy and simply activates all bundles. IMHO that is wrong in Felix, but honestly I'm not sure. I would expect that bundles are started according to their activation policy. [1] https://www.eclipse.org/equinox/documents/quickstart-framework.php
If this issue is current, can someone explain what all needs to be done?
(In reply to Ed Merks from comment #8) > If this issue is current, can someone explain what all needs to be done? At a minimum p2 should determine which bundles have the lazy activation policy and p2 should mark these bundles as started, using their activation policy. But in my opinion the correct thing to do is to always start all bundles according to their activation policy. The case for installing a bundle but not activating it is pretty weak. If you don't want the functionality of the bundle you should not have it installed. But at this point in the life of p2 and Eclipse I fear such a change to the default behavior will be unexpected. Therefore I think we should, do the minimal thing if we do anything here. That is what my original patch from 2009 did. At that time Pascal wanted a general way to encode that lazy information in the bundles.info file. But I think that is a more complicated approach. The fact of the matter is, currently p2 and Eclipse in general is depending on this unspecified Equinox behavior where the Framework will auto-start any lazy activation bundle even when nothing has called Bundle.start on that bundle. p2 should at least explicitly start (with activation policy) the lazy activated bundles. This still makes it rather difficult for "normal" bundles to get activated when managed by p2 because they are required to have this extra CU to mark them as eagerly activated. It would have been far more simple if p2 would have just marked all installed bundles to be started according to their activation policy right from the beginning. But I think the ship has sailed on our ability to change that default behavior.
