---------- Forwarded message ----------
From: Guillaume Nodet <[email protected]>
Date: Wed, Sep 9, 2009 at 14:20
Subject: Re: [FileInstall] BundleException(s) while re-deploying a
Spring-enabled bundle
To: [email protected]
Can you try to reproduce the problem using equinox instead ?
Just edit the etc/config.properties file and switch to
"karaf.framework=equinox".
I think the Felix framework may react badly. Looking at [1], the
framework should try to stop the bundle, which means it must wait
until the bundle is either started or stopped, then stop if if
needed.
Looking at the code, if the bundle is either starting or stopping,
the exception you've seen is thrown.
[1]
http://www.osgi.org/javadoc/r4v41/org/osgi/framework/Bundle.html#update%28%29
On Wed, Sep 9, 2009 at 12:38, Jeremias Maerki<[email protected]
> wrote:
Keywords: FileInstall, Karaf, SpringDM, CXF
I'm suspecting something wrong in either FileInstall, Felix
Framework,
SpringDM, CXF or my spring.xml in a bundle. Not sure which one
it is,
yet, though I have the impression that it's one of the first two
in the
list. I'm hoping someone might have an idea.
Stopping and starting the bundle manually (via WebConsole) works
fine.
But re-deploying the bundle after a new build into the directory
observed by FileInstall (from Karaf Trunk build made today), the
Spring
Context doesn't seem to be closing properly. In this case, I'm
seeing a
number of these (can be quite many, issued until the bundle is
really
stopped):
11:57:19,828|ERROR| ted-bundles} |
fileinstall
| ? ? | Failed to update
artifact
C:\Dev\xxxxx\_container\apache-felix-karaf-0.9.0-SNAPSHOT\..
\deploy\ch.jm.xxx.job.submission.http.jar
org.osgi.framework.BundleException: Bundle
ch.jm.xxx.job.submission.http [115] cannot be update, since it
is either starting or stopping.
at org.apache.felix.framework.Felix.updateBundle
(Felix.java:1786)
at org.apache.felix.framework.BundleImpl.update
(BundleImpl.java:908)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.update
(DirectoryWatcher.java:762)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.update
(DirectoryWatcher.java:621)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run
(DirectoryWatcher.java:286)
Right after that:
11:57:29,828|ERROR| PackageAdmin |
RunnableTimedExecution |
oncurrent.RunnableTimedExecution 109 | Closing runnable for
context OsgiBundleXmlApplicationContext
(bundle=ch.jm.xxx.job.submissi
on.http, config=osgibundle:/META-INF/spring/*.xml) did not
finish in 10000ms; consider taking a snapshot and then shutdown
the VM in case the thread still hangs
11:57:29,843|INFO | PackageAdmin |
ultOsgiApplicationContextCreator |
ultOsgiApplicationContextCreator 67 | Discovered
configurations {osgibundle:/META-INF/spring/*.xml} in bundle
[xxx :: Job :: Sub
mission :: HTTP POST Adapter (ch.jm.xxx.job.submission.http)]
11:57:29,843|INFO | derThread-18 |
OsgiBundleXmlApplicationContext |
pport.AbstractApplicationContext 411 | Refreshing
org.springframework.osgi.context.support.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)
ka...@root> Exception in thread "SpringOsgiExtenderThread-9"
java.lang.IllegalStateException: BeanFactory not initialized or
already closed - call 'refresh' before accessing beans via the
ApplicationC
ontext
at
org.springframework.context.support.AbstractRefreshableApplicationContext.getBeanFactory
(AbstractRefreshableApplicationContext.java:153)
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.close
(DependencyWaiterApplicationContextExecutor.java:345)
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.fail
(DependencyWaiterApplicationContextExecutor.java:401)
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne
(DependencyWaiterApplicationContextExecutor.java:287)
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh
(DependencyWaiterApplicationContextExecutor.java:175)
at
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh
(AbstractDelegatedExecutionApplicationContext.java:175)
at
org.springframework.osgi.extender.internal.activator.ContextLoaderListener
$2.run(ContextLoaderListener.java:718)
at java.lang.Thread.run(Thread.java:619)
Please note that the errors issued by Spring are not always the
same.
I've only listed the consistent exception in that context.
This is not a crucial problem for me as it only appears during a
re-deployment. I can work around that by stopping the bundle
manually
before re-deployment. But maybe this gives some hints about a
possible
bug somewhere.
Thanks,
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
