Hi Jean-Baptiste, the combination with shared configuration and excluded factoryPid sounds like my initial problem, beacuse of which you made the properties blacklist configurable ( http://karaf.922171.n3.nabble.com/Sharing-configuration-with-Cellar-td4037365.html#a4037374 ).
But I can try this combination again on monday. Improving the factory sync sounds good ;) One question out of curiosity, why do you generate this factoryPid anyways? Cheers, Ronny 2015-01-23 8:52 GMT+01:00 Jean-Baptiste Onofré <[email protected]>: > By the way, Ronny, for Cellar 3.0.2/2.3.5, I will improve the factory sync > with a special behaviour way service.factoryPid property is there. > > I will create a Jira about that. > > Regards > JB > > On 01/23/2015 07:38 AM, Ronny Bräunlich wrote: > >> Hi Achim, Hi Jean-Baptiste, >> >> that was a lot of input for me. >> Let me start with your questions: >> >> >The ManagedServiceFactory comes from a bundle right ? >> >It's a bundle containing a service implementing ManagedServiceFactory. >> >> Right! >> >> >So, you have to sync the bundle with Cellar: you will have the factory >> on the nodes, and the sync on the config created by the factory. >> >You see what I mean ? >> >> I am not sure what you mean. Synchronising the bundle will lead to a >> factory on each node, right. But what do you mean with "the sync on the >> config created by the factory"? Do you mean the actual file or the object? >> >> >By the way, do you use etc/*.cfg file or config:* commands to create >> the config files ? >> >> I used a .cfg file. As you taught me its name is the Factory PID "-1.cfg". >> >> >Sometime I think a management server isn't always the worst idea when >> configuring a cluster. >> >> No objections ;) >> >> Cheers, >> Ronny >> >> 2015-01-22 21:24 GMT+01:00 Jean-Baptiste Onofré <[email protected] >> <mailto:[email protected]>>: >> >> Anyway, honestly, I don't see a huge issue just by excluding >> factoryPid and sync the PID. It's not perfect, but it works fine if >> the file are present in the etc folder. >> >> Regards >> JB >> >> On 01/22/2015 08:50 PM, Achim Nierbeck wrote: >> >> JB, no problem at all. >> My first idea to use a UUID made of the nodeID and the >> factoryPid, does >> have some dangers though. >> If someone adds this configuration on two nodes it is >> duplicated. But >> one has to die one death ;) >> >> Sometime I think a management server isn't always the worst idea >> when >> configuring a cluster. >> >> regards, Achim >> >> >> >> 2015-01-22 20:43 GMT+01:00 Jean-Baptiste Onofré <[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>: >> >> By the way, thanks Achim again for the discussion ;) >> >> >> On 01/22/2015 08:41 PM, Jean-Baptiste Onofré wrote: >> >> In order to manage service factory in a better way, I >> can implement >> something similar to fileinstall: a specific property >> like >> karaf.cellar.factoryPid to know where the factory comes >> from. >> >> It's the way that fileinstall manage each *.cfg file >> (adding the >> felix.fileinstall.filename property). >> >> Let me dig around that and improve this. >> >> Regards >> JB >> >> On 01/22/2015 06:27 PM, Ronny Bräunlich wrote: >> >> Hi everyone, >> >> I am using Apache Karaf 3.0.2 and Cellar >> 3.0.1-SNAPSHOT >> (built from >> commit >> 7a598b285f7b302efa15d9887dfea9____d855b9951a) and I >> think I found a >> bug. >> I have two Karaf instances running. On both I >> installed >> Cellar and this >> simple project >> https://github.com/____rbraeunlich/karaf-managed-____ >> service-factory-example >> <https://github.com/__rbraeunlich/karaf-managed-__ >> service-factory-example> >> >> >> <https://github.com/__rbraeunlich/karaf-managed-__ >> service-factory-example >> <https://github.com/rbraeunlich/karaf-managed- >> service-factory-example>> >> After setting config.listener = true on both and >> removing >> service.factoryPid from the >> config.excluded.properties I >> dropped a >> config file into the etc/ directory. >> Then I could see the factory on the first Karaf >> instance >> getting called >> with the properties roughly every 100ms. >> Debugging the Karaf couldn’t show me the source of >> the >> problem. I >> suggest the Karaf updates itself and therefore >> calls the >> update() method >> all the time. >> The second instance didn’t make a move all the time. >> >> Does anyone have a clue? >> >> Cheers, >> Ronny >> >> >> >> -- >> Jean-Baptiste Onofré >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >> >> >> >> -- >> >> Apache Member >> Apache Karaf <http://karaf.apache.org/> Committer & PMC >> OPS4J Pax Web <http://wiki.ops4j.org/__display/paxweb/Pax+Web/ >> <http://wiki.ops4j.org/display/paxweb/Pax+Web/>> Committer >> & Project Lead >> blog <http://notizblog.nierbeck.de/__> >> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >> >> Software Architect / Project Manager / Scrum Master >> >> >> -- >> Jean-Baptiste Onofré >> [email protected] <mailto:[email protected]> >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
