p.s. If I had to guess, I'd say that there are some threads that do not
get stopped when you stop your bundle for the update. If any threads
continue to run after a bundle's stop() method is called, then you can
have all sorts of fun.
On 7/2/12 12:07, Dan Gravell wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
