tag:blogger.com,1999:blog-18772002.post7316174311521912257..comments2023-12-06T19:00:46.094+00:00Comments on OSGi Blog: Best Practice with Depressed BundlesJürgen Alberthttp://www.blogger.com/profile/02725834158183495837noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-18772002.post-60190639651176491612008-02-04T14:12:00.000+00:002008-02-04T14:12:00.000+00:00I think the term "execute code" is quite confusing...I think the term "execute code" is quite confusing and probably a bit of a strong statement in this context. The only thing stopping a bundle does is call the BundleActivator stop method and invalidate the BundleContext. If a bundle does not behave properly with respect to cleaning up services/resources/threads etc. then it does not matter if it stops itself or another bundle stops it. In bothThomas Watsonhttps://www.blogger.com/profile/14853078142946210604noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-35311935438501354262007-07-16T12:45:00.000+00:002007-07-16T12:45:00.000+00:00I agree it is not a clean solution but I really do...I agree it is not a clean solution but I really do not know a better one. The garbage collection model make this code work but if the programmer did more things after the start() call, he would be screwed as well. Nasty problem.Peter Krienshttps://www.blogger.com/profile/11373850803487010328noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-34155416193585448732007-07-16T08:14:00.000+00:002007-07-16T08:14:00.000+00:00Now I am confused: how does that make sure I am no...Now I am confused: how does that make sure I am not executing any code after the thread.start() call? And wouldn't that code pose the same problem?hn3000https://www.blogger.com/profile/07431323570804618720noreply@blogger.com