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


This is a good thread.  It would seem that we will have some compatibility issues to work through.  Of course, if someone has Eclipse-LazyStart then we can still start them automagically.  For people looking to get on the new/standard header though we should make it possible/easy.

Perhaps there should be a bug opened to track this? (what release/build should we target for the changes?)  Here are some random thoughts about the scope of change
- bundles installed by update.configurator
- bundles installed by osgi.bundle
- people looking at the state of bundles to decide what to do (e.g., some people were previously looking and starting the bundle if it was in Resolved state).  Now they will not get quite what they expected/wanted...

Jeff



Danail Nachev <d_nachev@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

02/12/2007 04:55 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject
Re: [equinox-dev] OSGi new startup policies





I think that the problem with the current update.configurator and new
OSGi activation policy is that the bundles' start() method must be
called, in order to be able to activate them. Before OSGi R4.1, the lazy
activation occurred automatically. For R4.1, the update.configurator
will need to call start() with parameter to use the bundle's activation
policy. Am I correct?

What about the bundles in osgi.bundles property. These with start
attribute will be eagerly started, but for the remaining there isn't
code which will bring them in started state.

Danail

Thomas Watson wrote:
>
> I missed this question down in my inbox, sorry for the late response.
>
> What did you have in mind for update.configurator and application
> shutdown?  Currently update.configurator has no notion of an
> application.  It just follows some policy to install a set of bundles.
>  In 3.3 M5 there are two ways an eclipse application can shutdown.
>
> 1) It chooses to exit.  In the case of the SDK workbench this is user
> driven (i.e. the user decides to use File->Exit).
> 2) The ApplicationHandle.destroy() method is called, this eventually
> causes the application's implementation of IApplication.stop() to be
> called which should force the application to exit.
>
> In both cases this causes the Framework to proceed with shutdown and
> exit, update.configurator does not have to do anything.  This is the
> default behavior for the eclipse application container.  There are
> additional configurations available to allow multiple eclipse
> applications to be launched and shutdown without causing the framework
> to shutdown.  Even in this case I do not see how update.configurator
> would get involved unless you want update.configurator to be the one to
> decide what applications to run and to make the decision of when to exit
> the framework.  Currently we do not have such a bundle making these
> types of decisions.  We only have the notion of a default application
> that is run on startup.
>
> Tom
>
>
>
> *Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>*
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
>
> 02/05/2007 09:25 PM
> Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
>
>                  
> To
>                  equinox-dev@xxxxxxxxxxx
> cc
>                  
> Subject
>                  [equinox-dev] OSGi new startup policies
>
>
>                  
>
>
>
>
>
>
> Even though the changes coming down from OSGi around bundle activation
> should be backward compatible, I wonder if there is anything that should
> be done in update.configurator and the way we shutdown the application?
>
> PaScaL_______________________________________________
> 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

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