Issue with latest alpha-6 snapshot

Cannot set XMPPTCPConnectionConfiguration to a connection once connected to do a login.

I build configuration using

XMPPTCPConnectionConfiguration.XMPPTCPConnectionConfigurationBuilder gconfig = XMPPTCPConnectionConfiguration.builder();
        SmackConfiguration.DEBUG_ENABLED = DEBUG_VERSION;
        xmpptcpConnectionConfiguration; Later connect using config
       XMPPTCPConnection xmpptcpConnection = new XMPPTCPConnection(xmpptcpConnectionConfiguration);
       xmpptcpConnection.connect(); Later register/create account using user provided input name and password.
     AccountManager accountManager = AccountManager.getInstance(ConnectionsManager.getInstance().getConnection());
     accountManager.createAccount(username, pass, accountattribs); PROBLEM STARTS HERE                 gconfig.setUsernameAndPassword(user,secret);
                ConnectionsManager.getInstance().getConnection().login(); on Login it takes the old username and password its not taking the new connection user and password  I have to discconect and re-build config with new username and password
and then login . Can we not tweak something to allow login with params as it was before for non-anonymous logins ?
  1.   ; 
  2.             ConnectionsManager.getInstance().getConnection().login(); 

Where do you create a new XMPPTCPConnection instance with the newly build connection configuration?

If i create a new instance of xmmptcp i will have to disconnect the existing one yes or it automatically re-connects with new instance?

None of that, changing the credentials of a XMPPTCPConnection is no longer supported. You have to create a new one.

Flow schrieb:

None of that, changing the credentials of a XMPPTCPConnection is no longer supported. You have to create a new one.

I am not sure, if this in the flavor of RFC 6120, which states:

Where appropriate for the chosen SASL mechanism, the receiving entity SHOULD allow a configurable but reasonable number of retries (at least 2 and no more than 5); this enables the initiating entity (e.g., an end-user client) to tolerate incorrectly provided credentials (e.g., a mistyped password) without being forced to reconnect (which it would if the receiving entity immediately returned a SASL failure and closed the stream).

What do you think? What is if the user provides invalid credential? You have to create a new connection?

I know that that was likely the reason login() was defined with additional parameters. But this required additional complexity which caused some errors, see SMACK-614 and SMACK-615. Right now my top priority was to make ConnectionConfiguration immutable. Also the “user entered wrong password” case is the rare case, and not the common. I’m not sure if it hurts that much to reconnect.

Also note that the RFC weakly specifies the behavior for the receiving entity (the server).

BTW I’m not ruling out that the “provide different credentials with login” feature may be re-added later. Although it’s not a priority for me.

What’s the reason to store/provide the credentials in the ConnectionConfiguration? I mean you could make the configuration immutable (and not provide credentials in it) and still solve SMACK-614 (which seems to be resolvable easily at the first glance).

I’m thinking more about a design that stores the credentials in ConnectionConfiguration, but adding additional fields for the actually used username+password/callback handler in AbstractXMPPConnection. Then Smack could provides, besides login(), which will automatically decide which loging to perform, i.e. username, callback handler or anonymous, another login method with two String parameters for username and password.