Managing configuration(properties) for my bundle

[vector_jdev.work]

Generally speaking, I need to be able to configure my bundle. When developing .war web apps we were using .properties file included inside .war.  What is the best way to configure osgi bundles in fuse? Also when configuration is changed, the bundle must be able to get new configuration without restarting/redeploying the bundle...

What we're using now is "Configuration Admin" (that is the part of OSGI spec). I think that is the correct way of managing configuration for bundles, isn't it? When using this it's needed to have someBean.cfg under fuse_home/etc dir. The question is when having some hundreds of bundles deployed it will be nice to have all that config files under different dirs, ie etc/ds, etc/dao, etc/application1, etc/application2...

Is it possible to configure fuse that way? Also do you know how to reload config when its changed?

I've heard that it's possible to confiture Configuration Admin to get config from database. Does anybody advice me some source of information how to configure CA for FUSE?

Edited by: vector on Jul 21, 2009 8:27 AM

[mielket]

Hi,

Yes, the ConfigurationAdmin service is also provided by FUSE ESB 4.x. It scans the fuse_home/etc folder for config files but will it does not go into subdirectories. You will need to place your config files straight into etc/.

There is another option however: You can group your bundles into features and use a feature.xml configuration with that. It will then only applies to your feature.

See http://servicemix.apache.org/kernel/46-provisioning.html

[mielket]

FYI, have further raised the feature request ESB-795.

[vector_jdev.work]

Thanks. I will look deeply in grouping bundles into features then..

The configuration admin properties is the great way of configuring app. If you will store props inside your bundle, then QA team (or other people) need to unzip/change/zip/redeploy your bundle. Under conf. adm /etc folder the properties can be auto-updates during bundle runtime. This is very usefull feature, so including props inside may not be so good idea.

We just need to be able to manage huge amount of property files under /etc. It will also be good idea to be able to configure property manager to get them from DataBase.

PS. Can you update ESB-795 to include comments about pointing another datasource for configuration. (database )

Edited by: vector on Jul 21, 2009 1:50 PM

[mielket]

The configuration admin properties is the great way of configuring app. If you will store props inside your bundle, then QA team (or other people) need to unzip/change/zip/redeploy your bundle. Under conf. adm /etc folder the properties can be auto-updates during bundle runtime. This is very usefull feature, so including props inside may not be so good idea.

Yes, for many scenarios the configuration should not be part of the bundle itself but there might be other scenarios where this could be desired.

We just need to be able to manage huge amount of property files under /etc. It will also be good idea to be able to configure property manager to get them from DataBase.

PS. Can you update ESB-795 to include comments about pointing another datasource for configuration. (database )

I am not aware of that feature. Can you please point me to the resource where you read about it?

I particularly checked here and did not spot any mentioning of that feature.

[vector_jdev.work]

It is said, that The Configuration Admin service doesn?t specify any particular way of storing and accessing properties. Each implementation can do what it likes

Particulary we are having  Pax ConfMan implementation  of Config Admin service.

It means it's is possible to create a bundle that can manage properties in more convinient way then just putting all stuff to fuse_home/etc folder.

[unwired]

Is it possible from inside a bundle to update properties in the file system.  The use case is that there are some properties initialized from the .cfg file but subsequently the property is changed at runtime.  This property needs to be persisted so that the next run will use the new property

[ccustine]

If you change a configuration value through the config command (edit org.x.y.z, propset x y, update), then the value should be persisted to the bundle data.  It should use this value on next start as well, even though it isn't stored in the etc/org.x.y.z.cfg file. 

If you subsequently update the corresponding etc/org.x.y.z.cfg file by either changing values and saving, or even touch org.x.y.z.cfg, we will detect this and load all of the settings from there and therefore override the manual changes made from the shell.  Most people will choose one or the other method for changing config values, but I think we will improve this in the future so that it is more straight forward.

Thanks,

Chris