Florian Schmaus bfc14227ca 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' 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.		2017-01-07 10:38:41 +01:00
..
java/org/jivesoftware/smack	Propagate stream errors on connect/login to the caller	2017-01-07 10:38:41 +01:00
resources	Prefix subprojects with 'smack-'	2014-04-28 19:44:14 +02:00