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 <[email protected]>: > 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 <[email protected]> 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 <[email protected]>: >>> @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 <[email protected]> >>> 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 <[email protected]> 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: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> >>> >>> -- >>> Cheers, >>> Guillaume Nodet >>> ------------------------ >>> Blog: http://gnodet.blogspot.com/ >>> ------------------------ >>> Open Source SOA >>> http://fusesource.com >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
