felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: NoClassDefFoundError after update, caused by NPE in BundleRevisionImpl.calculateContentPath ?
Date Thu, 09 Aug 2012 17:10:06 GMT
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 <heavy@ungoverned.org> wrote:

> On Aug 9, 2012, at 10:44 , Dan Gravell <elstensoftware@googlemail.com> 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 <heavy@ungoverned.org>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 <elstensoftware@googlemail.com>
>>> 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 <fmeschbe@adobe.com
>>>> 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: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>> 
>>>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>> 
>>> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message