powered by Jive Software

Force ChatManager to obey threads in Messages

Quick background: I’m working on a bot with a strophe frontend. The bot can be interacted with directly, but the strophe client also uses it to manage a dashboard. In the strophe client, I am specifically setting a thread value on my messages as well as a unique resource when logging in. I log in with the same account Adium uses for my normal chat behavior. Every so often, I’d get bot responses in my Adium window while doing development on the dashboard. I tracked the reason down to Smack’s internal chat management. If it can’t find a chat that matches the thread, it uses one from the user or bare user cache (in order). Anyway, I wanted to be able to turn this behavior off. I made the following change in the ChatManager source for 3.3.1 (context provided), I’d be interested if this could become a core feature so I don’t have to patch future versions:


*** 91,96 ****

— 91,98 ----

= new WeakHashMap<PacketInterceptor, PacketFilter>();

private Connection connection;

  • private boolean strictThreadsResources = false;
    

ChatManager(Connection connection) {

this.connection = connection;


*** 116,122 ****

}

else {

chat = getThreadChat(message.getThread());

! if (chat == null) {

// Try to locate the chat based on the sender of the message

chat = getUserChat(message.getFrom());

}

— 118,124 ----

}

else {

chat = getThreadChat(message.getThread());

! if (chat == null && !strictThreadsResources) {

// Try to locate the chat based on the sender of the message

chat = getUserChat(message.getFrom());

}


*** 129,134 ****

— 131,148 ----

}

}, filter);

}

  • /**
    
  •  * Force smack to not fall back to user chat matching when looking up a matching
    
  •  * chat for messages with a thread. If the thread don't match, create a new chat
    
  •  */
    
  • public void setStrictThreadsResources(boolean strict) {
    
  •     strictThreadsResources = strict;
    
  • }
    
  • public boolean getStrictThreadsResources() {
    
  •     return strictThreadsResources;
    
  • }
    

/**

Please attach the patch as extra file in unified diff format (e.g. “diff -u”).

Done.

Thanks. http://issues.igniterealtime.org/browse/SMACK-387?focusedCommentId=20668&page=co m.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-20668

I am not very happy with introducing a new variable “strictThreadsResources”, because I think this is actually a bug as I described here.

This basically allows a user to enable or disable a bug.

Why not just fix this bug without the variable?

It certainly took me long enough to track down what was going on. Not sure how your post didn’t show up in my googling …

In the harsh light of day, I think you are right - I can’t come up with a single scenario in which the current behavior would be deisirable. The only stretch I have is that the code was there to deal with a bad client or server that wasn’t playing nice causing Smack to leak conversations.

I’d forget my patch and just remove the fallback - I can whip up a patch for that if need be…