When a bundle is stopped, it should stop all of its thread before
returning from stop()...even if those threads have been started by
libraries being used by the bundle and not the bundle directly.
-> richard
On 7/3/12 5:15, Dan Gravell wrote:
Well that's interesting.
I added a bundle listener before my deploy call, and also changed the
deploy to run inside a thread. And now it works. Every time. I guess it's
running it in a separate thread that works?
I do still get these NPEs:
Exception in thread "pool-66-thread-2" java.lang.NullPointerException
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
at
net.liftweb.actor.LAScheduler$$anonfun$9$$anon$2$$anon$3.run(LiftActor.scala:66)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
Exception in thread "pool-66-thread-4" java.lang.NullPointerException
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
at
net.liftweb.actor.LAScheduler$$anonfun$9$$anon$2$$anon$3.run(LiftActor.scala:66)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
... however I think they may be related to old threads from the closed-down
old instance of the UI. They appear to be benign if unsightly.
For the refresh call, I have written my BundleListener so that it counts up
the Bundles that go into STOPPED state and then once each of them are
STARTED again I run the refresh. I suppose another way of doing it would be
to get the Requirements from the Resolver and wait for them to be UPDATED.
The way I'm currently doing it may conflict if other bundles were being
STARTED and STOPPED at the same time, but this is a simple,
single-user-and-app environment rather than an app server or anything like
that so I'm happy with that for now (unless anyone sees any obvious flaws
I'm missing).
Dan
On Tue, Jul 3, 2012 at 9:17 AM, Dan Gravell
<[email protected]>wrote:
Thanks for the offer Richard. I'm going to do some more digging on the
threading side of things, as you advised in your follow up. At the same
time I also discovered
http://blog.osgi.org/2007/07/best-practice-with-depressed-bundles.html last
night which made me think I need to think more about the threading going
on. There are a number of threads in my app including from the UI which the
source of the deploy() call. The UI is web based; the actual call comes
from a Scala actor (it's using the Lift framework).
If I make no further progress I'll try to create a few bundle for you to
take a look at. Assume you need the source too...
Dan
On Mon, Jul 2, 2012 at 8:46 PM, Richard S. Hall <[email protected]>wrote:
Seems like this could take forever...perhaps you can create a scaled down
example you can email me to reproduce the issue.
-> richard
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
