On Wed, Sep 9, 2009 at 2:59 PM, Guillaume Nodet<[email protected]> wrote: > Btw, the javadoc says: > "If this bundle is in the process of being activated or deactivated > then this method must wait for activation or deactivation to complete > before continuing. If this does not occur in a reasonable time, a > BundleException is thrown to indicate this bundle was unable to be > stopped. " > > Not sure if your interpretation really fits the javadoc, as there is a > "MUST wait for activation / deactivation". Also a timeout of 0 does > not really seem *reasonable* to me ;-)
Well, what would be reasonable for you? Point is that it is an ok interpretation :-) regards, Karl > 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 > -- Karl Pauls [email protected]
