Re: [equinox-dev] OSGi new startup policies

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

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