Hey Edward. Thanks for your comments. First off, I should mention that the PropertyFileConfigurationInitializer is very much a work in progress. It was developed with very specific usage in mind and will need to be modified before more generic usage scenarios can be supported. That being said, let me respond to your comments.
> * The naming scheme will assumes that the first dash (-) is the > separator for service pid.Where as the naming scheme examples in > chapter 104.3.1.3 for devices use dash extensively. Very true. Perhaps in the case of ManagedServiceFactories a different separator character should be used. > * Config admin support values other than string. Should we address key > naming scheme to differentiate the array, vector, number, long, short > plus mapped values? Yeah, I think it would be nice to support all of these types. > * Should PropertyFileConfigurationInitializer polls the > "net.tucana.osgi.service.config.base.dir" directory? that way, if any > of the file is modified, we can automatically update the configuration > admin. This would be nice. I've been thinking about how to handle changes to Configurations when the framework is running. Directory monitor polling functionality would also be nice for adding new Configurations to the system in addition to updating existing Configurations. Perhaps the updates could be bi-directional, ie, if a Configuration is changed via a config management UI, for example, then we could sync the config changes back to the corresponding properties files. Of course, this makes things a good deal more complicated, but is an interesting idea nonetheless. > * I don't think "PropertyFileConfigurationInitializer" should be > registered to OSGi container. Unless if this is used for "polling" > purposes or being able to update configurations on runtime. As it stands, this code is only useful for bootstrapping Configurations on framework startup, but I'd like to add support for runtime updates. I'd like to exand this code so as to make it more useful. > * I'm not sure what does the ServiceTracker#addingService() is doing. > Wouldn't this give random result i.e. if there is multiple > [DefaultConfigurationInitializer] services registered to OSGi > container? The ServiceTracker#addingService method is used to bootstrap configurations with the PropertyFileConfigurationInitializer as soon as a ConfigurationAdmin service implementation becomes available. This method should be marked as synchronized and should keep track of whether or not the configurations have been "bootstrapped" so as to prevent multiple invocations of PropertyFileConfigurationInitializer#initializeConfigurations from the addingService method. > There is config manager under pax/config-admin that does similar to this code. > https://scm.ops4j.org/repos/ops4j/projects/pax/config-admin/configmanager Thanks for the pointer. I'll take a look at this code this week. - Ben On 11/23/06, Edward Yakop <[EMAIL PROTECTED]> wrote: > Hi, > > PropertyFileConfigurationInitializer: > * The naming scheme will assumes that the first dash (-) is the > separator for service pid.Where as the naming scheme examples in > chapter 104.3.1.3 for devices use dash extensively. > * Config admin support values other than string. Should we address key > naming scheme to differentiate the array, vector, number, long, short > plus mapped values? > * Should PropertyFileConfigurationInitializer polls the > "net.tucana.osgi.service.config.base.dir" directory? that way, if any > of the file is modified, we can automatically update the configuration > admin. > > Activator of net.tucana.osgi.impl.config: > * I don't think "PropertyFileConfigurationInitializer" should be > registered to OSGi container. Unless if this is used for "polling" > purposes or being able to update configurations on runtime. > * I'm not sure what does the ServiceTracker#addingService() is doing. > Wouldn't this give random result i.e. if there is multiple > [DefaultConfigurationInitializer] services registered to OSGi > container? > > Note: > There is config manager under pax/config-admin that does similar to this code. > https://scm.ops4j.org/repos/ops4j/projects/pax/config-admin/configmanager > > Regards, > Edward Yakop > > On 11/23/06, Benjamin Schmaus <[EMAIL PROTECTED]> wrote: > > BTW, the link is > > > > https://scm.ops4j.org/repos/ops4j/laboratory/users/bschmaus > > > > and not > > > > https://scm.ops4j.org/repos/ops4j/laboratory/bschmaus > > > > I messed that up in the original post. > > > > On 11/22/06, Benjamin Schmaus <[EMAIL PROTECTED]> wrote: > > > Hey Niclas. > > > > > > Yes, the service in this bundle runs in conjunction with OSGi's > > > ConfigurationAdmin service. > > > > > > The README file under net.tucana.osgi.impl.config has more info. > > > > > > https://scm.ops4j.org/repos/ops4j/laboratory/users/bschmaus/net.tucana.osgi.impl.config/README > > > > > > I'm heading out of town for a couple of days on account of the > > > Thanksgiving holiday, but I can give you some more info next week if > > > you're interested. > > > > > > - Ben > > > > > > On 11/22/06, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > > > > On 11/22/06, Benjamin Schmaus <[EMAIL PROTECTED]> wrote: > > > > > > > > > I just committed some new bundles to: > > > > > > > > > > https://scm.ops4j.org/repos/ops4j/laboratory/bschmaus > > > > > > > > I have not checked this stuff yet (and about to fly to London shortly, > > > > so...) but do these bundle operate in accordance with the > > > > Configuration Admin service (ch 104, in the Compendium), if so how, or > > > > is it some other mechanism? > > > > > > > > > > > > Cheers > > > > Niclas > > > > > > > > _______________________________________________ > > > > general mailing list > > > > [email protected] > > > > http://lists.ops4j.org/mailman/listinfo/general > > > > > > > > > > > _______________________________________________ > > general mailing list > > [email protected] > > http://lists.ops4j.org/mailman/listinfo/general > > > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
