Return-Path: X-Original-To: apmail-karaf-user-archive@minotaur.apache.org Delivered-To: apmail-karaf-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D908B10E23 for ; Sat, 3 Jan 2015 20:07:17 +0000 (UTC) Received: (qmail 89033 invoked by uid 500); 3 Jan 2015 20:07:18 -0000 Delivered-To: apmail-karaf-user-archive@karaf.apache.org Received: (qmail 88985 invoked by uid 500); 3 Jan 2015 20:07:18 -0000 Mailing-List: contact user-help@karaf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@karaf.apache.org Delivered-To: mailing list user@karaf.apache.org Received: (qmail 88975 invoked by uid 99); 3 Jan 2015 20:07:18 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Jan 2015 20:07:18 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW X-Spam-Check-By: apache.org Received-SPF: error (athena.apache.org: local policy) Received: from [217.70.183.197] (HELO relay5-d.mail.gandi.net) (217.70.183.197) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Jan 2015 20:07:13 +0000 Received: from mfilter1-d.gandi.net (mfilter1-d.gandi.net [217.70.178.130]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 24B5B41C054 for ; Sat, 3 Jan 2015 21:06:11 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter1-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter1-d.gandi.net (mfilter1-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id dj2UYMpKO+jE for ; Sat, 3 Jan 2015 21:06:09 +0100 (CET) X-Originating-IP: 82.238.224.4 Received: from [192.168.134.10] (bre91-1-82-238-224-4.fbx.proxad.net [82.238.224.4]) (Authenticated sender: jb@nanthrax.net) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 5203841C04F for ; Sat, 3 Jan 2015 21:06:09 +0100 (CET) Message-ID: <54A84BAF.7070506@nanthrax.net> Date: Sat, 03 Jan 2015 21:06:07 +0100 From: =?windows-1252?Q?Jean-Baptiste_Onofr=E9?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: user@karaf.apache.org Subject: Re: Sharing configuration with Cellar References: <54987D81.8090601@nanthrax.net> <54991548.6040007@nanthrax.net> <54991BED.4090009@nanthrax.net> <1A752566-F381-4474-8BB7-090A9BE22325@gmail.com> In-Reply-To: <1A752566-F381-4474-8BB7-090A9BE22325@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Hey Ronny, I did the change to let you tweak the property that you want to exclude. I push and publish a SNAPSHOT for you. Regards JB On 01/03/2015 08:38 PM, Ronny Br=E4unlich wrote: > Hello Jean-Baptiste, > > did you make the change so that the factoryPid gets shared? > If yes, do I have to set a certain property? > > Cheers, > Ronny > > Am 23.12.2014 um 08:38 schrieb Jean-Baptiste Onofr=E9 >: > > Hi Ronny, > > No, it mean that the PID are normally created on the fly right ? So > locally to one node. > > Let me build a SNAPSHOT without the factoryPid filtering, you will be > able to test it. I keep you posted. > > Regards > JB > > On 12/23/2014 08:28 AM, Ronny Br=E4unlich wrote: >> Hi Jean-Baptiste, >> >> I was using version 3.0.0 and I don't mind using a SNAPSHOT versionsin= ce >> it's only my free time project ;) >> >> So, what you're saying is, that it would be better if a bundle would >> create the properties and pass them to the configuration admin than a >> *.cfg file in the /etc directory? >> >> Cheers, >> Ronny >> >> 2014-12-23 8:10 GMT+01:00 Jean-Baptiste Onofr=E9 > >> >: >> >> Hi Ronny, >> >> which version of Cellar do you use ? >> >> Do you mind to make a quick test with a SNAPSHOT ? >> >> Basically, the reason for filtering the factoryPid is that normally= , >> they are local to a node (they are created locally), so not sure if >> it makes sense to sync it as it should be created by the >> bundle/factory. >> >> Regards >> JB >> >> >> On 12/23/2014 07:04 AM, Ronny Br=E4unlich wrote: >> >> Hi Achmin, hi Jean-Baptiste, >> >> thank you for your quick responses. >> Please, you could explain to me why the service.factoryPid was >> excluded and why you think that I shouldn't use a config-factor= y? >> >> What I try to achive is that on one Karaf instance the service = gets >> configured and the ManagedServiceFactory on every Karaf creates= the >> same service. That ways I hope to achieve better scaling (at >> least in >> my mind ;) ) because the service exists several times. >> >> Cheers, >> Ronny >> >> PS. Happy holidays guys! >> >> 2014-12-22 21:22 GMT+01:00, Jean-Baptiste Onofr=E9 >> >: >> >> Hi Ronny, >> >> as you can see in the Cellar ConfigurationSupport: >> >> private static String[] EXCLUDED_PROPERTIES =3D >> {"service.factoryPid", >> "felix.fileinstall.filename", "felix.fileinstall.dir", >> "felix.fileinstall.tmpdir", >> "org.ops4j.pax.url.mvn.__defaultRepositories"}; >> >> The service.factoryPid is not sync by Cellar: it's an >> expected behavior >> as it doesn't make sense to sync it: the main configuration >> should >> create the pid. >> >> I created a Jira to let the user configure the excluded >> properties (as >> his own risk). >> >> If your configuration is a regular conf, it should be sync >> without >> problem by Cellar. I don't think it's a good idea to sync >> config factory >> (and use config factory generally speaking ;)) >> >> Let me implement the command to allow you to change the >> excluded >> properties. >> >> Regards >> JB >> >> On 12/22/2014 09:10 PM, Ronny Br=E4unlich wrote: >> >> Hi all, >> >> I know I already had some similar question but I think = I >> am getting >> closer to the real problem. >> There is an example project, too, which you can find he= re: >> https://github.com/__rbraeunlich/karaf-managed-__service-factory-examp= le >> >> >> Basically I have two Karaf instances synchronized with >> the help of >> Cellar. >> In the etc/ directory I placed a file >> named >> de.blogspot.wrongtracks.__simple.factory.Factory-1.cfg >> The log of the first Karaf shows the expected log entri= es: >> "Got pid: >> >> de.blogspot.wrongtracks.__simple.factory.Factory.__6b9773c4-a828-4ddc-= bbdc-__ecbdd99535cb >> with following dictionary.=93 >> Unfortunately, the second Karaf doesn=92t want to >> participate. The >> configuration arrived (visible via config:list >> "(service.pid=3Dde.blogspot*)=93 but no log entries are >> visible. >> Shouldn=92t the second factory write the log entries, t= oo? >> >> Cheers, >> Ronny >> >> >> -- >> Jean-Baptiste Onofr=E9 >> jbonofre@apache.org >> >> http://blog.nanthrax.net >> Talend -http://www.talend.com >> >> >> -- >> Jean-Baptiste Onofr=E9 >> jbonofre@apache.org >> >> http://blog.nanthrax.net >> Talend -http://www.talend.com >> >> > > -- > Jean-Baptiste Onofr=E9 > jbonofre@apache.org > http://blog.nanthrax.net > Talend -http://www.talend.com > --=20 Jean-Baptiste Onofr=E9 jbonofre@apache.org http://blog.nanthrax.net Talend - http://www.talend.com