I don't think there is any real *need* for that, but being consistent when possible never hurts. In addition to providing a single key for a human readable factory pid, it would also allow using different locations as input for such configurations while enabling those to work together.
On Tue, Sep 8, 2009 at 21:21, Filippo Diotalevi <[email protected] > wrote: > On Tue, Sep 8, 2009 at 8:54 PM, Felix Meschberger<[email protected]> > wrote: > > Hi all > > > > In a comment to FELIX-1221 [1] Tim Moloney proposes the definition of a > > well-known configuration property, which may act as kind of an alias for > > the service.pid property automatically generated by the Configuration > > Admin Service upon factory configuration creation. > > > > Such a property would serve multiple purposes: > > > > * Provide a human readable identifaction of a factory > > configuration (at least more human readable than the generated PID) > > > > * Provide an alias for tools match factory configurations to external > > data for synchronization. Candidates of such tools are: > > - File Install > > - Karaf Features > > - Sling JCR Install (similar to File Install) > > - Web Console > > > > > > Currently each tool uses its own approach and its own name. Having a > > common name would simplify things probably and would allow the Web > > Console to better identify configurations etc. > > > > Yes, if I understand correctly, it is what we have called in File > Install "felix.fileinstall.filename"; in that case, we needed a way to > remember the file generating the configuration dictionary (to retrieve > it later), so we introduced that constant. > > What I don't understand is, is there any benefit in having a unified > property name (besides the one you mention for the Web Console)? > > -- > Filippo Diotalevi > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
