You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2009/09/09 14:21:38 UTC
Fwd: [FileInstall] BundleException(s) while re-deploying a
Spring-enabled bundle
Do you guys are ok with my analysis ? Imho it looks like a bug in the
framework, but I'm not 100% sure.
---------- Forwarded message ----------
From: Guillaume Nodet <gn...@gmail.com>
Date: Wed, Sep 9, 2009 at 14:20
Subject: Re: [FileInstall] BundleException(s) while re-deploying a
Spring-enabled bundle
To: users@felix.apache.org
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<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
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [FileInstall] BundleException(s) while re-deploying a
Spring-enabled bundle
Posted by Guillaume Nodet <gn...@gmail.com>.
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<ka...@gmail.com> wrote:
> On Wed, Sep 9, 2009 at 2:21 PM, Guillaume Nodet<gn...@gmail.com> 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 <gn...@gmail.com>
>> Date: Wed, Sep 9, 2009 at 14:20
>> Subject: Re: [FileInstall] BundleException(s) while re-deploying a
>> Spring-enabled bundle
>> To: users@felix.apache.org
>>
>>
>> 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<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
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [FileInstall] BundleException(s) while re-deploying a
Spring-enabled bundle
Posted by Guillaume Nodet <gn...@gmail.com>.
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<ma...@luminis.nl> 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<gn...@gmail.com> 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<ka...@gmail.com> wrote:
>>>>
>>>> On Wed, Sep 9, 2009 at 2:21 PM, Guillaume Nodet<gn...@gmail.com> 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 <gn...@gmail.com>
>>>>> Date: Wed, Sep 9, 2009 at 14:20
>>>>> Subject: Re: [FileInstall] BundleException(s) while re-deploying a
>>>>> Spring-enabled bundle
>>>>> To: users@felix.apache.org
>>>>>
>>>>>
>>>>> 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<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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Karl Pauls
>>>> karlpauls@gmail.com
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>>
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [FileInstall] BundleException(s) while re-deploying a Spring-enabled bundle
Posted by Marcel Offermans <ma...@luminis.nl>.
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<gn...@gmail.com>
> 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<ka...@gmail.com> wrote:
>>> On Wed, Sep 9, 2009 at 2:21 PM, Guillaume Nodet<gn...@gmail.com>
>>> 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 <gn...@gmail.com>
>>>> Date: Wed, Sep 9, 2009 at 14:20
>>>> Subject: Re: [FileInstall] BundleException(s) while re-deploying a
>>>> Spring-enabled bundle
>>>> To: users@felix.apache.org
>>>>
>>>>
>>>> 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<dev@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
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
>
Re: [FileInstall] BundleException(s) while re-deploying a
Spring-enabled bundle
Posted by Guillaume Nodet <gn...@gmail.com>.
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<ka...@gmail.com> wrote:
> On Wed, Sep 9, 2009 at 3:07 PM, Guillaume Nodet<gn...@gmail.com> 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<ka...@gmail.com> wrote:
>>> On Wed, Sep 9, 2009 at 2:59 PM, Guillaume Nodet<gn...@gmail.com> 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<ka...@gmail.com> wrote:
>>>>> On Wed, Sep 9, 2009 at 2:21 PM, Guillaume Nodet<gn...@gmail.com> 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 <gn...@gmail.com>
>>>>>> Date: Wed, Sep 9, 2009 at 14:20
>>>>>> Subject: Re: [FileInstall] BundleException(s) while re-deploying a
>>>>>> Spring-enabled bundle
>>>>>> To: users@felix.apache.org
>>>>>>
>>>>>>
>>>>>> 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<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
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> karlpauls@gmail.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [FileInstall] BundleException(s) while re-deploying a
Spring-enabled bundle
Posted by Karl Pauls <ka...@gmail.com>.
On Wed, Sep 9, 2009 at 3:07 PM, Guillaume Nodet<gn...@gmail.com> 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<ka...@gmail.com> wrote:
>> On Wed, Sep 9, 2009 at 2:59 PM, Guillaume Nodet<gn...@gmail.com> 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<ka...@gmail.com> wrote:
>>>> On Wed, Sep 9, 2009 at 2:21 PM, Guillaume Nodet<gn...@gmail.com> 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 <gn...@gmail.com>
>>>>> Date: Wed, Sep 9, 2009 at 14:20
>>>>> Subject: Re: [FileInstall] BundleException(s) while re-deploying a
>>>>> Spring-enabled bundle
>>>>> To: users@felix.apache.org
>>>>>
>>>>>
>>>>> 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<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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Karl Pauls
>>>> karlpauls@gmail.com
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Karl Pauls
karlpauls@gmail.com
Re: [FileInstall] BundleException(s) while re-deploying a
Spring-enabled bundle
Posted by Guillaume Nodet <gn...@gmail.com>.
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.
On Wed, Sep 9, 2009 at 15:01, Karl Pauls<ka...@gmail.com> wrote:
> On Wed, Sep 9, 2009 at 2:59 PM, Guillaume Nodet<gn...@gmail.com> 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<ka...@gmail.com> wrote:
>>> On Wed, Sep 9, 2009 at 2:21 PM, Guillaume Nodet<gn...@gmail.com> 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 <gn...@gmail.com>
>>>> Date: Wed, Sep 9, 2009 at 14:20
>>>> Subject: Re: [FileInstall] BundleException(s) while re-deploying a
>>>> Spring-enabled bundle
>>>> To: users@felix.apache.org
>>>>
>>>>
>>>> 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<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
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [FileInstall] BundleException(s) while re-deploying a
Spring-enabled bundle
Posted by Karl Pauls <ka...@gmail.com>.
On Wed, Sep 9, 2009 at 2:59 PM, Guillaume Nodet<gn...@gmail.com> 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<ka...@gmail.com> wrote:
>> On Wed, Sep 9, 2009 at 2:21 PM, Guillaume Nodet<gn...@gmail.com> 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 <gn...@gmail.com>
>>> Date: Wed, Sep 9, 2009 at 14:20
>>> Subject: Re: [FileInstall] BundleException(s) while re-deploying a
>>> Spring-enabled bundle
>>> To: users@felix.apache.org
>>>
>>>
>>> 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<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
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Karl Pauls
karlpauls@gmail.com
Re: [FileInstall] BundleException(s) while re-deploying a
Spring-enabled bundle
Posted by Guillaume Nodet <gn...@gmail.com>.
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 ;-)
On Wed, Sep 9, 2009 at 14:37, Karl Pauls<ka...@gmail.com> wrote:
> On Wed, Sep 9, 2009 at 2:21 PM, Guillaume Nodet<gn...@gmail.com> 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 <gn...@gmail.com>
>> Date: Wed, Sep 9, 2009 at 14:20
>> Subject: Re: [FileInstall] BundleException(s) while re-deploying a
>> Spring-enabled bundle
>> To: users@felix.apache.org
>>
>>
>> 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<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
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [FileInstall] BundleException(s) while re-deploying a
Spring-enabled bundle
Posted by Karl Pauls <ka...@gmail.com>.
On Wed, Sep 9, 2009 at 2:21 PM, Guillaume Nodet<gn...@gmail.com> 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 <gn...@gmail.com>
> Date: Wed, Sep 9, 2009 at 14:20
> Subject: Re: [FileInstall] BundleException(s) while re-deploying a
> Spring-enabled bundle
> To: users@felix.apache.org
>
>
> 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<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
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Karl Pauls
karlpauls@gmail.com