Hi, all right, I think it would have been nicer to have that documented in either docs or code, but now that this is confirmed to be "as designed" I am going to propose a change to control this behaviour. Will come back with a PR later the day.
Fabian PS: I did already a couple of PRs, how is the process to get them going? On Mon, Dec 14, 2015 at 8:20 AM, Guillaume Nodet <[email protected]> wrote: > 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) > > >> > > > > > > > > >
