issues with 1.0.0.RC1 ConnectController

[goatboy]

This controller was flexible and allowed you to pass in a Provider<ConnectionRepository> to be used as your connectionRepository factory/finder. Now it seems it's a singleton connectionRepository and this takes away all flexibility to say service mutilple users/accounts that are being added to db. for example this is how our connection repository factory used to create a repository per request and allowed us to deal with a single account per request and use the same controller to oauth many different providers without being forced to use the userId/User db model of spring social showcase examples.

@Configuration("connectionRepositoryProvider")
public class PublishToSocialConnectionRepositoryProvider {

    @Bean(name ="connectionRepository")
    @Scope(value = "request")
	public ConnectionRepository createConnectionRepository(@Value("#{session.getAttribute('accountId')}") Long accountId) {
		return new PublishToSocialConnectionRepository(accountId);
	}
}

this way on each request we would get a connectionRepository that dealt with that specific account id because addConnection() only takes a Connection object. Our extended controller from ConnectController was clean and relied on ConnectController to do all the oauth/add of new access_tokens for mutiple accounts.
Now it's forced to have only one connectionRepository during construction and ConnectController is singleton and there is not a clean way to make it aware of which accountId to deal with.
Please either make
addConnection(...) protected or
b) stop making these member variables all private final on all these classes it's an API for God's sake but it has no flexibility to be extended. why can't connectionRepository in ConnectController be protected member so child classes can access it or set it up like they need to?
c) Go back to Inject Provider<ConnectionRepository> style that was in m3 and daily snapshots for a long time. At least this method allowed some flexibility and overwrite by subclasses of ConnectController.

there are no hooks in this ConnectController and all the member fields are private final.

[Keith Donald]

I'm OK with extension but it needs to be designed for carefully with all extension points well-documented.

As it relates to @Injecting Provider<ConnectionRepository> vs ConnectionRepository, please review the latest spring-social-quickstart and spring-social-showcase SocialConfig.java and you'll see why we made this change. To have a user-scoped reference injected, inject a proxy to a request-scoped bean as shown in both of these samples.

FWIW, we've also factored out a ConnectSupport utility class you can reuse in your own Controller implementation if you'd rather do it some other way.

Keith