Yeah, I agree. In Karaf, we've enhanced the config commands so that you can actually edit a configuration based on the zookeeper file it uses, so that should help too.
On Tue, Apr 5, 2011 at 17:36, Achim Nierbeck <bcanh...@googlemail.com> wrote: > Guillaume, > > you are right that if there are multiple directories watched you run > into this issue. > Never the less the ID still would be unique, just the stored data > wouldn't which leads to quite a mess > when looking for the reason :) > > Since the ConfigurationAdmin API doesn't give a way of adding this > PID, ok I give up :) > > Just thinking about a perfect world, where we certainly don't live in, > it would have helped. > > regards, Achim > > > 2011/4/5 Guillaume Nodet <gno...@gmail.com>: >> Fileinstall can monitor multiple directories, so you'd need the full >> path in order to have a unique id. >> And the ConfigurationAdmin API gives no way to set the PID anyway, so >> not sure how we could do that. The API only allow the creation of a >> new factory configuration given its factory PID or the modification of >> an existing configuration. >> >> On Tue, Apr 5, 2011 at 09:01, Achim Nierbeck <bcanh...@googlemail.com> wrote: >>> Hi Guillaume, >>> >>> I'm still not convinced :) >>> Since a file name is usually unique since we are talking of the >>> combination of FileInstall and ConfigurationAdmin. >>> In this case I'd say the <factory.pid>-<service-pid> pattern could be used. >>> >>> regards, Achim >>> >>> >>> 2011/4/4 Guillaume Nodet <gno...@gmail.com>: >>>> @Achim: >>>> This would not really guarantee a new unique PID if you can give it ... >>>> >>>> @Carlos: >>>> Not sure about the meta-type, but I suppose it should use the factory >>>> pid instead of factory based configurations? >>>> >>>> On Mon, Apr 4, 2011 at 22:59, Achim Nierbeck <bcanh...@googlemail.com> >>>> wrote: >>>>> Hi Guillaume, >>>>> >>>>> just because out of curiosity, where in the spec is it defined how the >>>>> PID is generated? >>>>> I just found the following in the current 4.2 spec: >>>>> >>>>> <quote> >>>>> When a Configuration object for a Managed Service Factory is created >>>>> (ConfigurationAdmin.createFactoryConfiguration), a new unique PID is >>>>> created for this object by the Configuration Admin service. The scheme >>>>> used >>>>> for this PID is defined by the Configuration Admin service and is >>>>> unrelated >>>>> to the factory PID. >>>>> </quote> >>>>> >>>>> The way I read this, that it is completely free on how to define this >>>>> unique PID. >>>>> From my point of view in combination with the FileInstaller this newly >>>>> unique Service PID could be like Carlos suggested. >>>>> >>>>> just my 2 cents >>>>> >>>>> regards, Achim >>>>> >>>>>> The ConfigAdmin spec specifies that the PID has to be generated, so >>>>>> no, that's not possible. >>>>>> However you can filter based on the file name, as an additional >>>>>> property is added to the configuration to be able to easily link it >>>>>> back to the file. >>>>>> Look for the felix.fileinstall.filename property. >>>>>> >>>>>> On Fri, Apr 1, 2011 at 13:50, Carlos Quiroz <cqui...@gemini.edu> wrote: >>>>>>> Hi >>>>>>> >>>>>>> I have been using FileInstall to start and install my services using >>>>>>> ManagedServiceFactories but one issue I find is that FileInstall ask >>>>>>> ConfigAdmin an initial configuration which is set to a random UUID. >>>>>>> >>>>>>> Could be that FileInstall gets the pid from the file name like is >>>>>>> getting the Factory PID? Like >>>>>>> >>>>>>> <factory.pid>-<service.pid>.cfg >>>>>>> >>>>>>> In the code, FileInstall is actually doing something like that parsing >>>>>>> the filename but it doesn't use the service.pid part >>>>>>> >>>>>>> I think that would be quite useful as the Random UUID in PID makes it >>>>>>> difficult to find specific services >>>>>>> >>>>>>> Any opinion? >>>>>>> >>>>>>> Carlos >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>>>>> For additional commands, e-mail: users-h...@felix.apache.org >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>>> For additional commands, e-mail: users-h...@felix.apache.org >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> Guillaume Nodet >>>> ------------------------ >>>> Blog: http://gnodet.blogspot.com/ >>>> ------------------------ >>>> Open Source SOA >>>> http://fusesource.com >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>> For additional commands, e-mail: users-h...@felix.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>> For additional commands, e-mail: users-h...@felix.apache.org >>> >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
