Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 276541 - XMPP messages are sent to wrong receiver when using multiple logins
Summary: XMPP messages are sent to wrong receiver when using multiple logins
Status: RESOLVED FIXED
Alias: None
Product: ECF
Classification: RT
Component: ecf.providers (show other bugs)
Version: 3.0.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.0.0RC2   Edit
Assignee: Marcelo Mayworm CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-15 13:47 EDT by Jörg Rathlev CLA
Modified: 2009-05-29 14:27 EDT (History)
3 users (show)

See Also:
mayworm: iplog+


Attachments
Proposed patch (1.08 KB, patch)
2009-05-15 13:47 EDT, Jörg Rathlev CLA
slewis: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jörg Rathlev CLA 2009-05-15 13:47:47 EDT
Created attachment 136036 [details]
Proposed patch

When using multiple logins with the same username, messages are sent to the user which logged in last, instead of the specific username/resourceID that was specified.

In the class org.eclipse.ecf.internal.provider.xmpp.smack.ECFConnection,
the method #sendMessage(ID, Message) determines the receiver for the XMPP message based on the IDs getUsernameAtHost(), which does not include the XMPP resource ID. If rcvr.getFQName() is used instead, the problem disappears.
Comment 1 Scott Lewis CLA 2009-05-15 13:54:16 EDT
Setting target milestone to RC2 and adding Remy, Marcelo for review of proposed fix/patch.

Thanks Jorg for finding/reporting and the proposed patch.
Comment 2 Remy Suen CLA 2009-05-15 14:46:23 EDT
Looks fine to me, thanks for the patch, Jorg. In the future, please create a patch and set the 'Patch Root' to be at the 'Workspace' level. This translates to less mouse clicks when applying patches because Eclipse will already know which project(s) to patch.
Comment 3 Scott Lewis CLA 2009-05-15 17:58:28 EDT
+1 from me for the patch.  Thanks Jorg.

After Marcelo's assent Remy would you like to apply and release?  (if you would rather, I will...doesn't matter to me).  Thanks.
Comment 4 Remy Suen CLA 2009-05-15 18:02:50 EDT
(In reply to comment #3)
> After Marcelo's assent Remy would you like to apply and release?  (if you would
> rather, I will...doesn't matter to me).  Thanks.

I don't mind but if you want this in as fast as possible then it would be easier if Marcelo pushes it in if he is okay with the diff. Saves the round trip of either of us reading the email and committing it.
Comment 5 Scott Lewis CLA 2009-05-15 18:51:47 EDT
(In reply to comment #4)
> (In reply to comment #3)
> > After Marcelo's assent Remy would you like to apply and release?  (if you would
> > rather, I will...doesn't matter to me).  Thanks.
> 
> I don't mind but if you want this in as fast as possible then it would be
> easier if Marcelo pushes it in if he is okay with the diff. Saves the round
> trip of either of us reading the email and committing it.
> 

Ok...sounds good to me.  Marcelo please approve, apply and release to head after you've had a chance to examine and test.  If you aren't able to do it for time or another reason just reassign and one of us will 

Thanks all.

Comment 6 Marcelo Mayworm CLA 2009-05-16 12:34:45 EDT
The patch is working fine and fix the bug. The code is already on the HEAD.

Thanks Jörg!
Comment 7 Marcelo Mayworm CLA 2009-05-16 14:15:45 EDT
iplog was changed and the fix in is place.