Right, that's really an edge interpretation, but it fits in. Do you see in a future version the timeout being configurable with a value > 0 ? ;-) I think that would help a lot in this case.
On Wed, Sep 9, 2009 at 14:37, Karl Pauls<[email protected]> wrote: > On Wed, Sep 9, 2009 at 2:21 PM, Guillaume Nodet<[email protected]> wrote: >> Do you guys are ok with my analysis ? Imho it looks like a bug in the >> framework, but I'm not 100% sure. > > Its not a bug as such. The point is that the spec does say that we > wait for a timeout for the bundle to either be stopped or started and > then throw an exception. In other words, felix just has a timeout of 0 > but it is still correct :-) > > regards, > > Karl > >> ---------- 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 >> > > > > -- > Karl Pauls > [email protected] > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
