-
1. Re: Managing configuration(properties) for my bundle
mielket Jul 21, 2009 8:47 AM (in response to vector_jdev.work)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
-
2. Re: Managing configuration(properties) for my bundle
mielket Jul 21, 2009 9:07 AM (in response to vector_jdev.work)FYI, have further raised the feature request ESB-795.
-
3. Re: Managing configuration(properties) for my bundle
vector_jdev.work Jul 21, 2009 9:51 AM (in response to 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
-
4. Re: Managing configuration(properties) for my bundle
mielket Jul 21, 2009 11:13 AM (in response to vector_jdev.work)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.
-
5. Re: Managing configuration(properties) for my bundle
vector_jdev.work Jul 24, 2009 10:26 AM (in response to mielket)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.
-
6. Re: Managing configuration(properties) for my bundle
unwired Aug 3, 2009 10:07 PM (in response to vector_jdev.work)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
-
7. Re: Managing configuration(properties) for my bundle
ccustine Aug 9, 2009 6:58 PM (in response to unwired)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