IQ Handler not receiving message routed to "conference" service

Openfire Openfire Dev
1

I am writing a plugin which will accept a custom IQ packet which I’'d like to have addressed to (e.g. “conference.jivesoftware.org”), but it appears that packets addressed as such are being intercepted by the MUC IQ router before reaching my plugin.

The following code of IQRouter.java is the suspect area:

if (recipientJID != null) {
     RoutableChannelHandler serviceRoute = routingTable.getRoute(recipientJID);
     if (serviceRoute != null && !(serviceRoute instanceof ClientSession)) {
          // A component/service/remote server was found that can handle the Packet
          serviceRoute.process(packet);
          return;
     }
}
if (isLocalServer(recipientJID)) {
...

When a packet is being routed and it is determined that a service should be responsible for processing it, the method returns and never gets to the point where it would delegate to a custom IQ Handler. The only work-around I found for this was to just not set a “to” address on the incoming packet, but I would really like to avoid that since it makes no semantic sense since the whole point of the query is to obtain extended info about the MUC server.

Ideas?

Thanks,

Jeff

Message was edited by: jsegal

2

If any devs could shed some light on this I’'d be very appreciative.

3

Hey Jeff,

What you see is the intended and expected behavior. Each XMPP entity has its own XMPP address (i.e. JID). When you send an IQ packet to then the MUC service is going to handle that packet. Moreover, if you don’'t specify a TO address then the IQ packet is handled by the server itself by using the correct IQHandler.

I don’'t have more info about your requirements or what you are trying to achieve but what you can do is create a new service that will receive packets and may forward them to the MUC service. Your service will have its own JID so clients will need to send packets to the new service JID and the service will then interact with the MUC service.

Hope that helps.

Regards,

– Gato

4

Gato,

What I’'m trying to do is extend Service Discovery with a new query that would combine disco#items and disco#info. The idea is to cut down on network I/O by allowing clients to obtain both a list of children for a particular entity as well as some detailed information about each item, which would be added as child elements to the items. A query for information about each MUC on a server might look like this:

<iq id="6Kmp6-3" to="conference.foo.org" from="joe@foo.org">
     <query xmlns="http://jabber.org/protocol/disco#itemsinfo"></query>
</iq>

While a response could be:

<iq id="6Kmp6-4" to="joe@foo.org" from="conference.jsegal" type="result">
     <query xmlns="http://jabber.org/protocol/disco#itemsinfo">
          <item jid="numbercrunchers@conference.foo.org" name="Accounting"></item>
               <x xmlns=''jabber:x:data'' type=''result''>
                 <field var=''language''>
                    <value>english</value>
                 </field>
                 <field var=''department''>
                    <value>accounting</value>
                 </field>
                 <field ...></field>                                
               </x>
          </item>
          <item ...></item>
     </query>
</iq>

Obviously, this deviates from the Service Discovery protocol, but we didn’‘t like the idea of 100 users logging in at once, sending a disco#items for a list of 1000 chat rooms, then 1000 disco#info queries for each chat and each user. Since in the end it is essentially a query on the conference service, I didn’'t think it made sense to create a new service to handle it. However, if that is the only way to implement this as an IQHandler, it seems that the only other alternative would be to use a PacketInterceptor instead.

Thanks,

Jeff