Return-Path: X-Original-To: apmail-felix-users-archive@minotaur.apache.org Delivered-To: apmail-felix-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D16839CC8 for ; Wed, 25 Apr 2012 13:23:01 +0000 (UTC) Received: (qmail 58182 invoked by uid 500); 25 Apr 2012 13:23:01 -0000 Delivered-To: apmail-felix-users-archive@felix.apache.org Received: (qmail 58036 invoked by uid 500); 25 Apr 2012 13:23:00 -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 58025 invoked by uid 99); 25 Apr 2012 13:23:00 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Apr 2012 13:23:00 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of bengt.rodehav@gmail.com designates 209.85.160.177 as permitted sender) Received: from [209.85.160.177] (HELO mail-gy0-f177.google.com) (209.85.160.177) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Apr 2012 13:22:52 +0000 Received: by ghbf11 with SMTP id f11so90575ghb.22 for ; Wed, 25 Apr 2012 06:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=CoHCfyD9J9BC271V41Z6nAm3Mr6IQqEMXUrNOmAgg0U=; b=mKU9sgYO0XTQPznQeRMaqKnrYNMhulRqpWPrsks1hsjKU/kTePh3/xf0g2l3jsQM4E TqO7WYOtGmTmiLr5mHOVFA0F16zz1FFE8r8gHfLFYy7Y6TacPIAHa1TYdCzHDOs27qtg Rf+qh17jA47Cjhtq0QB7uQber2Y3sCx9s6dHapL/aUUnlSD561xCPVJ+aYvKFJ2ichaN WmIqKwa2wqxXO9hOjvcm3s6CK140RK3SxP/yzeGGEKxsD5/GYYEtLo8tdrKQmtXc6Jmb qrulfwXenw8+w5LH/dNxqCVS3qKevOqauCNYNev6bJEXfvRT5iVaQjU9LpNwv+c8zwcg OyrQ== MIME-Version: 1.0 Received: by 10.60.14.226 with SMTP id s2mr3403141oec.29.1335360151590; Wed, 25 Apr 2012 06:22:31 -0700 (PDT) Sender: bengt.rodehav@gmail.com Received: by 10.60.125.230 with HTTP; Wed, 25 Apr 2012 06:22:31 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Apr 2012 15:22:31 +0200 X-Google-Sender-Auth: feOAXjHZPwf5Mf2unP9vVTdrEwI Message-ID: Subject: Re: Variable substitution in File install From: Bengt Rodehav To: users@felix.apache.org Content-Type: multipart/alternative; boundary=e89a8fb1f9c47b953404be80c3a2 --e89a8fb1f9c47b953404be80c3a2 Content-Type: text/plain; charset=ISO-8859-1 After browsing through the code it seems like this is already implemented. The InterpolationHelper was updated to support this in https://issues.apache.org/jira/browse/FELIX-2663 (by yourself I believe Guillaume). This should be part of version 1.1.0 of Felix utils. Fileinstall uses 1.1.0 of Felix utils. It is marked as a private package and is therefore colocated in the fileinstall bundle. Looking at fileinstall it also seems like it is updated to pass the bundle context to InterpolationHelper. All in all, it seems like this has already been resolved... Now, why doesn't it work for me then? I will do a few more tests to verify that I'm not lying about this, /Bengt 2012/4/25 Bengt Rodehav > Will do... > > > 2012/4/25 Guillaume Nodet > >> Sure, and if you could provide a patch, that would be awesome of course >> ;-) >> >> On Wed, Apr 25, 2012 at 14:14, Bengt Rodehav wrote: >> >> > Wouldn't that be a neat feature? Shall I create a JIRA? >> > >> > /Bengt >> > >> > 2012/4/25 Guillaume Nodet >> > >> > > You're absolutely right. Custom properties are loaded by karaf main >> and >> > > given to the system bundle when the osgi framework is created, which >> are >> > > then made available to all bundles using BundleContext#getProperty(). >> > > The InterpolationHelper can be given a BundleContext which can be >> used in >> > > exactly the way we want. >> > > >> > > On Wed, Apr 25, 2012 at 13:47, Bengt Rodehav >> wrote: >> > > >> > > > The way I understood it, the InterpolationHelper is not used by >> config >> > > > admin but when the configuration is loaded from file (which is >> > initiated >> > > by >> > > > file install). Thus, file install would have to be made aware of the >> > > > properties defined in custom.properties somehow. I have no idea >> where >> > > those >> > > > are evaluated though. >> > > > >> > > > /Bengt >> > > > >> > > > 2012/4/25 Guillaume Nodet >> > > > >> > > > > Yes, it should be possible to do that, for to be consistent, it >> would >> > > > have >> > > > > to be done by ConfigAdmin too, else it could lead to >> inconsistencies >> > > > > between what FileInstall thinks the property value is and what the >> > > bundle >> > > > > actually receive. So I'd be fine with any change if those are >> done >> > by >> > > > > ConfigAdmin, but if they are done by iPojo or blueprint (for >> > example), >> > > > i'm >> > > > > not so sure. >> > > > > >> > > > > On Wed, Apr 25, 2012 at 13:36, Bengt Rodehav >> > > wrote: >> > > > > >> > > > > > Hello again Guillaume, >> > > > > > >> > > > > > I found the place where the substitution is being made. It's in >> the >> > > > class >> > > > > > InterpolationHelper which resides in the same package as Felix >> > > > Properties >> > > > > > class. >> > > > > > >> > > > > > I made a small test. It seems like variables defined as system >> > > > variables >> > > > > > are preserved (because InterpolationHelper knows about them). >> Also, >> > > if >> > > > I >> > > > > > refer to other configuration properties, they are preserved as >> > well. >> > > > > > >> > > > > > However, the properties I define in my custom.properties file >> are >> > not >> > > > > > preserved. Apparently they are not substituted by >> > > InterpolationHelper. >> > > > I >> > > > > > have no idea where that substitution takes place but I would >> like >> > to >> > > > make >> > > > > > fileinstall aware of it. Do you think that is possible? >> > > > > > >> > > > > > /Bengt >> > > > > > >> > > > > > 2012/4/25 Guillaume Nodet >> > > > > > >> > > > > > > Yes, only properties that have change should be written back. >> > > > > > > But as you said, the check is done by substituting inside the >> > > > > properties >> > > > > > > file, but if the computed value is different from the value >> from >> > > the >> > > > > > > configuration, the whole property will be overwritten by the >> new >> > > > value. >> > > > > > Do >> > > > > > > you have substitution with system properties or other bundle >> > > > > > configuration >> > > > > > > properties ? If so, those properties will be overwritten at >> the >> > > first >> > > > > > > change. >> > > > > > > >> > > > > > > On Wed, Apr 25, 2012 at 12:28, Bengt Rodehav < >> bengt@rodehav.com> >> > > > > wrote: >> > > > > > > >> > > > > > > > You mean that only properties that have changed should be >> > written >> > > > > back? >> > > > > > > Not >> > > > > > > > the part where variables are preserved even in changed >> > properties >> > > > - I >> > > > > > > > assume. >> > > > > > > >> > > > > > > >> > > > > > > > At a first glance I can't figure out where the variable >> > > > substitution >> > > > > > > takes >> > > > > > > > place either. But for this to work, it must be done before >> > > > comparing >> > > > > > with >> > > > > > > > the existing value - right? >> > > > > > > > >> > > > > > > > /Bengt >> > > > > > > > >> > > > > > > > 2012/4/25 Guillaume Nodet >> > > > > > > > >> > > > > > > > > That's exactly what is supposed to happen because we use >> > > > > > > > > the org.apache.felix.utils.properties.Properties which is >> > known >> > > > to >> > > > > > work >> > > > > > > > for >> > > > > > > > > that. >> > > > > > > > > One thing that could happen though is that the properties >> > that >> > > > are >> > > > > > > > > substituted are not know to fileinstall, so that it can't >> > > really >> > > > > > > compare >> > > > > > > > > the real values. >> > > > > > > > > The reason is that file install doesn't use the bundle >> system >> > > > > context >> > > > > > > > when >> > > > > > > > > computing the substitution so it only takes into account >> the >> > > > > > > substitution >> > > > > > > > > within the file, not with system properties or bundle >> context >> > > > > > > properties. >> > > > > > > > > I'm actually not sure who does such a substitution on the >> > > client >> > > > > side >> > > > > > > as >> > > > > > > > I >> > > > > > > > > doubt ConfigAdmin does not automatically. >> > > > > > > > > >> > > > > > > > > On Wed, Apr 25, 2012 at 11:11, Bengt Rodehav < >> > > bengt@rodehav.com> >> > > > > > > wrote: >> > > > > > > > > >> > > > > > > > > > One improvement I've been thinking about is to only >> write >> > > back >> > > > > > > > properties >> > > > > > > > > > that have actually changed. This would help in my case >> > since >> > > I >> > > > > have >> > > > > > > my >> > > > > > > > > own >> > > > > > > > > > web gui that disables/enables my services. I do so by >> > setting >> > > > an >> > > > > > > iPOJO >> > > > > > > > > > @Controller property to true/false via config admin. I >> > > > therefore >> > > > > > > don't >> > > > > > > > > use >> > > > > > > > > > any variables for this particular property but my other >> > > > > > configuration >> > > > > > > > > > properties (that are not changed) are "ruined" because >> of >> > the >> > > > > > > variable >> > > > > > > > > > expansion. >> > > > > > > > > > >> > > > > > > > > > I'm not sure if config admin provides enough >> information to >> > > > > > determine >> > > > > > > > > what >> > > > > > > > > > properties have been changed. Either way file install >> could >> > > > > > probably >> > > > > > > > > > evaluate it's current value of the property (and do >> > variable >> > > > > > > expansion >> > > > > > > > in >> > > > > > > > > > the process) and compare this value with the value >> provided >> > > by >> > > > > > config >> > > > > > > > > > admin. If they are the same than no writing back of this >> > > > property >> > > > > > is >> > > > > > > > > needed >> > > > > > > > > > and the variable would then be preserved in the >> > configuration >> > > > > file. >> > > > > > > > > > >> > > > > > > > > > I guess it would also be possible to preserve variables >> in >> > > > > > properties >> > > > > > > > > that >> > > > > > > > > > have been changed as well. File install could check if >> the >> > > > > original >> > > > > > > > value >> > > > > > > > > > contained variables. It could then try use those >> variables >> > > for >> > > > > the >> > > > > > > new >> > > > > > > > > > value as well. It would then have to search in the new >> > value >> > > if >> > > > > the >> > > > > > > > value >> > > > > > > > > > of the property is still used and then substitute that >> > value >> > > > for >> > > > > > the >> > > > > > > > > > property. This is not foolproof and could be ambiguous >> but >> > I >> > > > > think >> > > > > > it >> > > > > > > > > could >> > > > > > > > > > be implemented to work in most cases. This feature >> should >> > be >> > > > > > > > configurable >> > > > > > > > > > since it is not 100% safe. >> > > > > > > > > > >> > > > > > > > > > The feature not to write back properties that have not >> > > changed >> > > > > > could >> > > > > > > > also >> > > > > > > > > > be configurable but doesn't really have to be since I >> > believe >> > > > it >> > > > > > can >> > > > > > > be >> > > > > > > > > > made foolprooof. >> > > > > > > > > > >> > > > > > > > > > /Bengt >> > > > > > > > > > >> > > > > > > > > > 2012/4/25 Bengt Rodehav >> > > > > > > > > > >> > > > > > > > > > > I use file install (currently 3.1.10 but have also >> tried >> > > with >> > > > > > > 3.2.2) >> > > > > > > > in >> > > > > > > > > > > Karaf 2.2.5 to feed configurations (both normal and >> > factory >> > > > > > > > > > configurations) >> > > > > > > > > > > into the config admin service. >> > > > > > > > > > > >> > > > > > > > > > > In my configuration files I use different variables >> that >> > I >> > > > > define >> > > > > > > in >> > > > > > > > > > > Karaf's custom.properties file. I'm not sure whether >> > Karaf >> > > > > > exposes >> > > > > > > > them >> > > > > > > > > > as >> > > > > > > > > > > system properties but they are nevertheless picked up >> by >> > > > > > > fileinstall. >> > > > > > > > > > > >> > > > > > > > > > > However, when fileinstall is configured to write back >> > > > > > configuration >> > > > > > > > > > > changes to the configuration file, these variables are >> > not >> > > > > > > preserved >> > > > > > > > > but >> > > > > > > > > > > are expanded. This makes it very hard to read and >> further >> > > > > > maintain >> > > > > > > > the >> > > > > > > > > > > configuration files. I can easily see why this is >> > happening >> > > > > since >> > > > > > > the >> > > > > > > > > > work >> > > > > > > > > > > is divided between file install and the configuration >> > admin >> > > > and >> > > > > > the >> > > > > > > > > > latter >> > > > > > > > > > > does not know about the variables at all. >> > > > > > > > > > > >> > > > > > > > > > > I don't have a suggestion how to solve this but this >> is a >> > > > major >> > > > > > > > problem >> > > > > > > > > > > (for me at least) to use fileinstall and config admin >> > > > > together. I >> > > > > > > > guess >> > > > > > > > > > if >> > > > > > > > > > > fileinstall was just an implementation of the config >> > admin >> > > > > > instead >> > > > > > > > of a >> > > > > > > > > > > general listener to configuration chagnes there would >> be >> > > > other >> > > > > > > > > > > possibilities. >> > > > > > > > > > > >> > > > > > > > > > > Does anyone have any suggestions how to combine write >> > back >> > > of >> > > > > > > > > > > configuration changes with preservation of variables? >> > Could >> > > > > > > > fileinstall >> > > > > > > > > > > provide such a feature? >> > > > > > > > > > > >> > > > > > > > > > > /Bengt >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > -- >> > > > > > > > > ------------------------ >> > > > > > > > > Guillaume Nodet >> > > > > > > > > ------------------------ >> > > > > > > > > Blog: http://gnodet.blogspot.com/ >> > > > > > > > > ------------------------ >> > > > > > > > > FuseSource, Integration everywhere >> > > > > > > > > http://fusesource.com >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > -- >> > > > > > > ------------------------ >> > > > > > > Guillaume Nodet >> > > > > > > ------------------------ >> > > > > > > Blog: http://gnodet.blogspot.com/ >> > > > > > > ------------------------ >> > > > > > > FuseSource, Integration everywhere >> > > > > > > http://fusesource.com >> > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > ------------------------ >> > > > > Guillaume Nodet >> > > > > ------------------------ >> > > > > Blog: http://gnodet.blogspot.com/ >> > > > > ------------------------ >> > > > > FuseSource, Integration everywhere >> > > > > http://fusesource.com >> > > > > >> > > > >> > > >> > > >> > > >> > > -- >> > > ------------------------ >> > > Guillaume Nodet >> > > ------------------------ >> > > Blog: http://gnodet.blogspot.com/ >> > > ------------------------ >> > > FuseSource, Integration everywhere >> > > http://fusesource.com >> > > >> > >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> FuseSource, Integration everywhere >> http://fusesource.com >> > > --e89a8fb1f9c47b953404be80c3a2--