One party is fileinstall which try to update the bundle because it has been updated on disk. Not really sure what the other party is. I'll try to investigate.
On Wed, Sep 9, 2009 at 15:31, Karl Pauls<[email protected]> wrote: > On Wed, Sep 9, 2009 at 3:07 PM, Guillaume Nodet<[email protected]> wrote: >> 5 minutes looks more reasonable to me. >> >> I think what the specs implies is that the framework *needs* to wait >> for the bundle to be stopped before continuing, but is allowed to >> throw an exception if it takes too long, for example if the bundle is >> stucked in the stopping process. Same is true for the uninstall >> method. >> >> I think the goal is to allow the user not to deal with timing issues >> in the usual cases, but have the method call succeed when possible. > > But this is still a rather tricky thing to do. My bundle might as well > prefer to not wait 5 minutes before it returns. We could make it > configurable but still that doesn't help if you are not in control of > the framework. Anyways, it is a good idea to not have more then one > management agent change the same part of the framework at the same > time as OSGi wasn't designed for this (as is apparent by this and some > other problems). > > In other words, while I agree with you that it would be nice to have a > configurable timeout for this it is still a good idea to write your > management agent in a way that it is able to deal with this issue > regardless (as it might happen no matter what you do). > > Just to get a better understanding of this, do you know what is > causing this (i.e., what parties are trying to manage the same bundles > at the same time and why)? > > regards, > > Karl > >> On Wed, Sep 9, 2009 at 15:01, Karl Pauls<[email protected]> wrote: >>> 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] >>> >> >> >> >> -- >> 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
