The scanning was done with the following in mind: * all files will be scanned recursively * all first level directories are exploded jars
The scanning is done recursively so that if a file in an exploded jar is modified, the jar will be recreated and the bundle updated with the changes. 2015-12-13 11:45 GMT+01:00 Fabian Lange <[email protected]>: > Hi All, > > Raymond was correct and this finally lead me onto the right track. It DOES > support recursive scanning already. But it does not work :) > I have documented it in https://issues.apache.org/jira/browse/FELIX-5134 > > short summary here: Yes the WatchedScanner#ScannerWatcher will pick up the > "nested" config file. Its processLogic will however not "use" it. > There is a parent directory check logic (for whatever reason) which breaks > it. Instead of passing on the original config file, it passes on the parent > directory. > > This leads to > A) recursive not working > B) instead retrying the "directory name" as config file, which fails and > the retry logic in DirectoryWatcher will retry it over and over again. > > As far as I can tell, a correct fix would be to not use the "file" in > ScannerWatcher.process()/remove() but to use the original "path.toFile()" > > Perhaps somebody who has insight on what the directory up walking is > supposed to actually do can comment here > > Fabian > > On Fri, Dec 11, 2015 at 5:51 PM, Fabian Lange <[email protected] > > > wrote: > > > I will provide a repro case over the weekend. > > > > Best regards > > Fabian > > > > On Fri, Dec 11, 2015 at 2:58 PM, Raymond Auge <[email protected]> > > wrote: > > > >> On Fri, Dec 11, 2015 at 8:49 AM, Fabian Lange < > >> [email protected]> > >> wrote: > >> > >> > Hi Ray, > >> > I would agree, but i get directories which are not matching the > pattern, > >> > > >> > >> really? that's very strange. > >> > >> > >> > and also it does not support recursive at the moment. > >> > > >> > >> It most certainly does support recursion. > >> > >> > >> > My proposal however is not complete, because it is not yet for the > nio2 > >> > watcher > >> > > >> > Fabian > >> > > >> > On Fri, Dec 11, 2015 at 2:44 PM, Raymond Auge < > [email protected] > >> > > >> > wrote: > >> > > >> > > Isn't the filter already enough to handle this? > >> > > > >> > > - Ray > >> > > On Dec 11, 2015 07:40, "Fabian Lange" <[email protected]> > >> > wrote: > >> > > > >> > > > Hi Guillaume, > >> > > > thanks for the reply. > >> > > > I have implemented a proposal > >> > > > > >> > > > > >> > > > >> > > >> > https://github.com/CodingFabian/felix/commit/3d9d9b17ede1e480b4f52d8a43d0f946694a47b4 > >> > > > > >> > > > I also replace SecureRandom with Random, because thats just > overkill > >> > for > >> > > > avoiding temp file collisions: > >> > > > > >> > > > > >> > > > > >> > > > >> > > >> > https://github.com/CodingFabian/felix/commit/69fce7ce5292d6287477debee384841402f51718 > >> > > > > >> > > > I do not know how I can find the JIRA you mentioned. Would you > take > >> > care > >> > > of > >> > > > the bookkeeping for me? > >> > > > Thank you > >> > > > > >> > > > Fabian > >> > > > > >> > > > On Fri, Dec 11, 2015 at 10:56 AM, Guillaume Nodet < > >> [email protected]> > >> > > > wrote: > >> > > > > >> > > > > If the default mode is the same as before, this should keep > >> > > > compatibility. > >> > > > > I don't have any problem adding a flag to disable directory > >> > processing, > >> > > > and > >> > > > > the proposed solution looks good to me (jar | recurse | skip). > >> > > > > The way to go would be to create a JIRA (actually, I think one > >> > already > >> > > > > exists for that) and attach a patch or provide a github pull > >> request. > >> > > > > > >> > > > > 2015-12-11 9:05 GMT+01:00 Fabian Lange < > >> [email protected] > >> > >: > >> > > > > > >> > > > > > Hia, > >> > > > > > as an Apache Karaf user I was today surprised to see > >> fileinstalls > >> > > > > behaviour > >> > > > > > in a Profiler > >> > > > > > > >> > > > > > I am using the feature to provide multiple directories. > >> > > > > > I am using karaf/etc,karaf/etc/mystuff > >> > > > > > > >> > > > > > What I did learn is that "mystuff" is already scanned but > >> treated > >> > as > >> > > > jar > >> > > > > > file. Sadly thats a big performance hog with a small update > >> > interval, > >> > > > > > because it creates temp files and copies the whole directory > >> into > >> > it. > >> > > > > > I have actually not figured out how I would use that feature > to > >> be > >> > > > > honest. > >> > > > > > > >> > > > > > What I however propose to do is to add a > >> > > > > > > >> > > > > > felix.fileinstall.subdirectory.mode = jar | recurese | skip > >> > > > > > Would this break any current functionality? when set to > recurse > >> or > >> > > > skip? > >> > > > > > > >> > > > > > How would be the process to integrate my changes? I could > >> provide a > >> > > > diff. > >> > > > > > > >> > > > > > And if somebody minds, please tell me how that jar thing is > >> > supposed > >> > > to > >> > > > > > work :) > >> > > > > > > >> > > > > > Best regards, > >> > > > > > Fabian > >> > > > > > > >> > > > > > -- > >> > > > > > Fabian Lange | Performance Expert > >> > > > > > mobil: +49 (0) 160.3673393 > >> > > > > > > >> > > > > > codecentric AG | Merscheider Straße 1 | 42699 Solingen | > >> > Deutschland > >> > > > > > > >> > > > > > Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht > >> Wuppertal > >> > > > > > Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns > >> > > > > > Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . > >> > Jürgen > >> > > > > Schütz > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> > >> > >> -- > >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > >> (@rotty3000) > >> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > >> (@Liferay) > >> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > >> (@OSGiAlliance) > >> > > > > >
