Return-Path: Delivered-To: apmail-felix-users-archive@minotaur.apache.org Received: (qmail 58223 invoked from network); 17 Feb 2011 16:52:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 17 Feb 2011 16:52:10 -0000 Received: (qmail 86052 invoked by uid 500); 17 Feb 2011 16:52:10 -0000 Delivered-To: apmail-felix-users-archive@felix.apache.org Received: (qmail 85705 invoked by uid 500); 17 Feb 2011 16:52:07 -0000 Mailing-List: contact users-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@felix.apache.org Delivered-To: mailing list users@felix.apache.org Received: (qmail 85689 invoked by uid 99); 17 Feb 2011 16:52:06 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Feb 2011 16:52:06 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [74.125.82.53] (HELO mail-ww0-f53.google.com) (74.125.82.53) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Feb 2011 16:52:00 +0000 Received: by wwi18 with SMTP id 18so2607532wwi.10 for ; Thu, 17 Feb 2011 08:51:38 -0800 (PST) Received: by 10.216.185.199 with SMTP id u49mr2121699wem.45.1297961498183; Thu, 17 Feb 2011 08:51:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.230.137 with HTTP; Thu, 17 Feb 2011 08:51:18 -0800 (PST) X-Originating-IP: [71.92.39.5] In-Reply-To: References:

From: Carl Hall Date: Thu, 17 Feb 2011 11:51:18 -0500 Message-ID: Subject: Re: Fileinstall not reading .config files To: users@felix.apache.org Cc: dev@felix.apache.org Content-Type: multipart/alternative; boundary=0016e65397aa080ca4049c7d36c2 --0016e65397aa080ca4049c7d36c2 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 17, 2011 at 11:19 AM, Carl Hall 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 > /*.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 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 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 >> 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-unsubscribe@felix.apache.org >> >> For additional commands, e-mail: users-help@felix.apache.org >> >> >> >> >> > >> > > --0016e65397aa080ca4049c7d36c2--