Yeah, of course. The real point is that currently, there's no timeout at all.
On Wed, Sep 9, 2009 at 15:08, Marcel Offermans<[email protected]> wrote: > I'm sure that everybody has their interpretation about what's "reasonable", > probably largely depending on the application and target platform you're > running on and how your "management agent" works. In other words, I can see > the value of making this a configurable framework parameter. > > Greetings, Marcel > > > On Sep 9, 2009, at 15:01 , Karl Pauls 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
