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 > >
