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.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
