felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-3153) [Framework] refreshPackages() should stop bundles in one pass and refresh them in a second pass
Date Mon, 10 Oct 2011 20:12:31 GMT

    [ https://issues.apache.org/jira/browse/FELIX-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124449#comment-13124449

Richard S. Hall commented on FELIX-3153:

I don't see how the order of refresh would play a role here. Once stop is called on all bundles
they should cease to execute any code. If the bundles misbehaved and continued to let their
threads execute after stop(), then you might see failures.

I suppose one other possibility where order could be important is for bundles whose code assumed
they were active and thus had bundle contexts (e.g., lazily activated bundles). If so, that
would be another good argument against lazy activation because they make your bundle dependent
on deactivation order.

You can open up another bug for that and I can look into it too, but not for this release.
> [Framework] refreshPackages() should stop bundles in one pass and refresh them in a second
> -----------------------------------------------------------------------------------------------
>                 Key: FELIX-3153
>                 URL: https://issues.apache.org/jira/browse/FELIX-3153
>             Project: Felix
>          Issue Type: Bug
>    Affects Versions: framework-3.0.9, framework-3.2.2
>            Reporter: Ioannis Canellos
>            Assignee: Richard S. Hall
>             Fix For: framework-4.0.1
> When using refreshPackages on a bundle that is used by a lot of other bundles, it results
in error.
> There is no deterministic behavior and the error is not always the same, even if I repeat
the exact same test twice.
> A typical example on how I reproduce it is to refresh the spring-context bundle inside
servicemix 4.4 (running on felix).
> If I switch to equinox I don't have that issue. That doesn't say much, but I mention
it to exclude other possibilities. 
> From my logs I see that Felix tries to refresh the bundles in the populated graph with
a different order each time (I don't know if this helps identifying the issue).
> Usually, the error looks like this:
> ERROR: Bundle org.springframework.osgi.extender [83] Error stopping bundle. (java.lang.NoClassDefFoundError:
> java.lang.NoClassDefFoundError: org/osgi/framework/ServiceRegistration
> 	at org.springframework.osgi.util.OsgiServiceUtils.unregisterService(OsgiServiceUtils.java:41)
> 	at org.springframework.osgi.extender.internal.support.NamespaceManager.unregisterResolverService(NamespaceManager.java:195)
> 	at org.springframework.osgi.extender.internal.support.NamespaceManager.destroy(NamespaceManager.java:223)
> 	at org.springframework.osgi.extender.internal.activator.ContextLoaderListener.shutdown(ContextLoaderListener.java:547)
> 	at org.springframework.osgi.extender.internal.activator.ContextLoaderListener.stop(ContextLoaderListener.java:431)
> 	at org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:651)
> 	at org.apache.felix.framework.Felix.stopBundle(Felix.java:2216)
> 	at org.apache.felix.framework.Felix$RefreshHelper.stop(Felix.java:4489)
> 	at org.apache.felix.framework.Felix.refreshPackages(Felix.java:3581)
> 	at org.apache.felix.framework.PackageAdminImpl.run(PackageAdminImpl.java:363)
> 	at java.lang.Thread.run(Thread.java:680)
> Caused by: java.lang.ClassNotFoundException: org.osgi.framework.ServiceRegistration not
found by org.springframework.osgi.core [80]
> 	at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:787)
> 	at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)
> 	at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> 	... 11 more

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message