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.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)
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: [email protected]
For additional commands, e-mail: [email protected]
