Just to update where things are. Responses inline. On Thu, Feb 17, 2011 at 11:51 AM, Carl Hall <[email protected]> wrote:
> On Thu, Feb 17, 2011 at 11:19 AM, Carl Hall <[email protected]> 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? > Filed a patch under FELIX-2843 and merged by Carsten (thanks!). This change along with felix.fileinstall.disableConfigSave=false stops the constant reloading. > 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? > When an unchanged .cfg file is written out, lastModifed is not updated on my filesystem (linux; ext4). When an unchanged .config file is written out, lastModified is updated thus causing the checksum to not match and reload to happen. I have a patch to fix this but am not yet happy with how I am getting a reference to the scanner to update the checksum. I will keep refining this and submit the patch for review when ready (FELIX-2852). 1 https://issues.apache.org/jira/browse/FELIX-1572 >> >> >> On Thu, Feb 17, 2011 at 10:38 AM, Erik Froese <[email protected]>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 <[email protected]> >>> 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 <[email protected]> >>> 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: [email protected] >>> >> For additional commands, e-mail: [email protected] >>> >> >>> >> >>> > >>> >> >> >
