On Thu, Feb 17, 2011 at 11:19 AM, Carl Hall <c...@hallwaytech.com> wrote:
> // cc'ing dev list for suggestions of direction to proceed > > This sounds like an old bug [1] with a new twist. I've noticed that > <watched dir>/*.config files are read up, have 2 new props added > (service.pid, felix.fileinstall.filename) and are then written back to the > watched dir which seems to cause the loop (later, rinse, repeat). Note: the > *.config files are also appropriately written to felix-cache/ just like the > *.cfg files. > > From the sound of things, if fileinstall is stopped from writing the > *.config files back to the watched dir (load/ in this case), the errant loop > should be fixed. > devs, is this the right direction to go or are there implications I don't > know about? > This is already possible by setting felix.fileinstall.disableConfigSave = false (this logic looks backwards; shouldn't it be 'true'?). There is some logic performed on .cfg files to filter out service.pid, serviceFactory.pid, and felix.fileinstall.filename before writing back. Should this same logic be applied to .config files? I will look into the checksum matching and see if the loop can be stopped in that area. Should the checksum be updated after the file has been written back to its original location? 1 https://issues.apache.org/jira/browse/FELIX-1572 > > > On Thu, Feb 17, 2011 at 10:38 AM, Erik Froese <erik.fro...@gmail.com>wrote: > >> Hey Carl, >> >> Thanks. That patch does fix the problem of reading .config files from >> the fileinstall watched directory. >> >> It has an unfortunate side-effect though. Now the configuration is >> re-read and re-applied every time the fileinstall bundle scans the >> watched directory. This causes the services in the configured bundle >> to be unregistered, re-configured, and re-registered over and over. >> I'm guessing its not checking the timestamp on the file. >> >> Erik >> >> >> On Wed, Feb 16, 2011 at 12:35 AM, Carl Hall <c...@hallwaytech.com> wrote: >> > I debugged into this a bit tonight and found that when the file >> > load/some.great.Service.config is read up, the service pid that is >> parsed >> > from it turns out to be some.great.Service.co rather than >> some.great.Service >> > which causes config admin to not set the config on the correct service. >> I >> > have filed a JIRA for this [1] and attached a patch. >> > >> > Erik, catch me tomorrow and we'll test this a bit to verify this is what >> > you're experiencing. >> > >> > 1 https://issues.apache.org/jira/browse/FELIX-2843 >> > >> > >> > On Mon, Feb 14, 2011 at 11:32 AM, Erik Froese <erik.fro...@gmail.com> >> wrote: >> > >> >> Can anyone tell me how to use the richer syntax in a .config file and >> >> have felix / fileinstall / configadmin pick it up and apply it either >> >> on startup or during the fileinstall poll? >> >> >> >> Maybe I misunderstood something but I think the fileinstall should be >> >> able to read in a .config or .cfg file from the load directory (or >> >> whatever it's configured for). When it sees a .config file it should >> >> read it in with the same syntax that it saves bundles configurations. >> >> >> >> The .cfg files are read in as simple java.util.Properties files where >> >> everything is a string. I can't specify a list or map in these files. >> >> Everything gets wrapped in quotes and shoved into the configured >> >> attribute as a string. >> >> >> >> The .config file syntax allows for collections using syntax like: >> >> some.property = [ "value1", "value2" ] >> >> >> >> I configured fileinstall to monitor the $FELIX_HOME/load/ directory >> >> for bundles and config files. I was watching the process with dtruss >> >> (on a mac) and a debugger and I see java reading .cfg and .config >> >> files. The content of .cfg files is loaded into the running bundle >> >> configuration but the .config file doens't seem to affect anything. >> >> >> >> Thanks >> >> Erik >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> >> For additional commands, e-mail: users-h...@felix.apache.org >> >> >> >> >> > >> > >
