Felix Meschberger wrote: > 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. This is where I was getting at. I was assuming that there was an external process that started the whole thing and stopped it after bundles are deployed. Apparently, there is only a single queueHandler thread which handles the events. I must be missing something. >> 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. Right. I also do the same for bundles that we regard as plugins (based on our definition) since we added more "phases" to the plugin's lifecycle. My question is how does the installer handle direct and indirect dependencies if those dependencies are also required to be updated? > Regards > Felix Thanks again. Rick
