Return-Path: 
 <users-return-9850-apmail-felix-users-archive=felix.apache.org@felix.apache.org>
Delivered-To: apmail-felix-users-archive@minotaur.apache.org
Received: (qmail 39418 invoked from network); 17 Feb 2011 16:20:36 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 17 Feb 2011 16:20:36 -0000
Received: (qmail 9494 invoked by uid 500); 17 Feb 2011 16:20:36 -0000
Delivered-To: apmail-felix-users-archive@felix.apache.org
Received: (qmail 9046 invoked by uid 500); 17 Feb 2011 16:20:33 -0000
Mailing-List: contact users-help@felix.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@felix.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@felix.apache.org>
List-Post: <mailto:users@felix.apache.org>
List-Id: <users.felix.apache.org>
Reply-To: users@felix.apache.org
Delivered-To: mailing list users@felix.apache.org
Received: (qmail 9024 invoked by uid 99); 17 Feb 2011 16:20:32 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Feb 2011 16:20:32 +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 (nike.apache.org: local policy)
Received: from [209.85.215.49] (HELO mail-ew0-f49.google.com) (209.85.215.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Feb 2011 16:20:24 +0000
Received: by ewy20 with SMTP id 20so1113596ewy.22
        for <multiple recipients>; Thu, 17 Feb 2011 08:20:03 -0800 (PST)
Received: by 10.216.185.199 with SMTP id u49mr2082968wem.45.1297959584114;
 Thu, 17 Feb 2011 08:19:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.230.137 with HTTP; Thu, 17 Feb 2011 08:19:19 -0800 (PST)
X-Originating-IP: [71.92.39.5]
In-Reply-To: <AANLkTikJs8wvHJF5OKyKU_8RUC2_VBnxJFvXqvgnFBAE@mail.gmail.com>
References: <AANLkTi=4QduStzu+J74mBGo6PV1K6xF4pdqx6EgMgZpo@mail.gmail.com>
 <AANLkTim+v_1jeepWasK8v8FnqbAdgbNh1uxUMX2qCCbB@mail.gmail.com>
 <AANLkTikJs8wvHJF5OKyKU_8RUC2_VBnxJFvXqvgnFBAE@mail.gmail.com>
From: Carl Hall <carl@hallwaytech.com>
Date: Thu, 17 Feb 2011 11:19:19 -0500
Message-ID: <AANLkTinpdW2at0cu4-myWFaMrxDNk8PJKT2exxx--f1H@mail.gmail.com>
Subject: Re: Fileinstall not reading .config files
To: users@felix.apache.org
Cc: dev@felix.apache.org
Content-Type: multipart/alternative; boundary=0016e65397aaf1b398049c7cc3c4
X-Virus-Checked: Checked by ClamAV on apache.org

--0016e65397aaf1b398049c7cc3c4
Content-Type: text/plain; charset=ISO-8859-1

// 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?

1 https://issues.apache.org/jira/browse/FELIX-1572


On Thu, Feb 17, 2011 at 10:38 AM, Erik Froese <erik.froese@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 <carl@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.froese@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-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >
>

--0016e65397aaf1b398049c7cc3c4--