Thanks for the answers! Regards, Per-Erik Svensson
On Fri, Jan 21, 2011 at 4:35 PM, Richard S. Hall <[email protected]>wrote: > On 1/21/11 3:29, Per-Erik Svensson wrote: > >> Thanks! All that makes sense, and I guess the problem is that the swing >> worker switches to its done method (to the edt) when cancelled. I have no >> good (read easy) way of synchronizing the bundle.stop() with this. >> >> But, do I understand you correctly if I say that you can (and should) >> block >> inside bundle.stop until all threads have finnished? What happens with >> Felix's other responsibilities in the mean time? Do all "pending" service >> requests and bundle events (stopping, starting..) block? What is the >> thread >> "rules" when it comes to OSGi? >> > > Yes, some things will block. > > The rules dictate you should be quick in your stop(), but at the same time > the rules dictate that your bundle should be stopped after stop() (i.e., > your bundle shouldn't be doing stuff on background threads). > > -> richard > > > Regards, >> Per-Erik Svensson >> >> On Fri, Jan 21, 2011 at 1:57 AM, Richard S. Hall<[email protected] >> >wrote: >> >> On 1/20/11 6:02 PM, Per-Erik Svensson wrote: >>> >>> Hi, >>>> >>>> I would like to know when a class is loaded. I guess it is a bit >>>> different >>>> depending on things like usage of static members and the like but... Say >>>> java.util.Logger. I have a bundle that only consumes services. When the >>>> bundle is started it is running a few background threads. When the >>>> bundle >>>> is >>>> stopped, the background threads are cancelled. When they are cancelled, >>>> they >>>> will post a task on the event dispatch thread (I'm using swing workers) >>>> and, >>>> since they were cancelled, they will log just that ("Background thread >>>> interrupted" or similar is written to log). >>>> >>>> Now, everything worked fine up until the edt-task was about to log. At >>>> that >>>> point, felix threw an exception. Sadly, I don't have the stack trace atm >>>> and >>>> I'm not sure I can reproduce. I'm just curious if anyone knows what this >>>> can >>>> be. The offending line was calling >>>> >>>> java.util.Logger.getLogger(getClass().getName()).log(Level.INFO, >>>> "BG-thread >>>> cancelled) //or similar >>>> >>>> And remember that the bundle jar-file has been removed (with the help of >>>> FileInstall) from the system. It might linger in the bundle cache (I >>>> don't >>>> know how long it stays there) but the bundle is stopped and (presumably) >>>> uninstalled. >>>> >>>> I just removed the logger code to make it work. However, I'm suspecting >>>> that >>>> the cause of the error is either >>>> >>>> 1. getClass() must have a class loader and that is gone because the >>>> bundle is uninstalled. >>>> >>>> If you have a thread executing on the class, then the class loader >>> isn't >>> gone since the thread has a reference to the class and the class has a >>> reference to its class loader. >>> >>> 2. The static Logger isn't loaded yet or uses classes that aren't >>> >>>> loaded >>>> >>>> yet and thus felix informs me that it cant find the class. >>>> >>>> Something like this could be. >>> >>> >>> So, (a) when is a class loaded, (b) is there any good "pattern" for >>> >>>> dealing >>>> with disposing threads in OSGi, and (c) am I completely off here? :) >>>> >>>> For (a) it just depends. They are loaded on demand by the JVM. In some >>> cases loading a class will cause other class loads for dependent types >>> necessary for defining the class. For types used in methods, they will be >>> loaded on demand (although I'm not sure if this is mandated). >>> >>> For (b), the best you can do is stop your threads in your activator >>> stop() >>> method. Your bundle will not be uninstalled until after it returns from >>> its >>> stop() method. In Felix, we don't hold locks for class loading, so you >>> can >>> end up with situations were threads will have issues loading classes from >>> a >>> dependent bundle, but they won't have problems loading classes from >>> themselves as long as they are stopped in their activator stop() method. >>> >>> -> richard >>> >>> >>> Ok, (d) would it help writing "MyClass.class.getName()"? >>> >>>> Regards, >>>> Per-Erik Svensson >>>> >>>> >>>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
