powered by Jive Software

Listing Persistent Rooms that are tied to Component Sessions vs a Group Chat Service

Is there a way to list Persistent Rooms that are tied to Component Sessions vs a Group Chat Service

I have an external component that connects with a domain name of “weather.example.com”. You interact with it by joining a room like “dothis%dothat@weather.example.com”. Everything works fine when joining the rooms. I would like to create a list of interaction rooms as Persistent Rooms and need a solution.

If I create a Group Chat service of ‘weather’ I can create rooms, but my external component name ‘weather’ has a conflict and will not connect.

  • Is there a way to create a Persistent Rooms list without creating a Group Chat Service, so when Openfire sees the room name it directs it to the component for action?
  • Or is there a way to create a Group Chat Service and External Component with the same name that does not create issues

I hope this makes sense!


Does your component implement XEP-0045 Multi-User Chat? If it does not, then the address “dothisdothat@weather.example.com” does not represent a chat room (it is otherwise a valid address and will be routed to the external component, but the functionality behind the address is limited to whatever the external component implementation provides).

The Group Chat Service (conference) is a component in itself. This is why you get conflicts when you try to register another component with the same address. You cannot run two different components, using the same name.

Once upon a time, the Group Chat Service was designed to be runnable as a standalone, external component. I’m not sure if it’s still feasible to do that today (given that many years of development have passed, and that aspect has been totally neglected). It might be worth exploring though.

What functionality does your external component provide? Does that complement ‘group chat’ functionality, or don’t you need actual group chats at all? I’m guessing you do, as you want your rooms listed?

One way of hacking in functionality is by using PacketInterceptors, which could intercept data that’s being sent to the chat rooms, and act on it. The PacketInterceptor API is, however, available to Openfire plugins, but not external components.

Hi Guus,
I am not the end developer – just a user – so thank you for mapping this out.

  • The Group Chat service is a component itself
  • You cannot run two different components using the same name
  • I do want my rooms listed
  • Does your component implement XEP-0045 Multi-User Chat? I do not know?
    As I understand what you said I see I might have these possible options, and please add to it if I need more. (I am assuming, so correct me if I am wrong)
  1. Component change: Since Group Chat Service is a component then my component should be able to list rooms if it is written to implement XEP-0045 Multi-User Chat.
  • So, I can go back to the developer that have them add functionality to list rooms via a configuration file or whatever so that persistent channels show up for the component when I do a ‘room list’ on that server name (which is my component like weather.example.com)
  1. Openfire Add-On: A plugin or external component could be written that lists rooms and then hands them off to the component, like a new version of the PacketInterceptors but for rooms.
  • Example plugin.example.com or component.example.com is written to list rooms and take data from Openfire to my component. When you query plugin.example.com you get a list of rooms, then when you join that room you actually get directed to the component which takes action and does what it does