Hi Sahoo, Am Mittwoch, den 02.04.2008, 11:43 +0530 schrieb Sahoo: > Now coming to the point of why users care, as Stuart rightly pointed > out, users who embed Felix in their application don't want the > application to hang around even after all the application threads are > gone. Today to ensure that, they have to rely on an undocumented feature > (i.e. option #1).
In a traditional application you are absolutely right, and I would mark all threads there as daemon threads unless they do very specific tasks. For this reason I mark my threads as daemon threads. Now for an OSGi framework the situation is different: as I said, the bundle starting the thread should also stop it. Thus if you stop the framework correctly, which is what I assume, there will be no framework threads be hanging around after the framework terminated. Hence it is of no importance of whether the threads were daemon or non-deamon threads. If you OTOH do not shut down the framework before trying to shutdown your application in which the framework is embedded, well, yes, you are not behaving correctly, if I may say so ;-) Now, I try to imagine a situation, where you do not shutdown the framework and do not call System.exit() but just terminate all non-daemon thread to terminate the application. In this case of course, it is important to know whether any threads are started by the framework - or any bundle at all, because EventAdmin is implemented in a real separate bundle - are daemon or non-daemon. Is this your use scenario ? Actually, this scenario leads me to think that the event admin should define the threads as daemon threads for clarity and not have a configuration option or a documented state. Because the documented behaviour is to just stop the bundle to shutdown ;-) Regards Felix --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
