Steven E. Harris wrote:
"Richard S. Hall" <[EMAIL PROTECTED]> writes:
The Felix.start() method accepts a list of BundleActivator
instances. These passed in activator instances effectively become
part of the system bundle and their start()/stop() methods will be
given the system bundle's context so that they can install bundles,
register services, etc.
Oh, I completely missed that. Thanks for pointing it out. Now Felix
makes a lot more sense to me, especially from the point of view of
embedding it in an application.
On the topic of providing an activator list to Felix.start(), I notice
that SystemBundleActivator's start() method starts up all the
BundleActivators in the order they fall in the m_activatorList list.
In SystemBundle's constructor, it /appends/ activators for
PackageAdmin, StartLevel, and URLHandler services to the list provided
by the caller to Felix.start(). This means that
SystemBundleActivator.start() starts up the user-provided bundles (or
just BundleActivators) before these three (for now) system-provided
BundleActivators.
While I understand that bundles must expect services they rely on to
come and go, it might make for an easier start up if the user-provided
BundleActivators were started /after/ the system-provided ones. That
is assuming that any user-provided bundles would rely on services or
capabilities provided by the PackageAdmin, StartLevel, or URLHandler
BundleActivators.
Yes, they could probably be appended, however, I don't really see this
as critical, nor will it really resolve anything for you. For example,
URL Handlers can be disabled in the configuration file and I always
thought that it would be a nice long-term goal if we could find a way to
provide these services as framework extensions so that people could
easily only deploy them if they need them. So, it is probably best to
simply create your code to listen for the services appropriately.
-> richard
