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