> 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 ;-)
I think he is talking about the EventDispatcher which is a framework internal class not related to the EventAdmin. > Regards > Felix Sahoo, we do want the framework to inherit the status of the thread it has been created with. That doesn't prevent any installed bundle from running a none daemon threads so -- hence, as Felix points out, the correct way to shutdown the framework is to stop the system bundle so that all bundles get stopped and get a chance to clean-up their threads. I agree that we should document this some place. regards, Karl -- Karl Pauls [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
