Hi RIck, Did you envision running the
AssemblyManager constantly or is it "activated" as a one-time process and stopped after the process has accomplished its mission and repeated only when necessary?
The background thread is started and stopped by the bundle activator. Normally, it just sits and waits for events coming in. The reason for using a separate thread is, that (1) I do not want to block the Framework Event Queue and (2) installation and deinstallation actions may be launched, which might cause issues like deadlocks if ran synchronously. And yes, the actual installation by the Installer retrieved from the InstallerService runs in the background, which - currently - is a new thread each time bundles are installed or uninstalled. Also, could the more simple "visitor pattern"
(such as Peter Kriens's FileInstaller) be sufficient to detect and process the assembly bundles?
I do not quite understand that. AFAIK the FileInstaller sits and looks at file system locations and installs bundles as they come and uninstalls them as the corresponding file goes away, right ? This is more or less, what I do. I just add more fine grained control, in that I support more conrol over the lifecycle of bundles contained in assemblies, like starting and stopping. It is the task of the background thread to react to BundleEvents of the assembly bundles. Regards Felix
