felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [FileInstall] BundleException(s) while re-deploying a Spring-enabled bundle
Date Wed, 09 Sep 2009 12:59:17 GMT
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<karlpauls@gmail.com> wrote:
> On Wed, Sep 9, 2009 at 2:21 PM, Guillaume Nodet<gnodet@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 <gnodet@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

Mime
View raw message