please, refer to the new jira issue: FELIX-1776
<http://issues.apache.org/jira/browse/FELIX-1776>
Regards;
/pierre
Guillaume Nodet wrote:
I've done some testing, but I can't really reproduce the exact behavior.
Here's what I have:
14:15:53,978 | DEBUG | lixDispatchQueue | fileinstall
| ? ? | BundleEvent RESOLVED
14:15:54,017 | INFO | nerated-bundles} | fileinstall
| ? ? | {felix.fileinstall.poll
(ms) = 1000, felix.fileinstall.dir =
/Users/gnodet/work/felix/git/karaf/assembly/target/apache-felix-karaf-1.1.0-SNAPSHOT/deploy,
felix.fileinstall.debug = -1, felix.fileinstall.bundles.new.start =
true, felix.fileinstall.tmpdir =
/Users/gnodet/work/felix/git/karaf/assembly/target/apache-felix-karaf-1.1.0-SNAPSHOT/data/generated-bundles,
felix.fileinstall.filter = null}
14:15:54,017 | INFO | FelixStartLevel | fileinstall
| ? ? | Starting initial scan
14:15:54,032 | INFO | nerated-bundles} | fileinstall
| ? ? | Started bundle:
file:/Users/gnodet/work/felix/git/karaf/assembly/target/apache-felix-karaf-1.1.0-SNAPSHOT/deploy/org.apache.felix.karaf.shell.obr-1.1.0-SNAPSHOT.jar
14:15:54,034 | DEBUG | lixDispatchQueue | obr
| ? ? | BundleEvent RESOLVED
14:15:54,035 | DEBUG | lixDispatchQueue | obr
| ? ? | BundleEvent STARTED
14:15:55,006 | DEBUG | lixDispatchQueue | obr
| ? ? | BundleEvent STOPPED
14:15:55,007 | DEBUG | lixDispatchQueue | obr
| ? ? | BundleEvent UNRESOLVED
14:15:55,007 | DEBUG | lixDispatchQueue | obr
| ? ? | BundleEvent UPDATED
14:15:55,022 | DEBUG | lixDispatchQueue | obr
| ? ? | BundleEvent RESOLVED
14:15:55,024 | DEBUG | lixDispatchQueue | obr
| ? ? | BundleEvent STARTED
14:15:55,024 | INFO | nerated-bundles} | fileinstall
| ? ? | Updated
/Users/gnodet/work/felix/git/karaf/assembly/target/apache-felix-karaf-1.1.0-SNAPSHOT/deploy/org.apache.felix.karaf.shell.obr-1.1.0-SNAPSHOT.jar
14:15:55,025 | DEBUG | lixDispatchQueue | framework
| ? ? | FrameworkEvent PACKAGES
REFRESHED
The above log is a trimmed down version of karaf after a restart with
an update on the obr bundle located in the deploy folder between the
stop and restart.
What happens is that when the framework is restarted, the deployed
bundle is started by the framework. When fileinstall is then started,
it will update the obr bundle (so it will be stopped and restarted).
One possible thing that may happen is some kind of interaction between
the start level service and fileinstall. But if the start level of
the bundle is higher than the current start level, the framework
should not really start the deployed bundle when fileinstall asks to
do so until the start level has been raised. So I don't think there
is any possible issue here.
Can you check from your side ?
On Sat, Oct 17, 2009 at 09:04, Pierre De Rop
<pierre.de_...@alcatel-lucent.fr> wrote:
Hello Guillaume,
I did some testing on the latest fileinstall, from the trunk.
Specifically, I tested the resolved issue from FELIX-1578 and the problem
has disappeared.
However, I noticed another (different) problem when performing the test (not
sure if I must create another jira issue, or not ?).
Here is what I did when testing:
1) clean the fwk bundle-cache (the fwk is not running)
2) copy a test bundle in the fileinstall's deploy directory
3) touch -t 01010000 deploy/test.jar (so, the lastModified date of
test.jar is Jan, 1st 2009)
4) I start the fwk -> test.jar is installed
5) I stop the fwk
6) I recompile the test.jar bundle (I just manage to ensure that test.jar
has now a different checksum), and I modify the timestamp with "touch -t
02010000 deploy/test.jar" (the timestamp is now Feb 1st, 2009)
7) I restart the fwk (without cleaning the cache)
7.1) the test.jar bundle is properly *updated* and started (the patch
FELIX-1578 works fine)
7.2) *however, after a few milliseconds, test.jar is stopped and then
restarted.*
Don't you think that fileinstall uselessly restarts test.jar during the step
7.2 ?
/pierre
Guillaume Nodet wrote:
I've fixed a lots of jira issues this week on fileinstall, so I'd
welcome a bit more testing before preparing a release next week or
so...
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
