Oh I'm ~95% certain I'm doing something wrong ;) I haven't seen a walkthrough yet of writing this kind of code, so I've been going by the OSGi spec, Javadocs and piecing together other mailing list posts to try to work out what I need to call. Hence my other question about how update is "meant to be done" in multi bundle environments. Any link to non trivial examples are gratefully appreciated.
Anyway, these errors appear before refreshBundles is called... they are as a result of the OBR deploy call. Although I refactored the updater into its own bundle, the update routine is being called from a bundle that is being updated, specifically the user interface where the user clicks 'Update'. The NPE stack trace shows the UI being used before update. The same thread from the old UI has updated the bundle and started the new bundle, but I guess that means the same classes for the old UI are being used, hence the casting problems? However, I can't *not* update the UI, it's a core part of my app that I want to update, but the UI has to be used to perform the update. How would one go about this? Apologies for such noob questions. Dan On Mon, Jul 2, 2012 at 4:45 PM, Richard S. Hall <[email protected]>wrote: > I would venture to guess you are still doing something wrong...keep in > mind that the call to refreshBundles() is asynchronous, so you shouldn't > immediately try to start or do anything with your bundles. You need to give > a listener to refresh so you know when it is done. > > -> richard > > > On 7/2/12 11:35, Dan Gravell wrote: > >> So, I refactored the updater to a different bundle. Unfortunately I get >> the >> same problem. In two different runs I observed two different issues, one >> the CCE shown before, the other the LinkageError also shown before: >> >> ERROR: Resolver: Start error - com.elsten.bliss.bundle >> org.osgi.framework.**BundleException: Activator start error in bundle >> com.elsten.bliss.bundle [42]. >> at org.apache.felix.framework.**Felix.activateBundle(Felix.**java:2027) >> at org.apache.felix.framework.**Felix.startBundle(Felix.java:**1895) >> at org.apache.felix.framework.**BundleImpl.start(BundleImpl.**java:944) >> at org.apache.felix.framework.**BundleImpl.start(BundleImpl.**java:931) >> at >> org.apache.felix.**bundlerepository.impl.**ResolverImpl.deploy(** >> ResolverImpl.java:630) >> at com.elsten.bliss.updater.**OnlineUpdater.updateTo(** >> OnlineUpdater.java:48) >> at com.elsten.bliss.ui.model.**Updater$.update(Updater.scala:**17) >> at >> com.elsten.bliss.ui.comet.**Update$$anonfun$lowPriority$1$** >> $anonfun$apply$1.apply$mcV$sp(**Update.scala:75) >> at >> com.elsten.bliss.ui.comet.**Update$$anonfun$lowPriority$1$** >> $anonfun$apply$2.apply$mcV$sp(**Update.scala:72) >> at >> com.elsten.bliss.ui.comet.**Update$$anonfun$lowPriority$1$** >> $anonfun$apply$2.apply(Update.**scala:72) >> at >> com.elsten.bliss.ui.comet.**Update$$anonfun$lowPriority$1$** >> $anonfun$apply$2.apply(Update.**scala:72) >> at >> scala.concurrent.ThreadRunner$**$anon$1$$anonfun$run$1.apply(** >> ThreadRunner.scala:37) >> at >> scala.concurrent.ThreadRunner.**scala$concurrent$ThreadRunner$** >> $tryCatch(ThreadRunner.scala:**31) >> at scala.concurrent.ThreadRunner$**$anon$1.run(ThreadRunner.**scala:37) >> at java.lang.Thread.run(Thread.**java:679) >> Caused by: java.lang.LinkageError: loader constraint violation: when >> resolving method >> "com.elsten.bliss.main.Main.**getLicenceStore()Lcom/elsten/** >> bliss/licence/**PerFixLicenceStore;" >> the class loader (instance of >> org/apache/felix/framework/**BundleWiringImpl$**BundleClassLoaderJava5) >> of the >> current class, com/elsten/osgi/Activator, and the class loader (instance >> of >> org/apache/felix/framework/**BundleWiringImpl$**BundleClassLoaderJava5) >> for >> resolved class, com/elsten/bliss/main/Main, have different Class objects >> for the type com/elsten/bliss/licence/**PerFixLicenceStore used in the >> signature >> at com.elsten.osgi.Activator.**start(Activator.java:38) >> at >> org.apache.felix.framework.**util.SecureAction.** >> startActivator(SecureAction.**java:641) >> at org.apache.felix.framework.**Felix.activateBundle(Felix.**java:1977) >> ... 14 more >> >> I also get this NPE just before which doesn't appear to be related to >> anything directly called by *me*: >> >> Exception in thread "pool-43-thread-5" java.lang.NullPointerException >> at >> org.apache.felix.framework.**BundleWiringImpl.** >> findClassOrResourceByDelegatio**n(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) >> >> I also observed my bundles being stopped and restarted several times after >> these problems arise. >> >> I'm beginning to wonder whether forcing a restart of the VM might be >> easier? >> >> Maybe the number of packages I have is too large, thereby making version >> clashes more likely? >> >> Dan >> >> > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@felix.**apache.org<[email protected]> > For additional commands, e-mail: [email protected] > >
