Thanks Richard, I'll take another look at the thread situation. I suspect that it's mainly UI threads. Either way I'll try to find a way to stop them!
Dan On Thu, Aug 9, 2012 at 6:10 PM, Richard S. Hall <[email protected]>wrote: > Dan, > > I looked at your example and was able to recreate the issue. After > debugging it a little bit, it seems to be a fairly standard issue when > dealing with threads and OSGi: > > You must make sure that all threads created by a bundle have stopped > executing by the time the bundle's activator stop() method has returned. > > This can be complicated if you are using libraries that use threads and > don't give you a way to shut them all down. There is no way around this. > The start() method signals a bundle that it is ok to use resources and the > stop() method signals that the bundle must stop using all resources. > > The NPE results because some thread is still trying to load classes on a > bundle wiring that has been discarded. > > -> richard > > p.s. Unrelated, I also noticed that your threads continually ask for the > bliss keystore resource when I'm just sitting idle at the update screen. > Not sure if that is intended or not. > > On Aug 9, 2012, at 10:48 , Richard S. Hall <[email protected]> wrote: > > > On Aug 9, 2012, at 10:44 , Dan Gravell <[email protected]> > wrote: > > > >> I understand why you want it simplified but I don't think I can - part > of > >> the reason I think this is occurring is because it's a pretty complex > beast > >> with threads and bundles all over the place. > >> > >> I will send you some download instructions and instructions to run... > what > >> OS are you on? Is a plain folder structure in a ZIP easiest? > > > > Mac OS X. > > > > ZIP is fine. > > > > -> richard > > > >> > >> Dan > >> > >> On Thu, Aug 9, 2012 at 2:58 PM, Richard S. Hall <[email protected] > >wrote: > >> > >>> Perhaps you can give me some way to download it and recreate it…that's > >>> probably the quickest way. Of course, try to simplify it if you can… > >>> > >>> -> richard > >>> > >>> On Aug 9, 2012, at 06:29 , Dan Gravell <[email protected]> > >>> wrote: > >>> > >>>> Sorry: forgot to include my code... I am performing a refresh > >>>> (see blockingRefreshBundles()). Before this code runs I am using OBR > to > >>>> resolve a set of requirements. I then perform the update via the > >>> resolver. > >>>> 'startedBundles' are the bundles that were started at the time the > update > >>>> runs: > >>>> > >>>> for (Bundle bundle : startedBundles) { > >>>> try { > >>>> if(!FelixObrUtils.isFragment(bundle)) > >>>> sysBundle.getBundleContext().getBundle(bundle.getBundleId()).stop(); > >>>> } catch (BundleException e) { > >>>> LOG.error("Failed to stop " + bundle.getSymbolicName(), e); > >>>> } > >>>> } > >>>> resolver.deploy(0); > >>>> blockingRefreshBundles(null, sysBundle.getBundleContext()); > >>>> for (Bundle bundle : startedBundles) { > >>>> try { > >>>> if(!FelixObrUtils.isFragment(bundle)) > >>>> sysBundle.getBundleContext().getBundle(bundle.getBundleId()).start(); > >>>> } catch (BundleException e) { > >>>> LOG.error("Failed to restart " + bundle.getSymbolicName(), e); > >>>> } > >>>> } > >>>> > >>>> protected void blockingRefreshBundles(Collection<Bundle> > >>> restartedBundles, > >>>> final BundleContext bundleContext) { > >>>> final FrameworkWiring frameworkWiring = > >>>> bundleContext.getBundle(0).adapt(FrameworkWiring.class); > >>>> if(null!=frameworkWiring) { > >>>> final CountDownLatch latch = new CountDownLatch(1); > >>>> frameworkWiring.refreshBundles(restartedBundles, new > FrameworkListener() > >>> { > >>>> @Override > >>>> public void frameworkEvent(FrameworkEvent arg0) { > >>>> if(arg0.getType()==FrameworkEvent.PACKAGES_REFRESHED) > latch.countDown(); > >>>> } > >>>> }); > >>>> try { > >>>> latch.await(); > >>>> } catch (InterruptedException e) { > >>>> LOG.error("Interrupted while waiting for packages to refresh. Will > >>> continue > >>>> anyway"); > >>>> } > >>>> } else { > >>>> LOG.warn("Couldn't adapt system bundle to framework wiring so will not > >>>> refresh bundles"); > >>>> } > >>>> } > >>>> > >>>> Just a thought - might there be a problem in re-using the old > references > >>> to > >>>> 'startedBundles'? Following the update, should I refresh these > instances? > >>>> > >>>> Dan > >>>> > >>>> On Thu, Aug 9, 2012 at 11:19 AM, Felix Meschberger < > [email protected] > >>>> wrote: > >>>> > >>>>> Hi > >>>>> > >>>>> I would assume you need to call PackageAdmin.refreshPackages() after > >>>>> updating the bundles, such that all providers and consumers get to > know > >>> the > >>>>> latest updates. > >>>>> > >>>>> If you just to Bundle.update the call to PackageAdmin.refreshPackages > >>> must > >>>>> also be done explicitly. If you are using installation tools such as > >>> File > >>>>> Install this call would be done automatically by the installation > tool > >>>>> along with updating the bundles. > >>>>> > >>>>> Regards > >>>>> Felix > >>>>> > >>>>> Am 09.08.2012 um 11:59 schrieb Dan Gravell: > >>>>> > >>>>>> Hi all. I'm getting some NoClassDefFoundErrors and other > >>>>> exceptions/errors > >>>>>> after updating some bundles. The bundles work fine before. > Restarting > >>>>> Felix > >>>>>> clears the problem (no more NCDFE) and the newly updating bundles > work > >>>>> fine > >>>>>> once again. > >>>>>> > >>>>>> I'd like to be able to support updating while running, if possible. > >>>>>> > >>>>>> Here's a sample stacktrace: > >>>>>> > >>>>>> 2012-08-09 10:44:56,095 [ERROR] Error while executing > >>>>>> AutomaticFixerCoverArtCommand (AggregatedPolic > >>>>>> yCommand.java:65, thread policy pool 0) > >>>>>> java.lang.ExceptionInInitializerError > >>>>>> at > >>>>>> > >>>>> > >>> > com.elsten.bliss.music.policy.coverartpolicy.CoverArtUtils.dimensionsOf(CoverArtUtils.java > >>>>>> :163) > >>>>>> at > >>>>>> > >>>>> > >>> > com.elsten.bliss.music.policy.coverartpolicy.CoverArtUtils.openImageDimension(CoverArtUtil > >>>>>> s.java:187) > >>>>>> [...] > >>>>>> Caused by: java.lang.NullPointerException > >>>>>> at > >>>>>> > >>>>> > >>> > org.apache.felix.framework.BundleRevisionImpl.getResourcesLocal(BundleRevisionImpl.java:510) > >>>>>> at > >>>>>> > >>>>> > >>> > org.apache.felix.framework.BundleWiringImpl.findResourcesByDelegation(BundleWiringImpl.java:1127) > >>>>>> at > >>>>>> > >>>>> > >>> > org.apache.felix.framework.BundleWiringImpl.getResourcesByDelegation(BundleWiringImpl.java:1037) > >>>>>> at > >>>>>> > >>>>> > >>> > org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5.getResources(BundleWiringImpl.java:1778) > >>>>>> at > >>>>>> > >>>>> > >>> > org.eclipse.jetty.osgi.boot.internal.webapp.OSGiWebappClassLoader.getResources(OSGiWebappClassLoader.java:115) > >>>>>> at > >>>>>> java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:340) > >>>>>> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:432) > >>>>>> at > >>>>>> > >>>>> > >>> > javax.imageio.spi.IIORegistry.registerApplicationClasspathSpis(IIORegistry.java:206) > >>>>>> at javax.imageio.spi.IIORegistry.<init>(IIORegistry.java:138) > >>>>>> at > >>>>>> > javax.imageio.spi.IIORegistry.getDefaultInstance(IIORegistry.java:159) > >>>>>> at javax.imageio.ImageIO.<clinit>(ImageIO.java:64) > >>>>>> > >>>>>> 2012-08-09 10:44:57,061 [ERROR] Error while executing > >>>>>> AutomaticFixerCoverArtCommand (AggregatedPolicyCommand.java:65, > thread > >>>>>> policy pool 1) > >>>>>> java.lang.NoClassDefFoundError: Could not initialize class > >>>>>> javax.imageio.ImageIO > >>>>>> at > >>>>>> > >>>>> > >>> > com.elsten.bliss.music.policy.coverartpolicy.CoverArtUtils.dimensionsOf(CoverArtUtils.java:163) > >>>>>> at > >>>>>> > >>>>> > >>> > com.elsten.bliss.music.policy.coverartpolicy.CoverArtUtils.openImageDimension(CoverArtUtils.java:187) > >>>>>> [... no caused by trace here...] > >>>>>> > >>>>>> Immediately before that I get something I only see once I enable > Felix > >>>>>> debug logging: > >>>>>> > >>>>>> ERROR: Bundle com.elsten.bliss.ui [34] Unable to get module class > path. > >>>>>> (java.lang.NullPointerExcepti > >>>>>> on) > >>>>>> java.lang.NullPointerException > >>>>>> at > >>>>>> > >>>>> > >>> > org.apache.felix.framework.BundleRevisionImpl.calculateContentPath(BundleRevisionImpl.java > >>>>>> :410) > >>>>>> at > >>>>>> > >>>>> > >>> > org.apache.felix.framework.BundleRevisionImpl.initializeContentPath(BundleRevisionImpl.jav > >>>>>> a:347) > >>>>>> at > >>>>>> > >>>>> > >>> > org.apache.felix.framework.BundleRevisionImpl.getContentPath(BundleRevisionImpl.java:333) > >>>>>> at > >>>>>> > >>>>> > >>> > org.apache.felix.framework.BundleRevisionImpl.getResourcesLocal(BundleRevisionImpl.java:49 > >>>>>> 3) > >>>>>> at > >>>>>> > >>>>> > >>> > org.apache.felix.framework.BundleWiringImpl.findResourcesByDelegation(BundleWiringImpl.jav > >>>>>> a:1127) > >>>>>> at > >>>>>> > >>>>> > >>> > org.apache.felix.framework.BundleWiringImpl.getResourcesByDelegation(BundleWiringImpl.java > >>>>>> :1037) > >>>>>> at > >>>>>> > >>>>> > >>> > org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5.getResources(BundleWiri > >>>>>> ngImpl.java:1778) > >>>>>> at > >>>>>> > >>>>> > >>> > org.eclipse.jetty.osgi.boot.internal.webapp.OSGiWebappClassLoader.getResources(OSGiWebappC > >>>>>> lassLoader.java:115) > >>>>>> at > >>>>>> java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:340) > >>>>>> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:432) > >>>>>> at > >>>>>> > >>>>> > >>> > javax.imageio.spi.IIORegistry.registerApplicationClasspathSpis(IIORegistry.java:206) > >>>>>> at javax.imageio.spi.IIORegistry.<init>(IIORegistry.java:138) > >>>>>> at > >>>>>> > javax.imageio.spi.IIORegistry.getDefaultInstance(IIORegistry.java:159) > >>>>>> at javax.imageio.ImageIO.<clinit>(ImageIO.java:64) > >>>>>> at > >>>>>> > >>>>> > >>> > com.elsten.bliss.music.policy.coverartpolicy.CoverArtUtils.dimensionsOf(CoverArtUtils.java > >>>>>> :163) > >>>>>> at > >>>>>> > >>>>> > >>> > com.elsten.bliss.music.policy.coverartpolicy.CoverArtUtils.openImageDimension(CoverArtUtil > >>>>>> s.java:187) > >>>>>> > >>>>>> There are many of these NCDFEs but only one of those NPEs in > >>>>>> BundleRevisionImpl. Once those have been thrown, "all hell seems to > >>> break > >>>>>> loose" and I start getting NCDFEs for other classes including my > own. > >>>>> Does > >>>>>> the original exception cause these downstream ones or are they > >>> unrelated? > >>>>>> > >>>>>> During the update the Import-Package statements for javax.imageio.* > >>>>> remain > >>>>>> stable. > >>>>>> > >>>>>> Let me know if more contextual logs are useful. I can provide the > >>> actual > >>>>>> code that's running if it helps (it's large though). > >>>>>> > >>>>>> Dan > >>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [email protected] > >>>>> For additional commands, e-mail: [email protected] > >>>>> > >>>>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
