If I change configuration files I normally make a backup copy before. So did I with the file “LotusConnections-config.xml” of Lotus Connections 2.5. However, after I did that, Lotus Connections did no longer start and ended up with a bunch of java errors. My collegue Martti Garden reminded me, that we had this issue already in the past.
It does happen, if you store a copy of the “LotusConnections-config.xml” in the same directory as the file itself. Even if the file has another prefix (e.g. “Copy of …”) the error occurs. Another suffix (e.g. “LotusConnections-config.xml.OLD”) seems to work.
So be careful! And I will hopefully remember the next time and avoid some hours of debugging …
Update: Grrr. I just realized that I did post exact the same issue one year ago 🙁 It seems I need to search my blog the next time I do have a problem …
I thought this was the primary reason we blogged – so Google could lead us back to our posts explaining how to do things we forgot!
So did I … however I was 100% sure that it had something to do with the lines I changed in the config file so I did search for the wrong words in Google I guess…
This note is from the IBM developer responsible for this area.
When each IBM® Lotus® Connections application starts up it reads/validates all of the Lotus Connections configuration XML files, which are stored with the IBM® WebSphere® Application Server configuration files. An important point is that configuration in a file is NOT identified by the file name as one would expect – it is identified by the ‘id=’ attribute of the config element (which is one of the standard ways to identify configuration data). Thus, if a Lotus Connections configuration file is saved by renaming it from LotusConnections-config.xml to LotusConnections.SAVE.xml, for example, both files are XML files and contain the same set of configuration as far as Lotus Connections is concerned.
In earlier releases, Lotus Connections would read both files and use whichever version it read second. Thus, configuration changes might be mysteriously ignored. In release 2.5, the duplicate configuration is noticed and the following error message is logged: CLFRO0130E: Error, multiple configurations found for configuration identifier . (In addition, the full filename for each file is given). This, I would argue, is better/safer than using whichever configuration is read second.
Unfortunately, the message can get “lost” in the lengthy log as Connections continues to initialize. This will most likely be dealt with in the next release/fix-pack.
Hi Robert,
thanks a lot for this clarification!