felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fabian Lange (JIRA)" <j...@apache.org>
Subject [jira] [Created] (FELIX-5134) Felix Fileinstall does not work correctly with Subdirectories
Date Sun, 13 Dec 2015 10:40:46 GMT
Fabian Lange created FELIX-5134:

             Summary: Felix Fileinstall does not work correctly with Subdirectories
                 Key: FELIX-5134
                 URL: https://issues.apache.org/jira/browse/FELIX-5134
             Project: Felix
          Issue Type: Bug
          Components: File Install
    Affects Versions: fileinstall-3.5.0
         Environment: Apache Karaf 4.0.3
            Reporter: Fabian Lange

As started to discuss on mailing list I now have a full functional reproduction case using
apache karaf.

Here is how to reproduce:
download the 4.0.3 distribution of karaf, which contains fileinstall 3.50
extract it and move `org.apache.felix.fileinstall-deploy.cfg` from `etc` to another empty
directory outside of karaf (in my case i called it test). The reason to move this file is
that its a valid config and that it would make it harder to spot the problem if it would be
actually deployed, but the problem is not related to this file.

Now start karaf in debug mode by calling `karaf debug`, wait for it to cleanly start and attach
a debugger. Set a Breakpoint to `WatcherScanner#L125` the method is called `process()`.
(note if you need to retry that, be sure to delete the karaf data dir before retrying as it
messes with state).

Now move the test directory into your etc directory. you will see the breakpoint fire with
a situation like the attached screenshot.

The Scanner saw this file `/Users/fabian/Downloads/apache-karaf-4.0.3/etc/test/org.apache.felix.fileinstall-deploy.cfg`
and called process on it. Because its parent directory is NOT the one configured in the config,
it now starts to walk up the tree. Here is the problem.
Next check is if "test" has the configured directory as parent, which it has, and then the
loop exists, leaving the "test" directory as file.
This is then later passed down the line to config processing, which will FAIL, thus keep the
directory "test" forever in the retry logic of `DirectoryWatcher#processingFailures` and `DirectoryWatcher#doProcess`.

For me it looks like as if the walking logic could be kept, but if it finds a match, the original
file needs to be added in `ScannerWatcher#process()` and `remove`.

This message was sent by Atlassian JIRA

View raw message