You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2009/09/09 13:04:38 UTC
Re: [FileInstall] BundleException(s) while re-deploying a Spring-enabled bundle
I overwrite the existing bundle with the Ant copy task. Does that
question imply that I shouldn't do that? ;-)
On 09.09.2009 12:55:58 Guillaume Nodet wrote:
> When you redeploy the bundle, do you first remove it, then copy the
> new one, or do you overwrite the existing bundle ?
>
> On Wed, Sep 9, 2009 at 12:38, Jeremias Maerki<de...@jeremias-maerki.ch> 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.OsgiBundleXmlApplicationContext@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)
> > karaf@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: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: [FileInstall] BundleException(s) while re-deploying a
Spring-enabled bundle
Posted by Guillaume Nodet <gn...@gmail.com>.
Not at all, I'm just trying to determine what fileinstall is doing.
On Wed, Sep 9, 2009 at 13:04, Jeremias Maerki<de...@jeremias-maerki.ch> wrote:
> I overwrite the existing bundle with the Ant copy task. Does that
> question imply that I shouldn't do that? ;-)
>
> On 09.09.2009 12:55:58 Guillaume Nodet wrote:
>> When you redeploy the bundle, do you first remove it, then copy the
>> new one, or do you overwrite the existing bundle ?
>>
>> On Wed, Sep 9, 2009 at 12:38, Jeremias Maerki<de...@jeremias-maerki.ch> 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.OsgiBundleXmlApplicationContext@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)
>> > karaf@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: users-unsubscribe@felix.apache.org
>> > For additional commands, e-mail: users-help@felix.apache.org
>> >
>> >
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org