From: Richard S. H. <he...@un...> - 2004-06-01 08:09:14
|
Manuel Santillan Palencia wrote: >I've already used a similar approach, by extracting all the problematic >code from bundle B and putting it in a bundle event listener which >executes itself when the bundle B is already started. > >The thing is that if bundle B is in INSTALLED, RESOLVED OR STARTED >state, then there is no problem in bundle A accesing a class from bundle >B. However, if bundle A tries to access a class exported when bundle B >is STARTING, he won't be able to do it. Is this the correct way of >acting? Or should bundle A be able to access bundle B classes at any >time? > > I think that Michel is correct when he states that it has nothing to do with the STARTING state, however, it could very likely be an Oscar issue in some respects. Oscar has to do some sanity locking so that it can ensure that refreshes don't happen in the middle of other operations, for example. It is difficult to explain the approach, but Oscar uses two locks, where one is intended for simple operations and one is intended for adminstrative operations. An administrative operation can ensure complete mutex by getting both locks. So what do I guess is happening in your case? Well, I haven't used RMI in a long, long time, but if I remember correctly, it uses threads. Most likely, Oscar calls out to your code, which then calls back into Oscar on a different thread trying to access the other bundle, which creates some sort of cycle. My guess is you could recreate the problem without RMI, but by just creating a separate thread that tries to load the class. >I mean, I 've already found workarounds for this problem. But I do not >know if this is a bug (and therefore should need a fix) or is it just >the way the spec says it should work. :) > If you can create a small example that demonstrates the problem, I will look into whether/how it is possible to loosen the concurrency control, but this is a very tricky issue. Obviously, Oscar cannot necessarily deal with people grabbing its thread in callbacks and then sending in a new thread. -> richard |