Build: #2 was successful Changes by Florian Schmaus <flo@geekplace.eu>

Build result summary

Details

Completed
Queue duration
< 1 second
Duration
3 minutes
Labels
None
Agent
Default Agent
Revision
b0fef6ffcbe18af78db93aa4b0d7e9fe24e90d15
Total tests
429
Successful since
#1 ()

Tests

Code commits

Author Commit Message Commit date
Florian Schmaus <flo@geekplace.eu> Florian Schmaus <flo@geekplace.eu> b0fef6ffcbe18af78db93aa4b0d7e9fe24e90d15 Ensure that populateHostAddressees() doesn't return a list with 'null'
Thanks to Grigory Fedorov for reporting this.
Florian Schmaus <flo@geekplace.eu> Florian Schmaus <flo@geekplace.eu> 51d3c3176638eb7e9e08e6facf71d589bc2ccb04 Initialize Socket in TCP connection when proxy is used
Thanks to Grigory Fedorov for reporting this.
Florian Schmaus <flo@geekplace.eu> Florian Schmaus <flo@geekplace.eu> bfc14227caba62de16de59fef8a09dbbdb2ec10e Propagate stream errors on connect/login to the caller
Before this, if there was a stream error response by the server to our
stream open, that error response would only be handled in the reader
thread, and the user would get a message like:

"org.jivesoftware.smack.SmackException$NoResponseException: No
response received within reply timeout. Timeout was
5000ms (~5s). While waiting for SASL mechanisms stream feature from
server"

while the server may actually sent something like

<stream:stream
  xmlns='jabber:client'
  xmlns:stream='http://etherx.jabber.org/streams&#39;
  id='6785787028201586334'
  from='jabbim.com'
  version='1.0'
  xml:lang='en'>
  <stream:error>
    <policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
        </policy-violation>
        <text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
          Too many (2) failed authentications from this IP
      address (1xx.66.xx.xxx). The address will be unblocked at 04:24:00
      06.01.2017 UTC
    </text>
  </stream:error>
</stream:stream>

It was necessary to change saslFeatureReceived from SmackException to
XMPPException in order to return the StreamErrorException at this sync
point. But this change in return required the introduction of a
tlsHandled sync point for SmackException (which just acts as a wrapper
for the various exception types that could occurn when establishing
TLS). The tlsHandled sync point is marked successful even if no TLS
was established in case none was required and/or if not supported by
the server.
Florian Schmaus <flo@geekplace.eu> Florian Schmaus <flo@geekplace.eu> cff91f5a920f31cf6ee1e1eb085a490d109c8125 Use correct element and namepsace in AccountManager.isSupported()
Florian Schmaus <flo@geekplace.eu> Florian Schmaus <flo@geekplace.eu> 7167a55f81d6f51db04ee739799813b1a280d835 AccountManager: Don't fallback to disco#info if not authenticated