[
https://issues.apache.org/jira/browse/FELIX-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124449#comment-13124449
]
Richard S. Hall edited comment on FELIX-3153 at 10/10/11 8:13 PM:
------------------------------------------------------------------
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 it makes 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.
was (Author: rickhall):
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 pass
> -----------------------------------------------------------------------------------------------
>
> 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: org/osgi/framework/ServiceRegistration)
> 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
