So it seems that we are the only ones facing this problem, although I have to believe that the Felix Web Console will suffer from it too if it is installed alongside FileInstall. I don't know my way around the Web console code very well, but I just has a quick look at the ConfigManager class and I can't see it write to the FileInstall watched directories anywhere. Personally I don't think it would be a good idea anyway and I imagine that if the Web Console were to address this issue the same design criteria would apply, i.e. that it only deal with the Config Admin service and not be coupled to FileInstall. Now of course the Web Console skirts this a little bit by insisting that MetaType information be available for a PID so it won't deal with FileInstall-deployed PIDs at all. At least it used to work that way, maybe that is not true any more. But again, we are probably unusual here by allowing developers to add JavaDoc-like annotations to config files that will be processed into MetaType information.
Could I ask for a favour that would help us tremendously? The bulk of the new methods in the FileInstall and ConfigInstaller classes are either private or package-scoped. This makes it impossible for us to use the FileInstall code off-the-shelf with a few of our customizations added by overriding the default behaviour. It would be great if these methods (including the ConfigInstaller constructor) were protected. On Thu, Nov 19, 2009 at 3:41 PM, Richard S. Hall <[email protected]>wrote: > Why not have your browser-based tool simply dump the changes into the cfg > files managed by File Install? > > -> richard > > > On 11/19/09 5:48 PM, Gerry Woods wrote: > >> We have what may be an unusual situation. We initialize our config admin >> state using .cfg files picked up and deployed by FileInstall. Users may >> then use a browser-based tool to modify these configurations. >> Unfortunately, any modifications made by the user are wiped out when we >> restart because FileInstall assumes it is the only source of configuration >> data for the PIDs associated with the files it sees in its watched >> directory. Because of this, we have been forced to use a modified version >> of FileInstall that adds a timestamp to the configuration that can then be >> compared to the last modified time for the .cfg file. I was wondering if >> this is on anyone else's radar, or if there are any plans to correct this >> behavior. >> >> >> >
