You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall (Issue Comment Edited) (JIRA)" <ji...@apache.org> on 2011/10/10 22:14:29 UTC

[jira] [Issue Comment Edited] (FELIX-3153) [Framework] refreshPackages() should stop bundles in one pass and refresh them in a second pass

    [ 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