Do you guys are ok with my analysis ? Imho it looks like a bug in the framework, but I'm not 100% sure.
---------- Forwarded message ---------- From: Guillaume Nodet <[email protected]> Date: Wed, Sep 9, 2009 at 14:20 Subject: Re: [FileInstall] BundleException(s) while re-deploying a Spring-enabled bundle To: [email protected] Can you try to reproduce the problem using equinox instead ? Just edit the etc/config.properties file and switch to "karaf.framework=equinox". I think the Felix framework may react badly. Looking at [1], the framework should try to stop the bundle, which means it must wait until the bundle is either started or stopped, then stop if if needed. Looking at the code, if the bundle is either starting or stopping, the exception you've seen is thrown. [1] http://www.osgi.org/javadoc/r4v41/org/osgi/framework/Bundle.html#update%28%29 On Wed, Sep 9, 2009 at 12:38, Jeremias Maerki<[email protected]> wrote: > Keywords: FileInstall, Karaf, SpringDM, CXF > > I'm suspecting something wrong in either FileInstall, Felix Framework, > SpringDM, CXF or my spring.xml in a bundle. Not sure which one it is, > yet, though I have the impression that it's one of the first two in the > list. I'm hoping someone might have an idea. > > Stopping and starting the bundle manually (via WebConsole) works fine. > > But re-deploying the bundle after a new build into the directory > observed by FileInstall (from Karaf Trunk build made today), the Spring > Context doesn't seem to be closing properly. In this case, I'm seeing a > number of these (can be quite many, issued until the bundle is really > stopped): > > 11:57:19,828|ERROR| ted-bundles} | fileinstall | ? > ? | Failed to update artifact > C:\Dev\xxxxx\_container\apache-felix-karaf-0.9.0-SNAPSHOT\..\deploy\ch.jm.xxx.job.submission.http.jar > org.osgi.framework.BundleException: Bundle ch.jm.xxx.job.submission.http > [115] cannot be update, since it is either starting or stopping. > at org.apache.felix.framework.Felix.updateBundle(Felix.java:1786) > at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:908) > at > org.apache.felix.fileinstall.internal.DirectoryWatcher.update(DirectoryWatcher.java:762) > at > org.apache.felix.fileinstall.internal.DirectoryWatcher.update(DirectoryWatcher.java:621) > at > org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:286) > > Right after that: > > 11:57:29,828|ERROR| PackageAdmin | RunnableTimedExecution | > oncurrent.RunnableTimedExecution 109 | Closing runnable for context > OsgiBundleXmlApplicationContext(bundle=ch.jm.xxx.job.submissi > on.http, config=osgibundle:/META-INF/spring/*.xml) did not finish in 10000ms; > consider taking a snapshot and then shutdown the VM in case the thread still > hangs > 11:57:29,843|INFO | PackageAdmin | ultOsgiApplicationContextCreator | > ultOsgiApplicationContextCreator 67 | Discovered configurations > {osgibundle:/META-INF/spring/*.xml} in bundle [xxx :: Job :: Sub > mission :: HTTP POST Adapter (ch.jm.xxx.job.submission.http)] > 11:57:29,843|INFO | derThread-18 | OsgiBundleXmlApplicationContext | > pport.AbstractApplicationContext 411 | Refreshing > org.springframework.osgi.context.support.osgibundlexmlapplicationcont...@c81850 > : display name > [OsgiBundleXmlApplicationContext(bundle=ch.jm.xxx.job.submission.http, > config=osgibundle:/META-INF/spring/*.xml)]; startup date [Wed Sep 09 11:57:29 > CEST 2009]; root of context hierarch > y > 11:57:29,843|INFO | derThread-18 | OsgiBundleXmlApplicationContext | > ractOsgiBundleApplicationContext 359 | Unpublishing application context OSGi > service for bundle xxx :: Job :: Submission :: HTTP > POST Adapter (ch.jm.xxx.job.submission.http) > 11:57:29,859|INFO | ted-bundles} | fileinstall | ? > ? | Started bundle: > file:/C:/Dev/xxxxx/_container/deploy/ch.jm.xxx.job.submission.http.jar > 11:57:29,859|INFO | ted-bundles} | fileinstall | ? > ? | Started bundle: > file:/C:/Dev/xxxxx/_container/deploy/ch.jm.xxx.job.submission.http.jar > > Note again that there are multiple notifications that the bundle has > been started. > > After that I get some follow-up errors because Spring doesn't seem to > have stopped or started gracefully. > > I get the impression that in conjunction with FileInstall, an update > doesn't wait until the bundle is properly stopped and already starts the > updated one which causes trouble inside SpringDM. > > For completeness, here is one of the error messages from SpringDM: > > (the following appears on the console and in the log) > ka...@root> Exception in thread "SpringOsgiExtenderThread-9" > java.lang.IllegalStateException: BeanFactory not initialized or already > closed - call 'refresh' before accessing beans via the ApplicationC > ontext > at > org.springframework.context.support.AbstractRefreshableApplicationContext.getBeanFactory(AbstractRefreshableApplicationContext.java:153) > at > org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.close(DependencyWaiterApplicationContextExecutor.java:345) > at > org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.fail(DependencyWaiterApplicationContextExecutor.java:401) > at > org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:287) > at > org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:175) > at > org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:175) > at > org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:718) > at java.lang.Thread.run(Thread.java:619) > > Please note that the errors issued by Spring are not always the same. > I've only listed the consistent exception in that context. > > This is not a crucial problem for me as it only appears during a > re-deployment. I can work around that by stopping the bundle manually > before re-deployment. But maybe this gives some hints about a possible > bug somewhere. > > Thanks, > Jeremias Maerki > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
