In a dynamic system like OSGi one of the great errors you can make is
starting to control the initialization order. Due to update, things
can come and go at any time. All bundles should be written to assume
that their services could be there or not. The service binder, spring
or declarative services make this quite easy.
I have seen many projects desperately trying to control the
initialization order only to fall apart at the first update. It is
dangerous to try because it usually works in your development
environment but it becomes extremely brittle when you deploy and other
bundles start to interact as well.
A component model will only become truly reusable if components are
written in a robust way and not put unspecified requirements on the
framework.
Kind regards,
Peter Kriens
SEH> "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.
SEH> Oh, I completely missed that. Thanks for pointing it out. Now Felix
SEH> makes a lot more sense to me, especially from the point of view of
SEH> embedding it in an application.
SEH> On the topic of providing an activator list to Felix.start(), I notice
SEH> that SystemBundleActivator's start() method starts up all the
SEH> BundleActivators in the order they fall in the m_activatorList list.
SEH> In SystemBundle's constructor, it /appends/ activators for
SEH> PackageAdmin, StartLevel, and URLHandler services to the list provided
SEH> by the caller to Felix.start(). This means that
SEH> SystemBundleActivator.start() starts up the user-provided bundles (or
SEH> just BundleActivators) before these three (for now) system-provided
SEH> BundleActivators.
SEH> While I understand that bundles must expect services they rely on to
SEH> come and go, it might make for an easier start up if the user-provided
SEH> BundleActivators were started /after/ the system-provided ones. That
SEH> is assuming that any user-provided bundles would rely on services or
SEH> capabilities provided by the PackageAdmin, StartLevel, or URLHandler
SEH> BundleActivators.
SEH> In code, prepending in reverse order:
SEH> ,----[ SystemBundle.SystemBundle(Felix, BundleInfo, List) ]
SEH> | // Add the bundle activator for the URL Handlers service.
SEH> | activatorList.add(0, new URLHandlersActivator(felix));
SEH> |
SEH> | // Add the bundle activator for the start level service.
SEH> | activatorList.add(0, new StartLevelActivator(felix));
SEH> |
SEH> | // Add the bundle activator for the package admin service.
SEH> | activatorList.add(0, new PackageAdminActivator(felix));
SEH> `----
SEH> Or, if the shuffling around of array elements is onerous, one could
SEH> use a LinkedList or write it this way, appending the provided list to
SEH> the system-built list:
SEH> ,----[ SystemBundle.SystemBundle(Felix, BundleInfo, List) ]
SEH> | m_activatorList = new ArrayList(3 +
SEH> | null == activatorList ? 0 :
SEH> | activatorList.length);
SEH> |
SEH> | // Add the bundle activator for the package admin service.
SEH> | m_activatorList.add(new PackageAdminActivator(felix));
SEH> |
SEH> | // Add the bundle activator for the start level service.
SEH> | m_activatorList.add(new StartLevelActivator(felix));
SEH> |
SEH> | // Add the bundle activator for the URL Handlers service.
SEH> | m_activatorList.add(new URLHandlersActivator(felix));
SEH> |
SEH> | if (activatorList != null)
SEH> | m_activatorList.addAll(activatorList);
SEH> `----
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
