The first manually created group chat service gets the same service ID as the conference service which is added automatically. This results in the following issues:
When trying to create room with same ID of the room in other service it throws an error, that such room already exists, but still lets you to create such room.
Deleting one of the service deletes also the other and all rooms on both services.
Sometimes it copies permanent room from previous service
Apart from preventing these problems from occurring in the future, existing (faulty) configurations need to be fixed. These faulty configurations can be identified by the existence of two services with serviceID value '1'. As we cannot distinguish which attribute (room, property, affiliation, etc) belongs to which of the duplicate service, we will duplicate all of these existing attributes. This will result in a situation that mimics the existing behavior. We'll upset the least amount of users this way.
Ah, bleh. This is going to take forever. We're currently under some pressure to release the next version of Openfire. Lets be pragmatic and go with Guenther's solution. It is available now and will enable us to move forward.
Guenther, I just checked in your patch, slightly modified to allow the code to be moved outside of the SchemaManager implementation. This way, we at least keep that code clean(er). Could you review my changes, apply modifications where needed and resolve this issue please?
In my opinion it looks good, so I closed the ticket.
I just hit this problem on my 3.6 server. It seems to me that there is a more fundamental database problem if the intention is to allow separate services to have rooms with the same name. If that is what is desired then the then either serviceID needs to be added everywhere roomID occurs or the roomID must be unique across all services. It makes sense in that case to generate the roomID and don't make the end manually do a uniqueness search before creating a room.